Re: Another attempt at S6 init

From: Laurent Bercot <ska-supervision_at_skarnet.org>
Date: Wed, 22 Apr 2015 00:28:38 +0200

On 21/04/2015 23:19, TheOldFellow wrote:
> I am trying to write the init-stage1 script, so (B). The initrd has
> completed by the time it runs, since root is a lvm2 partition /dev
> must be mounted in initrd so that /dev/mapper/'root' can be mounted
> on /. That's the main function of my initrd, incidentally it has to
> mount /sys and /proc to do this.
>
> The script is running after /dev is mounted, but before anything has
> been set up as hotplug.
>
> What I think I have to do is to prepare the logger and execve into
> stage2.

  Right. You only have to do this.
  Do you keep your initrd after pivot_rooting, or do you unmount it ?
  If you keep it, it's a suitable place to put the scandir and the
live service directories. If you don't keep it, you have to create a
tmpfs first.

  Something like this (replace ${TMPFS} with your chosen location) :

----
if { s6-mount -wt tmpfs -o mode=0755,size=67108864 tmpfs ${TMPFS} }
if { s6-hiercopy /img/tmpfs ${TMPFS} }
redirfd -r 0 /dev/null
redirfd -wnb 1 ${TMPFS}/service/s6-svscan-log/fifo
fdmove -c 2 1
s6-envdir /etc/s6-init/env
background
{
   s6-setsid
   redirfd -w 1 ${TMPFS}/service/s6-svscan-log/fifo
   /etc/s6-init/init-stage2
}
unexport !
s6-svscan -t0 ${TMPFS}/service
----
  You don't need to close stdin/stdout/stderr, the redirections will
work fine. The advantage of not closing them is that you'll see the
error message if s6-mount or s6-hiercopy fails.
(I should make it clearer that the "close the standard descriptors"
thing is only useful when you want to change /dev under init's feet,
and you don't need that here.)
  Note that in the script you posted, there was a "s6hiercopy"
instead of "s6-hiercopy". Check that your original script doesn't
include the typo.
  If there's no typo, be aware that this script needs a correct
hierarchy in /img/tmpfs: at least /img/tmpfs/service for the
scandir and the initial services such as s6-svscan-log.
> I have a further problem in that the Kernel Panic obliterates the
> on-screen track, so there is no information about that cause the
> panic.  It would help if there was a 'panic silently' boot switch!
  Try loglevel=0.
  If it doesn't work, try console=null.
  If it doesn't work either, since you have access to your disk at
this point, mount your disk read-write and insert debug instructions
writing to disk and syncing the disk before each line in the script.
  After a crash, reboot with init=/bin/sh and examine the file that
was written to know what the last correctly executed instruction was.
(i.e. printf debugging, boot-style!)
-- 
  Laurent

Received on Tue Apr 21 2015 - 22:28:38 UTC