no GPT support

[GoogleCodeExporter]

9front appears to not support GUID-Partition-Table-ed disks.  Some fool who 
GPT-ized every box in sight and has to live with that for now should extract 
either code or a spec from FreeBSD gpart and implement userspace GPT goo for 
Plan 9.

If someone else wants to do this, I would suggest (a) keeping the code to 
expose contiguous regions of a disk as files in a separate process/module from 
the code that parses/unparses the partition table (the former should live in 
the kernel, and maybe replace the existing partition support, once its 
interface is sane and settled), and (b) keeping in mind that the disk could 
contain malicious data (e.g. strings containing “../”).

Original issue reported on code.google.com by rransom....@gmail.com on 10 Aug 2012 at 6:13

[GoogleCodeExporter]

Oh, ‘the code to expose contiguous regions of a disk as files’ is called 
fs(3).  Nice!

Original comment by rransom....@gmail.com on 10 Aug 2012 at 8:14

[GoogleCodeExporter]

the fs(3) device is for soft raids (mirrors, stripes, disk encryption ect...)
the sd(3) device also supports adding and removing continuous "regions" (we 
call them
partitions). the kernel doesnt do any partition table parsing at all. the
dos partition table is read by a userspace program disk/fdisk which then writes
the textual ctl messages to /dev/sdXX/ctl to add the partitions. plan9 
partition table
btw is exactly in that format as the ctl messages ;) ...

to support gpt, you just need to write a program that parses them and outputs 
these
ctl messages.

Original comment by cinap_le...@felloff.net on 10 Aug 2012 at 8:27

• Changed state: BasiclySound

[GoogleCodeExporter]

just write a program disk/gdisk which is like disk/fdisk, but for GPT

Original comment by a...@phicode.de on 10 Aug 2012 at 9:55

• Added labels: Priority-RockBottom
• Removed labels: Priority-Low

[GoogleCodeExporter]

How much would people hate having a ‘libuuid’ added to the system?

Original comment by rransom....@gmail.com on 13 Aug 2012 at 7:25

[GoogleCodeExporter]

how would this solve any problem? why not just write a simple function? just 
try to concentrate on the goal and try to archive it without pulling in systemd 
and dbus. ;)

Original comment by cinap_le...@felloff.net on 13 Aug 2012 at 8:11

[GoogleCodeExporter]

Some notes:

* I really do need a library, but it'll be libgpt, not just libuuid, because ...
* ... disk/fdisk and disk/prep seem like bad Plan 9 (or Unix) style to me.  The 
Right Thing is to have one program to read the partition table into an editable 
textual format, another program to write it back (after (optionally) 
sanity-checking it, of course), and possibly other little scripts to help 
humans munge the text format (although I can't think of any useful things for 
scripts to do to a good format besides ‘add new partitions to install $OS 
onto’).
* I want a tool to make a backup of the old partition table (or whatever would 
be clobbered by writing a new one), too (and a tool to restore it).  
Fortunately, this is mostly independent of GPT; all it needs is a (textual) 
list of chunks of disk to save.

(But I only want to add the good parts of systemd and dbus! ;) )

Original comment by rransom....@gmail.com on 13 Aug 2012 at 11:15

[GoogleCodeExporter]

You fail to argument on why we need a library and not a standalone program.

Original comment by iru.mu...@gmail.com on 13 Sep 2012 at 5:38

[GoogleCodeExporter]

He fails in delivering anything but random noise in
the bugtracker and whining that he can't have its
libpony that will solve everything for him.

closing this issue until theres some code.

Original comment by cinap_le...@felloff.net on 3 Oct 2012 at 4:32

• Changed state: ThereIsNoBug