Date: Thu, 12 Nov 1998 10:37:09 +0800 From: Peter Wemm <peter@netplex.com.au> To: asami@FreeBSD.ORG (Satoshi Asami) Cc: chuckr@mat.net, nate@mt.sri.com, jkh@zippy.cdrom.com, mike@smith.net.au, obrien@NUXI.com, current@FreeBSD.ORG Subject: Re: Is it soup yet? :-) Message-ID: <199811120237.KAA13939@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 11 Nov 1998 15:12:56 PST." <199811112312.PAA16909@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Satoshi Asami wrote:
> * No, you forget, there's 2 reasons to have things in /. One, they're
> * needed for boot. Two, they qualify as emergency repair tools.
> * Diskalbel falls into the 2nd category (note I agree with Nate's original
> * position here).
>
> And the bootblocks might be needed for emergency repair. Consider, if
> you have a disk that's failing all over the place, you managed to boot
> single-user from it (or booted from a floppy) and mounted root, you
> now need to somehow set up a bootable FreeBSD installation on your
> second hard drive. You are toast if the bootblocks are in the broken
> /usr.
Mind if I ask a question? What is going to get put on this bootable
installation on the second disk if you can't mount /usr? You're going to
have a pretty rotten time trying to use the new disk when /usr is empty.
If your source (and objects) are (were) in /usr/src and /usr/obj, then
you're still cactus because you can't rebuild /usr on the new disk.
If they were on /home/src or something like that and you can still mount
/home, then you can use disklabel to install the bootblocks from
/home/obj/where/ever.
Anyway, I find the easiest way of preparing and partitioning new disks is
to use a sysinstall floppy. :-)
Somebody else talked about the same argument applying to /sbin/disklabel
vs. /usr/sbin/disklabel. That is a different situation, disklabel belongs
in / because it's purpose is partition editing - bootblock installation is
a convenient add-on, not it's sole purpose.
My original complaint was about the (apparent) suggestion that /usr/mdec
was going away and the contents moved to /boot. We presently have a heap
of crud installed into /usr/mdec, which I object to installing on /. Since
it looks like what is actually proposed is that the stuff that presently
goes into /usr/mdec is going away and the present /boot/boot{0,1,2} that
is already in /boot will stay - I can live with that.
What about disklabel though? It's presently got rules for generating boot
names from the prefixes of the devices. ie: a boot1 for fd0 comes from "/
usr/mdec/fdboot", while boot2 comes from /usr/mdec/bootfd. This allows
implied (without disktab) support for having different bootcode on
different devices. Are we talking about changing this so that
#ifdef i386
defboot1 = "/boot/boot1";
defboot2 = "/boot/boot2";
#endif
#ifdef alpha
defboot1 = "/boot/boot1";
defboot2 = NULL; /* alpha has only one boot block set */
#endif
? Of course this would be overrideable by disktab and the command line,
but I want to make sure we're not talking about a symlink tree in /boot..
> Satoshi
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811120237.KAA13939>