3 ms·

> 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 comman

> 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?

xfs 8y ago
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) https://en.wikipedia.org/wiki/Dracut_(software)
- AceJohnny2 8y ago
  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?
  - xfs 8y ago
    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.
cmurf 8y ago
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.
thatcks 8y ago
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 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.)
JdeBP 8y ago
Some of this just came up on StackExchange, by coincidence. * https://unix.stackexchange.com/questions/450223/ https://unix.stackexchange.com/questions/450223/
predakanga 8y ago
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-shrink-root-filesystem-without-booting-a-livecd/227318#227318 https://unix.stackexchange.com/questions/226872/how-to-shrin... There's also https://github.com/marcan/takeover.sh https://github.com/marcan/takeover.sh (previously on HN: https://news.ycombinator.com/item?id=13622301 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.

xfs 8y ago

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) https://en.wikipedia.org/wiki/Dracut_(software)

AceJohnny2 8y ago
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?
- xfs 8y ago
  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.

cmurf 8y ago

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.

thatcks 8y ago

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 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.)

JdeBP 8y ago

Some of this just came up on StackExchange, by coincidence. * https://unix.stackexchange.com/questions/450223/ https://unix.stackexchange.com/questions/450223/

predakanga 8y ago

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-shrink-root-filesystem-without-booting-a-livecd/227318#227318 https://unix.stackexchange.com/questions/226872/how-to-shrin... There's also https://github.com/marcan/takeover.sh https://github.com/marcan/takeover.sh (previously on HN: https://news.ycombinator.com/item?id=13622301 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.