aborting at stage 1?

aborting at stage 1?

[Jorge Almeida]

What happens if some vital init task fails? Suppose that checking the
root filesystem fails. The system should halt, but how to do it? If the
script ends with "init 0" in case the previous steps fail, then some
changes must be made in /etc/runit, according to the man page of
runit-init. But if the root file system is mounted read-only...

-- 
Jorge Almeida

Re: aborting at stage 1?

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

* Jorge Almeida <jalmeida@math.ist.utl.pt> [2007-04-28 13:20:21 +0100]:

>What happens if some vital init task fails? Suppose that checking the
>root filesystem fails. The system should halt, but how to do it? If the
>script ends with "init 0" in case the previous steps fail, then some
>changes must be made in /etc/runit, according to the man page of
>runit-init. But if the root file system is mounted read-only...

This has pretty much nothing to do with runit.  For instance, my
/etc/runit/1 is:

#!/bin/execlineb

/bin/export PATH "/sbin:/bin:/usr/sbin:/usr/bin"

# run the traditional startup services
/bin/foreground { /sbin/rc 1 }

# create the stopit and reboot files for runit and chmod them appropriately
/bin/foreground { /bin/touch /etc/runit/stopit }
/bin/foreground { /bin/touch /etc/runit/reboot }

/bin/foreground { /bin/chmod 0 /etc/runit/stopit }
/bin/foreground { /bin/chmod 0 /etc/runit/reboot }

# remove /sbin/runit.old if it's found; that indicates runit was upgraded
/bin/foreground { /bin/if { /usr/bin/test -f /sbin/runit.old } /bin/rm -f /sbin/runit.old }

/bin/foreground { /bin/echo }


The important thing here is the call to /sbin/rc, which handles all the
initial setup, mounting, etc.  It's a little too big to paste here, but
you can view it here:

http://svn.annvix.org/cgi-bin/viewvc.cgi/tools/runit/trunk/init/rc?revision=616&view=markup

If something fatal happens, it's up to rc to deal with it.  It will
halt, reboot, drop to a console, etc. before stage 1 can complete if
there are problems.

Handling that stuff is pretty much outside the scope of runit itself...
runit gives you the power to do things, but it's up to you to handle
them gracefully.  =)  No different than SysVinit really.

FWIW, runit-init is installed as /sbin/init here.

-- 
Vincent Danen @ http://linsec.ca/

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

Re: aborting at stage 1?

[Jorge Almeida]

On Sat, 28 Apr 2007, Vincent Danen wrote:

> * Jorge Almeida <jalmeida@math.ist.utl.pt> [2007-04-28 13:20:21 +0100]:
>
>> What happens if some vital init task fails? Suppose that checking the
>> root filesystem fails. The system should halt, but how to do it? If the
>> script ends with "init 0" in case the previous steps fail, then some
>> changes must be made in /etc/runit, according to the man page of
>> runit-init. But if the root file system is mounted read-only...
>
> This has pretty much nothing to do with runit.  For instance, my
> /etc/runit/1 is:
>
Thank you for your reply, but I'm kind of lost here. The system I'm
trying to setup is LFS. I don't want to use general boot scripts, I'm
trying to keep the boot scripts (i.e., stages 1 and 3 scripts) simple
and customized to my system (sacrifying generality). I noticed that the
rc script in the link you provided uses /sbin/halt. In my Gentoo system,
/sbin/halt belongs to the sysvinit package, so I suppose it will not be
available in a sysvinit-free, pure runit, system. Is this correct? If
so, the point is how to halt the system during stage 1 when something
goes wrong and the root filesystem is not writable. From what I
understood of the runit man pages, the only way to halt the computer
when something goes wrong during stage 1 is to have the script
/etc/runit/1 to issue "init 0". This will jump over stage 2 but will go
to stage 3, which will need the root filesystem to be writable.

Thanks.

Jorge Almeida

Re: aborting at stage 1?

[Mike Buland]

On Saturday 28 April 2007 01:34:23 pm Jorge Almeida wrote:
> On Sat, 28 Apr 2007, Vincent Danen wrote:
> > * Jorge Almeida <jalmeida@math.ist.utl.pt> [2007-04-28 13:20:21 +0100]:
> >> What happens if some vital init task fails? Suppose that checking the
> >> root filesystem fails. The system should halt, but how to do it? If the
> >> script ends with "init 0" in case the previous steps fail, then some
> >> changes must be made in /etc/runit, according to the man page of
> >> runit-init. But if the root file system is mounted read-only...
> >
> > This has pretty much nothing to do with runit.  For instance, my
> > /etc/runit/1 is:
>
> Thank you for your reply, but I'm kind of lost here. The system I'm
> trying to setup is LFS. I don't want to use general boot scripts, I'm
> trying to keep the boot scripts (i.e., stages 1 and 3 scripts) simple
> and customized to my system (sacrifying generality). I noticed that the
> rc script in the link you provided uses /sbin/halt. In my Gentoo system,
> /sbin/halt belongs to the sysvinit package, so I suppose it will not be
> available in a sysvinit-free, pure runit, system. Is this correct? If
> so, the point is how to halt the system during stage 1 when something
> goes wrong and the root filesystem is not writable. From what I
> understood of the runit man pages, the only way to halt the computer
> when something goes wrong during stage 1 is to have the script
> /etc/runit/1 to issue "init 0". This will jump over stage 2 but will go
> to stage 3, which will need the root filesystem to be writable.
>
> Thanks.
>
> Jorge Almeida

I've been an LFS guy for quite a while now, and if you want any extra help 
with system setup feel free to send me an e-mail.  As far as halt goes, it is 
part of the sysvinit package, but so are a lot of other pretty important base 
components, checking my paco log it has mountpoint, pidof, halt, killall5, 
poweroff, reboot, shutdown, sulogin, telinit, last, lastb, mesg, utmpdump, 
and wall.  You can always install it and then get rid of the couple programs 
you're not going to use, but init only takes up 32k stripped on my system.

On my machine I setup runit to use the sysv style rc sysinit to begin with, 
it's really very easy, and you can always clean up the scripts that you don't 
need once you get it all working.

Like I say, if you want more info about cleaning this up or working with LFS, 
let me know.

--Mike

Re: aborting at stage 1?

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 2931 bytes --]

* Mike Buland <mike@geekgene.com> [2007-04-28 18:22:22 -0600]:

>> On Sat, 28 Apr 2007, Vincent Danen wrote:
>> > * Jorge Almeida <jalmeida@math.ist.utl.pt> [2007-04-28 13:20:21 +0100]:
>> >> What happens if some vital init task fails? Suppose that checking the
>> >> root filesystem fails. The system should halt, but how to do it? If the
>> >> script ends with "init 0" in case the previous steps fail, then some
>> >> changes must be made in /etc/runit, according to the man page of
>> >> runit-init. But if the root file system is mounted read-only...
>> >
>> > This has pretty much nothing to do with runit.  For instance, my
>> > /etc/runit/1 is:
>>
>> Thank you for your reply, but I'm kind of lost here. The system I'm
>> trying to setup is LFS. I don't want to use general boot scripts, I'm
>> trying to keep the boot scripts (i.e., stages 1 and 3 scripts) simple
>> and customized to my system (sacrifying generality). I noticed that the
>> rc script in the link you provided uses /sbin/halt. In my Gentoo system,
>> /sbin/halt belongs to the sysvinit package, so I suppose it will not be
>> available in a sysvinit-free, pure runit, system. Is this correct? If
>> so, the point is how to halt the system during stage 1 when something
>> goes wrong and the root filesystem is not writable. From what I
>> understood of the runit man pages, the only way to halt the computer
>> when something goes wrong during stage 1 is to have the script
>> /etc/runit/1 to issue "init 0". This will jump over stage 2 but will go
>> to stage 3, which will need the root filesystem to be writable.
>>
>> Thanks.
>>
>> Jorge Almeida
>
>I've been an LFS guy for quite a while now, and if you want any extra help 
>with system setup feel free to send me an e-mail.  As far as halt goes, it is 
>part of the sysvinit package, but so are a lot of other pretty important base 
>components, checking my paco log it has mountpoint, pidof, halt, killall5, 
>poweroff, reboot, shutdown, sulogin, telinit, last, lastb, mesg, utmpdump, 
>and wall.  You can always install it and then get rid of the couple programs 
>you're not going to use, but init only takes up 32k stripped on my system.
>
>On my machine I setup runit to use the sysv style rc sysinit to begin with, 
>it's really very easy, and you can always clean up the scripts that you don't 
>need once you get it all working.
>
>Like I say, if you want more info about cleaning this up or working with LFS, 
>let me know.

Likewise.  Annvix ships with SysVinit because it does have some pretty
important tools which Mike outlined above.  But I always remove
SysVinit's init program as I find runit better.  So, even though
SysVinit exists and is installed, the init program itself isn't.
There's nothing wrong with this (and you'll be missing a lot of good
tools if you go completely without).

-- 
Vincent Danen @ http://linsec.ca/

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

Re: aborting at stage 1?

[Jorge Almeida]

On Sun, 29 Apr 2007, Vincent Danen wrote:

>
> Likewise.  Annvix ships with SysVinit because it does have some pretty
> important tools which Mike outlined above.  But I always remove
> SysVinit's init program as I find runit better.  So, even though
> SysVinit exists and is installed, the init program itself isn't.
> There's nothing wrong with this (and you'll be missing a lot of good
> tools if you go completely without).
>
I have no problem with keeping sysvinit around.. I just needed
confirmation that a third party "halt" program is needed when it is
necessary to abort stage 1 without mounting the root fs rw.

Thanks.

-- 
Jorge Almeida

Re: aborting at stage 1?

[Gerrit Pape]

On Sat, Apr 28, 2007 at 08:34:23PM +0100, Jorge Almeida wrote:
> On Sat, 28 Apr 2007, Vincent Danen wrote:
> >* Jorge Almeida <jalmeida@math.ist.utl.pt> [2007-04-28 13:20:21 +0100]:
> >>What happens if some vital init task fails? Suppose that checking the
> >>root filesystem fails. The system should halt, but how to do it? If the
> >>script ends with "init 0" in case the previous steps fail, then some
> >>changes must be made in /etc/runit, according to the man page of
> >>runit-init. But if the root file system is mounted read-only...
> >
> >This has pretty much nothing to do with runit.  For instance, my
> >/etc/runit/1 is:
> >
> Thank you for your reply, but I'm kind of lost here. The system I'm
> trying to setup is LFS. I don't want to use general boot scripts, I'm
> trying to keep the boot scripts (i.e., stages 1 and 3 scripts) simple
> and customized to my system (sacrifying generality). I noticed that the
> rc script in the link you provided uses /sbin/halt. In my Gentoo system,
> /sbin/halt belongs to the sysvinit package, so I suppose it will not be
> available in a sysvinit-free, pure runit, system. Is this correct? If
> so, the point is how to halt the system during stage 1 when something
> goes wrong and the root filesystem is not writable. From what I
> understood of the runit man pages, the only way to halt the computer
> when something goes wrong during stage 1 is to have the script
> /etc/runit/1 to issue "init 0". This will jump over stage 2 but will go
> to stage 3, which will need the root filesystem to be writable.

Hi,

if something goes wrong in stage 1, the /etc/runit/1 script should exit
100.  runit will then skip stage 2, and enter stage 3, see runit(8).
Possibly some things in stage 3 won't work if the root fs is mounted
read-only, but finally /etc/runit/3 will exit, and runit will either
halt or reboot after looking at /etc/runit/reboot.  For read-only
filesystems, runit supports /etc/runit/reboot being a symlink, even a
dangling one, which can point into a ramdisk mount point.  This applies
to all files/directories the runit programs need write access to BTW, if
not, I'd consider it as a bug.

HTH, Gerrit.

Re: aborting at stage 1?

[Jorge Almeida]

On Tue, 19 Jun 2007, Gerrit Pape wrote:

>
> Hi,
>
> if something goes wrong in stage 1, the /etc/runit/1 script should exit
> 100.  runit will then skip stage 2, and enter stage 3, see runit(8).
> Possibly some things in stage 3 won't work if the root fs is mounted
> read-only, but finally /etc/runit/3 will exit, and runit will either
> halt or reboot after looking at /etc/runit/reboot.  For read-only
> filesystems, runit supports /etc/runit/reboot being a symlink, even a
> dangling one, which can point into a ramdisk mount point.  This applies
I suppose one can even do without the ramdisk by mounting an appropriate
"static" file over /etc/runit/reboot, with -o remount.

A thing that doesn't seem to play well with a pure-runit approach is
udevd. Maybe a solution would be to create a few static devices (the
ones needed for a particular system) and then run udevd as a stage 2
service, to take care of things like pen drives and such. (Just some
thoughts...)
> HTH, Gerrit.
>
>
Thanks,

Jorge