Date: Mon, 30 Oct 1995 13:14:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.org Subject: Re: boot disk.... Message-ID: <199510302014.NAA06517@phaeton.artisoft.com> In-Reply-To: <199510300812.JAA04793@uriah.heep.sax.de> from "J Wunsch" at Oct 30, 95 09:12:08 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's more that this much work be put in to maintain compatability with > > the existing scheme. If I Were To Have My Way (tm), I'd have another > > partition in the FreeBSD slice for holding kernels and bootstrap tools, > > stuck at the front of the slice. (Reminiscent of the SVR4 /stand (?) > > concept). I can see right now the fracas this would cause 8( > > Yeah, we've already got this one: the partition is called `a', and > it's mounted as /. Where's that big difference here to /stand? Er. Bad144 puts the replacement tracks at the end of the partition. That mans that a partition spanning the 1024 cylinder boundry on a device with bad144 enabled on it may in fact be unbootable if the sector conatining inode 2 is replaces, a sector in the directory contents referenced by inode 2 is replaced, a sector in the inode referenced by the directory entry for the booting kernel is replaced, or any of the blocks making up the booting kernel are replaced. This is arguably an implementation problem in bad144. I have continually argued for placing the replacement tracks following the 'a' slice and before the 'b' slice, such that you could steal space from swap if needed instead of reformatting the drive. This requires a disklabel change for "location of bad sector" if this is to be done automatically, or simply a layout change if it's to be under "user control" (read as "intensely complicated compared to a reinstall"). > After i had to install an SCO for a customer (ick!, they couldn't be > convinced of FreeBSD), and noticed that this f*cking multi-level boot > takes ages until it finally presents the Boot: prompt, i'm no longer a > fan of any more boot stages. The 7.5 K limitation has one interesting > feature: it makes us fast, since you could not put a GUI into it. :-) 8-). > Believe it or not, a separate /stand/boot tool will be bloated and > bloated until it will finally reaches its limits, too -- but it will > be much slower, and waste more boot time and disk space then. It > won't serve any better purpose however, and none of our current > problems can really be solved by it, except perhaps for the ``can only > boot off the compatibility slice'' one. Actually, it would have the advantage of letting the '/' partition be hosted on a non-UFS file system. It would also give us a place to put kernel modules and configure memory size dynamically (ala UnixWare) and file system modules, etc.. I think it was the implementation, not the idea, that is flawed in System V. On the other hand, it goes *away* from a hosted environment (ala UMSDOS), and so detracts from the ability to easily "test drive" it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510302014.NAA06517>