Date: Wed, 01 Feb 2006 12:15:06 -0800 From: Julian Elischer <julian@elischer.org> To: freebsd-current@freebsd.org Subject: Re: nextboot (was Re: boot block differences between 4.x and 6.x ?) Message-ID: <43E116CA.9060201@elischer.org> In-Reply-To: <200602011341.k11Dfbq1008941@lurza.secnetix.de> References: <200602011341.k11Dfbq1008941@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Oliver Fromme wrote: >Julian Elischer wrote: > > Oliver Fromme wrote: > > > [...] > > > I think the most visible changes in the boot blocks was > > > UFS2 support and the removal of nextboot(8) support. > > > > which I hope to put back because we continue to need it. > >I agree that it's needed. It's a very useful feature. > > > (The new nextboot being dependent on the root filesystem still being ok > > which is unacceptable to most embedded devices I've worked on, and why > > we still use the old bootblocks on all systems shipped.). > >>From my point of view, the biggest problem with the old >nextboot was the fact that it ignored loader(8) and tried >to load the kernel directly. While that might work under >certain conditions, it's not good in general. > >Therefore I think that a new nextboot implementation >should be implemented in loader itself. Since loader(8) >doesn't (and shouldn't) support writing to UFS2, the >state information should be written to an unused area in >block 2 on the disk, or something similar. In fact, one >byte is sufficient: It can be used as an index into a >table (ASCII text file), e.g. /boot/nextboot.conf. > >Would that be feasible to implement? > > The old nextboot used the 2nd block of the filesystem to hold information. But I can't remember if it used that information itself at all to decide whether to load boot1/boot2 from another partition, or whether it just always loaded it from the first 8k of the forst BSD partition.. I believe the latter. If I had lots of time to do it, I think I'd want to make a 'bootconfig' partition that covered the place where the info is stored and then try and interpret SOME of the information recovered to decide what drive/slice to load the rest of the boot1/boot2 combo. When we wrote the original nextboot code, we wanted to select between two root partitions, so that a failure to boot would result in a fallback to the other root, but we didn't want the bootblock writing anywhere in a filesystem, nor did we want the we kept free otherwise. We were only concerned with one drive however. At Ironport we use the identical scheme again. Allowing one root partition to be upgraded (with a newfs if needed) while teh other is being run on, and then rebooting into the new one with confidence that if it fails to get all the way up another reboot would come back to the previous root. Having the information as to where to boot to, on one of those partitions is not an option.. it may be failing because the filesystem, is in fact screwed. >Best regards > Oliver > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43E116CA.9060201>