Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

> How the initramfs /init pivots into running your real system's init daemon on your real system's root filesystem is beyond the scope of this entry. The commands may be simple (systemd just runs 'systemctl switch-root'), but how they work is complicated.

Darn, I was actually hoping this would be elaborated on. Does anyone know of other (just as understandable) sources?

View on HN

For switching to the real root filesystem, you want to read about the pivot_root system call, for example http://man7.org/linux/man-pages/man2/pivot_root.2.html (the usage examples in the pivot_root(8) manpage will help).

When the initramfs PID 1 is something simple like a shell script, I believe it just exec's the real root filesystem /sbin/init after the pivot_root and that init starts from scratch. For Linuxes where systemd is the initramfs init, there's a magic internal protocol to let a running systemd re-exec a new systemd binary while preserving all of its runtime state; this is used, for example, during systemd package upgrades and can be done deliberately with 'systemctl daemon-reexec'.

(I'm the author of the original entry.)

If you're interested in the userspace machinations, as opposed to what goes on in the kernel, there's a great rundown on this StackOverflow answer: https://unix.stackexchange.com/questions/226872/how-to-shrin...

There's also https://github.com/marcan/takeover.sh (previously on HN: https://news.ycombinator.com/item?id=13622301)

Both of these share a similar premise - set up and transfer control to an in-memory root filesystem, in order to make major changes to the real root filesystem.

You can boot with two additional boot parameters:

    systemd.log_level=debug rd.debug

That will get you very verbose logging to the journal, it'll include all the dracut stuff, and systemd setting up jobs and going through all sorts of logic. To read the result:

    sudo journalctl -b -o short-monotonic

I prefer monotonic time even though with these two boot options the startup will be significantly slower, it'll give you a better idea of the relative cost of everything than date/time.

Some of this just came up on StackExchange, by coincidence.

* https://unix.stackexchange.com/questions/450223/

dracut does the work. The reason it is complicated is because it supports booting from btrfs, DM RAID, MD RAID, LVM2, device mapper multipath I/O, dm-crypt, cifs, FCoE, iSCSI, NBD and NFS.

https://en.wikipedia.org/wiki/Dracut_(software)

Hm, Dracut looks like a userspace framework for building initramfs. I was wondering more about what's going on at the kernel level to switch the root. What depends on / ? Do any processes survive whose CWD is in the initramfs? Later in the article it's pointed out that systemd(from initramfs) passes the torch to systemd(in final root) while preserving state, so are any processes/ressources from the initramfs leftover or is everything cleared?

A process spawned from initramfs can certainly live on but you wouldn't want to do that because that would prevent initramfs from being unmounted. By switching to the new root you can run real binaries. You can also not switch the root and also run real binaries from the new mount but that's not very convenient is it?

Pivoting root is not the complicated. The complicated is the process of detecting and setting up the real root filesystem which can involve loading kernel modules to dhcp negotiation to http requests and more. Dracut handles all these.

Reply on news.ycombinator.com