NNvidia users will praise you if we can ship 555.
Ball i really want is more praise
wait... is that intrinsic or extrinsic?
wait... is that intrinsic or extrinsic?
JDo what must be done, Lord Vader.
LDo not hesitate, show no mercy
Bi hate sand
F@M2 Why is
Apparently, Fedora uses
https://fedoraproject.org/wiki/Features/DracutHostOnly
-no-hostonly used for dracut on initramfs regeneration for Bluefin?Apparently, Fedora uses
hostonly initramfs since F19https://fedoraproject.org/wiki/Features/DracutHostOnly
MHost only only includes the modules necessary to boot the machine that generated the initramfs.
MSo.... Most people likely won't be able to boot and won't have things like a working keyboard
Fohh, makes sense
FJust wanted to ask since this Fedora link caught my eye
MSo it makes sense for locally generated initramfs.
But we cannot make that optimization.
This is also part of the considerations for UKIs right now
But we cannot make that optimization.
This is also part of the considerations for UKIs right now
WWhat's UKI?
Auniversal kernel images
Abundling kernel, initramfs and command line as a distribution
Pfeet
GSo
-no-host-only enables BT (for peripherals in LUKs?), how do we keep rescue mode though?M-no-host-only is rescue mode. It has all of the drivers
GReferring to thisBenefit to Fedora
Less /boot usage. Faster boot and updates. Full fledged rescue mode available
GAh OK. Is there no way to enable only specific Bluetooth modules in dracut for initramfs? Like only for the hardware installed on the computer?
MNot unless you regenerate on host
GAh
GI see, the plan is to generate elsewhere
GYeah that would get tricky with UKI
MWe generate at build time.
Because we do not know target hardware, we have to go with the generic target.
If a user wants a smaller initramfs, they will need to locally generate.
Because we do not know target hardware, we have to go with the generic target.
If a user wants a smaller initramfs, they will need to locally generate.
GBecause you can't just generate another initramfs and plop it on because it needs to be signed with the kernel
MYepp
GYeah that's hard
GTbh I might only support UKI with TPM support, and just leave it at that
MSo we actually have the pieces in place for uki, but rpm-ostree doesn't speak them yet.
MSince we generate initramfs at build time we can create it. But it doesn't know how to plop them down yet.
We also bloated the initramfs to include all of the tpm and other decryption methods
We also bloated the initramfs to include all of the tpm and other decryption methods
GAh
MAnd because UKI is a single blob.... It's huge
GSo that's not good right?
MCorrect
MIt's kernel + initramfs in one EFI executable
MSo for Nvidia people. They will likely only have space for 2 maybe 3 UKIs
GAre the BT drivers bundled too?
MI don't know. If they are not that is something that can/should be added
GIt depends on how big /boot is right?
MUKIs will go into /boot/EFI unless uefi driver is shipped for ext4
MWait. You will still need the pair data which would need to be done on local system so might as well not include bt driver at build time
GAh
GYeah Bluetooth is tricky
GSo a UKI with all of the decryption modules + nvidia is around 200mb?
MYes. Maybe a bit more. And remember that fat32 you lose space
GWell
GUKIs hopefully will make secureboot actually secure and make systems more reliable, seems like a decent tradeoff to me. Maybe by the time they ship UKIs for Silverblue, NVK will be rock solid compared to the proprietary nvidia driver in performance
Abut boot is not efi
Aunless you do one combined partition, it doesnt make sense to use /boot/EFI
