Active slice, only for a next boot

Julian Elischer julian at freebsd.org
Sat May 28 18:17:08 UTC 2011


On 5/28/11 11:10 AM, Julian Elischer wrote:
> On 5/28/11 4:06 AM, Chris Rees wrote:
>>
>>
>> On 28 May 2011 10:04, "Julian Elischer" <julian at freebsd.org 
>> <mailto:julian at freebsd.org>> wrote:
>> >
>> > On 5/27/11 11:34 AM, Warner Losh wrote:
>> >>
>> >> On May 27, 2011, at 10:47 AM, rank1seeker at gmail.com 
>> <mailto:rank1seeker at gmail.com> wrote:
>> >>
>> >>> ----- Original Message -----
>> >>> From: Alexander Best<arundel at freebsd.org 
>> <mailto:arundel at freebsd.org>>
>> >>> To: rank1seeker at gmail.com <mailto:rank1seeker at gmail.com>
>> >>> Cc: hackers at freebsd.org <mailto:hackers at freebsd.org>
>> >>> Date: Fri, 27 May 2011 13:47:54 +0000
>> >>> Subject: Re: Active slice, only for a next boot
>> >>>
>> >>>> On Fri May 27 11, rank1seeker at gmail.com 
>> <mailto:rank1seeker at gmail.com> wrote:
>> >>>>>
>> >>>>> Idea is ...
>> >>>>> I have i.e; 3 slices, of which first is active.
>> >>>>> Now I wana set slice 2 active, but only for a one/next boot.
>> >>>>> Once slice 2 is booted and system is shutdown or rebooted, 
>> once again,
>> >>>
>> >>> first slice is active and booted, without user's intervention.
>> >>>>>
>> >>>>> Is this possible or should be implemented?
>> >
>> >
>> > nextboot(8) USED to do this before it was broken by someone to 
>> "look into the filesystem"
>> > for it's next boot hint which is obviously broken if you are 
>> trying to get to another filesystem
>> > because the main one is broken.
>> >
>>
>> Doesn't sound that useful to me- I think of the main use for 
>> nextboot being to try new kernels on a one-time basis. If you're 
>> rescuing a broken filesystem surely it's better to just set another 
>> slice active?
>>
>
> try using it on an appliance
>
> it has to recover  on its own from a complete filesystem screwup. 
i.e.  a 100% recovery with NO HUMAN INTERVENTION.
even in the case of a dead/dieing drive. (requires that bios has drive 
boot order feature)

I will add that this functionality is so useful that several companies 
still maintain the old bootblocks internally
(e.g. cisco)

The new functionality was introduced without an consultation and the 
old functionality just 'lost'.
Which was just bad design and project management..


>
>> Chris
>>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to 
> "freebsd-hackers-unsubscribe at freebsd.org"
>



More information about the freebsd-hackers mailing list