Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Feb 2006 15:04:45 -0700
From:      Scott Long <scottl@samsco.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        freebsd-current@freebsd.org, Oliver Fromme <olli@lurza.secnetix.de>
Subject:   Re: nextboot (was Re: boot block differences between 4.x and 6.x ?)
Message-ID:  <43E1307D.9030907@samsco.org>
In-Reply-To: <43E117F3.9090400@elischer.org>
References:  <200602011341.k11Dfbq1008941@lurza.secnetix.de>	<200602011240.11682.jhb@freebsd.org> <43E117F3.9090400@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
> John Baldwin wrote:
> 
>> On Wednesday 01 February 2006 08:41, 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?
>>>   
>>
>>
>> /boot/loader already does nextboot and does it by using UFS writing 
>> (which it does implement and use on archs whose disk drivers support 
>> writing such as i386) to overwrite (but not extend) /boot/nextboot.conf.
>>  
>>
> 
> which is exactly the feature that I wanted to avoid with the original 
> nextboot(8).
> Do NOT get any where-to-boot-from info from the possibly suspect 
> filesystem.
> Do NOT write back to the "possibly-suspect-filesystem".
> 
> The original nextboot was BIOS specific and not portable which is why 
> the new one
> has some good points (portable), but it didn't rely on correctness of the
> bootblock FS code or an intact first FS.
> 

It doesn't allocate new blocks or alter metadata.  It only modifies
existing data blocks.  It is no more unsafe than mounting an unclean
filesystem while bgfsck is running, and actually is a whole lot more
safe than that.

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43E1307D.9030907>