#1

Hello!

I’ve been looking through the source for rpm-ostree to figure out how Dracut interacts with OSTree. I haven’t been able to really figure it out. How exactly are they paired? Does Silverblue just layer the new initramfs on top of /usr?

Thanks

#2

See /usr/lib/dracut/modules.d/98ostree/module-setup.sh - this is part of ostree not rpm-ostree.

#3

This installs OSTree into the initramfs. How does dracut then tell OSTree to use this new initramfs instead of the old one? OSTree controlls /boot and gets its initramfs from /usr. Does dracut install there somehow?

#4

dracut is a tool to create an initramfs - it doesn’t handle installing it into boot or adjusting the grub configuration. This is handled directly by the ostree code - see ostree-bootloader-grub2.c. The planned move to the Boot Loader Specification in F30 should make this more robust - the BLS has been the preferred way for ostree to handle booting since the beginning and the grub, etc, code is there as compatibility shims.

#5

I get all of that. Dracut generates the initramfs and puts it into /foo. Then OSTree somehow knows to install the initramfs from /foo and not from /usr/lib/module/KVER/initramfs.img.

What tells OSTree to get the initramfs from a different location? That’s my question

#6

The initrd is actually generated when building the ostree and not on the target system. Because 98ostree/module-setup.sh is present when generating the ostree, the system initrd is created with the right hooks to do the ostree pivot root magic. And that’s the initrd that is used in /boot.

 sudo md5sum /boot/ostree/fedora-workstation-2337b6475f858eb29167353cee4705c0f5f49ab8550ffe37788d4697f3cb3004/initramfs-4.19.4-300.fc29.x86_64.img /usr/lib/modules/`uname -r`/initramfs.img
c9c8afd6f55a1294a0550a4b292435d9  /boot/ostree/fedora-workstation-2337b6475f858eb29167353cee4705c0f5f49ab8550ffe37788d4697f3cb3004/initramfs-4.19.4-300.fc29.x86_64.img
c9c8afd6f55a1294a0550a4b292435d9  /usr/lib/modules/4.19.4-300.fc29.x86_64/initramfs.img

I’m not sure if that answers your question or not.

#7

Is it not possible to generate a new initrd on the target system also?

#8

If you override the kernel package then rpm-ostree has code to rebuild the initrd and put it in the appropriate place in the locally generated commit. It’s still coming from the “system image” - it’s just that the “system image” in that case is generated locally. See https://github.com/projectatomic/rpm-ostree/pull/1346

#9

I see. That makes sense. Thank you!