Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Feb 2006 12:20:03 -0800
From:      Julian Elischer <julian@elischer.org>
To:        John Baldwin <jhb@freebsd.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:  <43E117F3.9090400@elischer.org>
In-Reply-To: <200602011240.11682.jhb@freebsd.org>
References:  <200602011341.k11Dfbq1008941@lurza.secnetix.de> <200602011240.11682.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.





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