Support getting init from a client #5

Closed
paradigm opened this Issue May 22, 2014 · 4 comments

Projects

None yet

1 participant

@paradigm
Member

Bedrock Linux should support getting an init from a client. There are a number
of things that make this tricky, but it does seem like it might be possible.

Various thoughts:

/sbin/init, the first process run, should be a Bedrock Linux program. It
will likely be a shell script. This will read some configuration to
determine which init the user desires from which client and then proceeds to
do setup work for that particular init. The setup work will do things such as:

  • Standardize existing mount points to be what the target init process expects
    the initrd to have created.
  • Do setup work the target init may not do, such as setup the core and/or other
    clients.

When Bedrock Linux's /sbin/init finishes setup, it will exec() to brc which
then exec()'s the target init. Using the exec()s for this is important
because some inits, most notably systemd, require being PID1. When performing
an exec() the PID does not change between the parent and new executable -
they're effectively the same process.

It may be necessary to have the target init call something to finalize
bedrock-specific setup when the target init's one-time setup is done, if that
type of thing could not be done by Bedrock's /sbin/init before hand without
messing up the target init.

It may be useful to have /sbin/init start a getty in an unusual place, such as
TTY9, as a fall back in case the client init fails. We may want to wrap this
getty in a loop so it automatically restarts.

Once implicit path pinning is setup, that should ensure the target init's
commands - such as systemctl - are provided by the exact same client providing
the init.

It may be wise to have brs refuse, or at least warn, about disabling the client
providing init, as that will likely crash the entire system.

@paradigm paradigm changed the title from Improve init to Support getting init from a client Jun 19, 2014
@paradigm
Member

I have successfully booted Bedrock Linux using systemd from an Arch Linux client. systemctl shows everything started correctly, and everything, both systemd- and bedrock-specific, seems to be working fine. Things like suspending when a laptop's lid is closed "just work". Various utilities may have to be at least partially re-written to support some changes this requires. Minimal testing has thus far been done for other init systems; however, systemd seems to be both the pickiest and most difficult to debug, and so if systemd is working it is very likely the others will fall in line with less work.

@paradigm
Member

I have successfully booted Bedrock Linux using the inits from Arch (systemd), Debian (sysv), and Ubuntu (upstart). Everything works as expected. While I have not yet tested other init systems such as openrc, it seems this general strategy works.

The only issues with the strategy which are currently evident:

  • There may be (harmless) warnings during boot about pre-existing mount points. For example, Debian Wheezy's boot sees mounts (presumably through /etc/mtab, or /proc/mounts or /proc/1/mounts) from other clients which are not accessible from its point of view of the filesystem. It warns about these.
  • The various init systems are probably not umounting mount points in other clients on shutdown. It may be necessary to hook into each init system to run Bedrock Linux umount code on shutdown.
@paradigm
Member
paradigm commented Jul 4, 2014

The cleanest solution to the mount point issues discussed above is to
pivot_root so that the client which provides init will be on the "real root"
in the global/primary/default mount namespace. It will then be able to see all
of the other mount points on the system and be able to unmount them on
shutdown.

Side effects of this strategy:

  • Currently, many Bedrock Linux utilities assume the "real root" is
    bedrock-as-a-client/global. They will have to be rewritten so that they are
    more flexible in this regard. Various utilities will need changes, such as:
    • Many things will differ at runtime depending on the output of bri -p 1.
      We may want to find a way to optimize this as much as possible. Perhaps
      this information could be cached during pre-boot in some location other
      utilities will be able to read.
    • brs will need to be more flexible about where exactly the mount points it
      places are. This should be relatively easy - it will just populate then
      use variables for both ends of the bind mounts rather than hard code things
      based on assumptions.
    • The paths brp uses may also need some changes. brs may bind mount the
      directory onto which brp is placed elsewhere to give brp easy access to the
      local versions of the files - perhaps a
      /bedrock/var/brp-local//etc/ directory.
    • brc will need to chroot() into a different location depending on which
      client is providing PID1.
  • This idea
    of moving everything out of the "real root" will, depending on your point of
    view, become much more viable. Since the real root changes at boot, it does
    not matter where it is when the partitions are mounted in some other distro.
    All that really matters is that the proper file is placed at /sbin/init and
    that wherever the bootloader is installed it can see what it needs to see.
@paradigm
Member

Done in 1.0beta2 Nyla

@paradigm paradigm closed this Dec 31, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment