Date: Tue, 29 Oct 2002 14:32:30 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c disk.c libdisk.h rules.c Message-ID: <20021029143230.A76592@kayak.xcllnt.net> In-Reply-To: <98377.1035926855@critter.freebsd.dk> References: <20021029124341.A76240@kayak.xcllnt.net> <98377.1035926855@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 29, 2002 at 10:27:35PM +0100, Poul-Henning Kamp wrote: > Sparc64 has no disklabel either and fsck should just be muffled to > not whine if the disklabel check fails: BSD disklabels are optional > now. Agreed. Getting GEOM to help out with these queries might also be something to consider. This can be as simple as parsing the sysctl information that's already there. For all I know, libdisk might do that right now... > I wont have much time to help you out before 5.0, but feel free to > throw questions at me if you want to try to tackle this yourself. No worries. As you explained above, the fsck(8) issue relates to when there's no /etc/fstab. I completely failed to make that clear. The biggest issue with GEOM WRT to partitioning in general is the inability to partition a disk when slices are mounted. It's known, and I'm sure we'll see a fix shortly. That is, I assume that's what you're working on :-) > You should be able to use the path though libdisk which I have just > cleared for sparc64 and alpha. The interface to the kernel is about > as generic as I can do it, and with a little luck you may need no > more than 10 lines of code in libdisk:disk.c to fill in the right > details. You need to write a write_ia64_disk.c which writes GPT, > and that is probably the worst bit. Sounds like something I might even want to try soon. > The situation is probably worse over in sysinstall, because you need > a mix of both screens if we want to co-exist with other OS's: > Only the "MBR" screen can understand "not ours" chunks of disk, and > only the "LABEL" screen can assign mountpoints and all that. Something like that yes. I'm not sure it's beneficial to seperate out the "them" and "us" to great extend, because I think we may want to have sysinstall create EFI partitions while we're at it. This is 95% on the way to have sysinstall create partitions/slices of just about anything we care about. > I will suggest that you fake it in the following way: > > Go into the MBR screen, and let people operate on the GPT partitions > like they would on MBR slices, have people create all FreeBSD > parititions here. Next, send them to the Label screen but disable > all size/create/delete options, and use it only for assigning > mountpoints, ufs options etc. This is far from optimal, and will > be different from what people are used to, but it will be possible > to implement it on a crash-schedule before 5.0. Since nobody is used to installing BSD with GPT, we don't have to worry about that too much. If it works and gets the job done, fine. If not, then we can aways migrate the MBR into a GPT post-mortem with gpt(8) and not do anything about sysinstall. On the other hand, FreeBSD/ia64 works perfectly fine with MBR and disklabel based partitioning so we can also delay this when the next sysins... Damn; and I tried so hard to avoid getting in that corner :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021029143230.A76592>