[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: Active slice, only for a next boot
From:       rank1seeker () gmail ! com
Date:       2012-03-27 18:57:46
Message-ID: 20120327.185746.474.1 () DOMY-PC
[Download RAW message or body]

----- Original Message -----
From: Chris Rees <crees@freebsd.org>
To: rank1seeker@gmail.com
Cc: John Baldwin <jhb@freebsd.org>, hackers@freebsd.org
Date: Mon, 26 Mar 2012 21:28:07 +0000
Subject: Re: Active slice, only for a next boot

> On 26 March 2012 18:10,  <rank1seeker@gmail.com> wrote:
> > ----- Original Message -----
> > From: John Baldwin <jhb@freebsd.org>
> > To: freebsd-hackers@freebsd.org
> > Cc: rank1seeker@gmail.com, hackers@freebsd.org
> > Date: Mon, 26 Mar 2012 10:18:53 -0400
> > Subject: Re: Active slice, only for a next boot
> > 
> > > On Sunday, March 25, 2012 2:49:17 pm rank1seeker@gmail.com wrote:
> > > > After having a thought about this issue and also currently looking at a
> > > BootEasy boot manager ...
> > > > 'boot0cfg' is almost perfect for this task and should/could be "exploited".
> > > > 
> > > > It's '-o noupdate' already does a major task, of keeping main slice active.
> > > > Now all we need is a flag, through which we specify slice to boot (replacing
> > > human presing button).
> > > > From that point on, existing code simply proceeds with received value.
> > > > 
> > > > '-o noupdate' ensures next boot will bring up main/active slice.
> > > 
> > > You mean like 'boot0cfg -s 4'?
> > > 
> > > --
> > > John Baldwin
> > > 
> > 
> > 
> > Yes, but new flag for that purpose ('-n' for example => nextboot).
> > 
> > I.e;
> > # 'boot0cfg -s 4 -o noupdate -n 3'
> > 
> > Would, set the default/main boot selection to slice 4 and  '-o noupdate'  ensures \
> > it remains that way, while '-n 3' would auto press/choose slice 3 in selection \
> > menu, as human would. Well in that case, better to not show menu at all, thus \
> > only "blic" into slice 3. At next boot it is at slice 4 again.
> 
> I'm afraid this sounds like a great way to make a very confusing
> scenario, where you have to reboot twice to be sure of a consistent
> boot sector, unless I've misunderstood you.
> 
> Chris


Let me put it this way.
'boot0cfg' should continue to behave as it does. Exactly in this form, it is a \
perfect (almost) solution. This means that none of it's current flag shall be edited \
in terms of functionality, thus preserving backward compatibility with everthing.

So, on top of all it's code, we add just a 1 flag which auto selects boot \
option/slice, as human would from it's boot menu. Simple as that. We can call that \
                flag:
    -n nextboot slice
or maybe
    -a (auto)answer

On existing machine with active and booted, i.e; slice 3
# 'boot0cfg -n 1'
     Would upon next power on, instead showing boot menu, simply choose slice 3 to \
boot. Same result as if human would press F3 for slice 3.

Nothing more, nothing else. Simple as that.
It's indirect effect is determined by combination of other already existing flags, \
i.e; '-o noupdate'

In above example without '-o noupdate' it would also make slice 1 active.
Contrary to that, with specified  '-o noupdate' , it would boot slice 1 only once, \
preserving slice 3 as active (all furter boots stick to it)

It is now clearer?


Domagoj Smolčić
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


[prev in list] [next in list] [prev in thread] [next in thread]