Systemd and containers

Posted Jun 17, 2015 12:26 UTC (Wed) by nix (subscriber, #2304)
In reply to: Systemd and containers by raven667
Parent article: Systemd and containers

Why make an arbitrary limit on the ramdisk to exclude it from being used as a rescue system?

There is a limit: initial ramdisks are not swappable (unlike, say, tmpfs). (This is why they are generally cleaned out and thrown away when switching to the initial root, so as not to waste precious physical RAM).

However, on a rescue disk it's not like you can rely on swap anyway, and on modern systems this is not much of a limit: I've seen ramdisks that contain entire compiler toolchains and even kernel source trees for building needed kernel modules on command. You wouldn't want to keep that lying around in RAM on a general-purpose system (can you imagine how big the initrd/linked in initramfs must be?), but in a rescue disk it's fine.

Systemd and containers

Posted Jun 18, 2015 0:24 UTC (Thu) by cesarb (subscriber, #6266) [Link] (1 responses)

> There is a limit: initial ramdisks are not swappable (unlike, say, tmpfs). (This is why they are generally cleaned out and thrown away when switching to the initial root, so as not to waste precious physical RAM).

I have seen code which switches root to the initramfs and runs a binary from there on shutdown. Wouldn't that mean that the initrd needs to be kept resident all the time?

Systemd and containers

Posted Jun 18, 2015 8:38 UTC (Thu) by mchapman (subscriber, #66589) [Link]

> I have seen code which switches root to the initramfs and runs a binary from there on shutdown. Wouldn't that mean that the initrd needs to be kept resident all the time?

No, the initramfs can be repopulated upon shutdown.

For example, with Dracut this is done by dracut-shutdown.service, which is pulled in by systemd's shutdown.target unit. See https://www.kernel.org/pub/linux/utils/boot/dracut/dracut... for details.