On Mon, Jan 5, 2015 at 5:03 PM, James Powell <james4591_at_hotmail.com> wrote:
> The initial init bootscript that I'm currently drafting is in execline using the template provided by Laurent. I was going to take the advice on using /bin/sh rather than /bin/execlineb but I recanted that decision due to the fact I wanted the using the FIFO handling execline provides.
>
> My question about stage 1 is as follows for a target system of a PC desktop:
>
> If I am reading things correctly, assumingly, init-stage1 using the template, I only need to correct the paths and include any mounts of virtual kernel file systems not listed as well as get cgroups ready, and stage any core one-time services like copying core service scripts to the service scan directory on the tmpfs, correct, before passing off to init-stage2 to load drivers, start daemons, etc.?
>
Laurent's answers are all great. Here's a few other things that I ran
into when adapting s6-init to run on my laptop (distro kernel and a
desire to not trash my root directory too badly), mostly in the
gotchas category:
1. Depending on your initramfs and your on-disk layout you can skip
mounting proc and sys. I know this is the case with Debian, probably
true elsewhere as well.
2. If you aren't starting udev until init-stage2, you'll need to
manually mknod null and console devices before the "Reopen
stdin/stdout/stderr" comment.
3. You'll need to either symlink /tmp into your tmpfs, mount a tmpfs
on /tmp as part of init-stage1, or remount / to rw before s6-svscan is
loaded. Otherwise the catch-all logger won't be able to do its thing
as written. Same deal with /service, though that one is documented and
expected.
4. If you don't want to have your dev mount in /mnt/tmpfs/dev (mostly
to keep ps output non-ugly and to kind-of stick to the FHS) you'll
need to make sure to manually create /dev/pts after you initially
mount a tmpfs or devtmpfs into /dev. This needs to get done before
starting you hotplug manager. udev mounts a devpts there for you when
started, but if you're running mdel you'll need to mount it yourself.
5. I made a few more classes of services for init-stage2 to copy into
the service directory. Specifically for things that I wanted running
ASAP and were udev agnostic. Those were: syslogd (using s6-ipcserver
and ucspilogd), klogd, cron, and udev. Mostly that was because I
needed udev running (and supervised) before bringing up dbus, and I
wanted to make sure /dev/log had a reader before I started bringing
anything up that might not want to talk to stdout instead (openssh,
I'm looking at you).
6. Lastly, since this was an init replacement on a distro-based
system, I made a script called "oneshots" that init-stage2 runs that
fired off all the fake daemons that get started when you bring up a
Debian system. This is things like checking if you're booting while on
batteries, clearing old sudo privileges, and setting the hostname.
The first four are all things that blew up in my face in one way or
another, usually as early-boot kernel panics but sometimes as just a
lot of junk logged to the console while I was trying to log in.
Everything between the fdclose line and repoening stdin is super
fragile, and since we've unmounted /dev, it's impossible to boot
half-way and then start a shell to find out what exactly went wrong.
Good luck. Barring some experiments back in the summer I never
switched any of my daily-use systems to s6-init. I have virutals that
are s6 top-to-bottom, but that doesn't particularly count.
> Thanks,
> James
>
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Tue Jan 06 2015 - 08:00:11 UTC