KAlright, starting to look into how we can do initramfs better
Kthis interests you @j0rge since you get your rainbow dinosaur for free
KBasically, we need a way to grab the initramfs.img file and modify it
Kas an action or as part of the containerfile
KLooking into a few ways to do this, one concept I have is to mount the .img file and modify it directly
Nare we thinking this would be easier to do as part of the ISO build process?
Nor in the container itself?
Kcontainer itself
Kthis saves the 20+ minutes on bazzite
Kand will help nvidia users if we can load the nvidia driver into initramfs
Kwithout the 20 minute wait
Kalso useful for branding (since we can load our watermark in without rebuilding initramfs)
Kand useful for encryption (Since we can add the tpm/other modules)
Nwould that get rid of the need for using mokutil to load the key?
Kthat would not, that's motherboard -> loaded image
Koutside of initramfs
Kbut it would mean functional encryption with just initramfs-etc
Kand not the full 20+ minute initramfs feature of ostree
Klsinitrduses cpio to do it, so it shouldn't be too hard to copy from that, extract with cpio, and recreate when done making changes
Myou think unpack, inject, repack would be easier than running dracut as part of the build process?
Kthat already happens in bazzite when we install the kernel, but it doesn't pick up our changes
Kworth trying a manual run
MWhere do you all do the kernel stuff right now?
Knear top of our containerfile, installing a new kernel does initramfs
Mit fails to write the image to /boot
Kso it does, haven't bothered w/ it due to us always rebuilding
Kso if we can fix that to write to the proper location and manual-execute
Kthat may be enough
Mhttps://github.com/ublue-os/bazzite/actions/runs/8641069139/job/23690555718#step:11:758
Seems to have a write location in /tmp while building
Seems to have a write location in /tmp while building
Mthat tmp location is where it's doing the copy for microcode in as well.
I'm unsure why boot isn't writeable
I'm unsure why boot isn't writeable
Kthat initramfs file should live in /usr/lib/modules
Kso we could copy it there
Malso complaining about /root (might need to do a bind mount of /var/root to /root. But I think that is just build log of dracut
Myepp you got it. We need to force the location to /lib/modules/$kver/initramfs.img
sha256sum matches on boot and that
sha256sum matches on boot and that
Mfound inside of ostree deploy as wel
Mlooks like it would need a manual run since when called as dracut, it will immediately drop privileges to prevent overwriting
Kyeah that's fine, we'd have to manual run anyway for nvidia builds
Kand it looks like adding the modules we need is trivial now that we use dracut
Knice, this is a W
MLooks like we just use a specified /tmp/dracut for build location. If we manually call as root it will still autocopy to the correct to kernel version as well!
Mso here is my quick idea:
Kcould probably even toss this in libexec in main
Kso everything that builds from it has it available to use
Mwell we won't have AKMODS variable....
Kah true, in that case as a file in main that can be grabbed
KI do that for nvidia drivers by pulling the script from HWE
Kor also in HWE
Monly reason I wouldn't want to put this into libexec is that clients should be using rpm-ostree initramfs at that point or initramfs-etc
since we are going around ostree here
since we are going around ostree here
