nextboot (was Re: boot block differences between 4.x and 6.x ?)

[Julian Elischer]

John Baldwin wrote:

>On Wednesday 01 February 2006 15:20, 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.
>>    
>>
>
>You are already presuming something of an FS as that is where you get your 
>loader and kernel from.  (Well, you could get the kernel from somewhere else 
>perhaps, but not the loader unless you are using PXE or a CD to boot.)
>  
>

I'm  not presuming anything about a particular slice, if I can specify 
another one..