Date: Fri, 4 Dec 1998 03:57:24 +0200 (SAT) From: Robert Nordier <rnordier@nordier.com> To: joelh@gnu.org (Joel Ray Holveck) Cc: freebsd-current@FreeBSD.ORG Subject: Re: /boot/loader what to set rootdev to? Message-ID: <199812040157.DAA21505@ceia.nordier.com> In-Reply-To: <86af14vprc.fsf@detlev.UUCP> from Joel Ray Holveck at "Dec 3, 98 04:12:39 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Joel Ray Holveck wrote: > > To me, commonsense just says no. And I'm not trying to convert > > anyone else to that opinion: it's why I don't want to even *think* > > about this stuff any more. :-) > > Okay. If you feel it necessary to drop this thread, go ahead. If you > can explain the cold boot rule's reasoning to me, even better. If you > (or Mike or anybody) can tell me whether nextboot still works, > terrific. We're probably fundamentally at cross-purposes here. You're saying, "But if I'm smart and careful, FBSDBOOT works for me, now". I'm saying, "FBSDBOOT is a major PITA with an immense potential for generating future support headaches because most folks will expect it to work when they're being neither smart nor careful. And it won't necessarily fail outright, it may just make the entire (future) system behave erratically." DOS was never intended as a generic launching pad for other operating systems. If their abysmal way, DOS versions 5 and above are quite sophisticated in terms of how they transform the default BIOS environment. No doubt you would never run FBSDBOOT with half a dozen home-grown DOS device drivers, and an equal number of TSR utilities installed. No doubt you would never run FBSDBOOT after running some inane non-resident program in your AUTOEXEC.BAT which completely hoses some significant part of the BIOS Data Area. No doubt you would never run FBSDBOOT after using a sexy commercial package which carelessly reprograms some hardware component in a way that doesn't matter to DOS. Before FreeBSD use of vm86, running FBSDBOOT was largely a hit or miss affair (the kernel loaded or it didn't). Once vm86 is heavily in use, the scenario changes. Let's say your file systems are suddenly getting trashed? Is that a FreeBSD problem? Well, FreeBSD will certainly get the blame. But faced with a predominantly Windows-using user, how do we disentangle this? Does everyone start sending MSD (Microsoft Systems Diagnostics) output along with the dmesg stuff? I'm not saying "Don't use FBSDBOOT". I'm just saying that (even though FBSDBOOT is "there" and works some of the time) loading DOS to load BTX to load the FreeBSD kernel is just not the easy route it seems to be. DOS opens a major can of worms. The worms may stay in the can, or they may not; either way, the result is simply dubious. By comparison, a clean boot approach is simple and failsafe. Regarding nextboot, I can't get your question into any kind of context, sorry. Is this just an entirely separate issue, or does "still works" relate to using FBSDBOOT versus not using FBSDBOOT in some way? -- Robert Nordier 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?199812040157.DAA21505>