On Mon, Jan 5, 2015 at 5:03 PM, James Powell <[email protected]> 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
