install: Only remove bootloader dirs from the ESP - #2475
ericcurtin wants to merge 1 commit into
Conversation
In alongside mode (`install to-existing-root`) we currently empty the whole EFI System Partition. However the ESP is frequently shared with content bootc does not manage and cannot recreate. On Apple Silicon the Asahi installer places the stage 2 bootloader (m1n1/boot.bin, which stage 1 chainloads), the device firmware payload (vendorfw/) and the U-Boot EFI variable store (ubootefi.var) on the ESP. Wiping them leaves the machine unable to boot Linux at all and without WiFi/Bluetooth firmware; this was hit while converting a Fedora Asahi Remix install to a bootc image. Only remove the EFI/ and loader/ directories, which are the trees written by bootupd (grub/shim) and systemd-boot and which we are about to reinstall anyway, and preserve everything else. This also resolves the existing TODO about not wiping the ESP. Update the to-existing-root documentation accordingly and add a unit test covering the preserved content. Generated-by: AI
github-actions
Bot
added
area/install
|
This seems like a safer default than what was suggested in the TODO @cgwalters "TODO: we should also support not wiping the ESP." Disclosure: very much not AI writing this comment :) |
| /// the device firmware payload (`vendorfw/`) and the U-Boot EFI variable store | ||
| /// (`ubootefi.var`) on the ESP; wiping them leaves the machine unbootable. | ||
| #[context("Removing bootloader content from EFI system partition")] | ||
| fn clean_esp_bootloader_dirs(efidir: &Dir) -> Result<()> { |
There was a problem hiding this comment.
People might also have custom bootloader config files in ESP/loader. I think we should read the config files and only remove the ones we own and the boot binaries referenced by them.
There was a problem hiding this comment.
Maybe but I wouldn't mind a second opinion on that... For example... Would the pre-existing boot entries be completely broken after this? I'm open to it, but a second opinion could be interesting
There was a problem hiding this comment.
It's more or less related to #2243. I don't think it's a blocker per se, but if we're going the distance to do this, then maybe we should just handle all the cases.
Would the pre-existing boot entries be completely broken after this?
we're deleting the pre-existing boot entries... so, yes.
There was a problem hiding this comment.
Sorry, maybe I didn't explain myself well enough... Even if we left the pre-bootc boot entries around... Would they even boot at that point? Would they even be useful after the conversion to a bootc system? (genuine question, haven't checked how destructive "bootc install to-existing-root" is to userspace, initramfs, kernel, etc. This is useful in Asahi because of the files required above needed to boot, not because of rollback to pre-bootc case)
2 participants
Problem
bootc install to-existing-root(alongside mode) empties the entire EFI System Partition inclean_boot_directories(). The ESP is frequently shared with content bootc does not manage and cannot recreate.Concrete case: converting a Fedora Asahi Remix 43 install on an Apple Silicon Mac mini to
quay.io/fedora-asahi-remix-atomic-desktops/base-atomic:44. The Asahi installer keeps on the ESP:m1n1/boot.bin- stage 2 m1n1 + U-Boot, chainloaded by stage 1 from the Apple boot partition. Without it the machine cannot boot Linux at all.vendorfw/- Apple device firmware (WiFi, Bluetooth, ...) loaded by the Asahi dracut module at boot.ubootefi.var- U-Boot's EFI variable store.asahi/- installer metadata.After the install the ESP contained only
EFI/. The system was only recoverable because a copy of the ESP had been made beforehand. The same class of problem applies to any platform that stores firmware or earlier boot stages on the ESP (U-Boot based SBCs, some Chromebooks, ...).There is already a
// TODO: we should also support not wiping the ESP.at that spot.Change
EFI/andloader/directories from the ESP. These are the trees written by bootupd (shim/grub) and systemd-boot, and they are reinstalled immediately afterwards. Everything else on the ESP is preserved.to-existing-rootdocs, which currently state that/boot/efi"will be reinitialized".test_clean_esp_bootloader_dirs) covering removed vs. preserved content and idempotency.Testing
cargo test -p bootc-lib --lib install::tests::test_clean_esp_bootloader_dirs install::tests::test_remove_all_noxdevpasses (Fedora 44, aarch64).cargo fmt --checkclean.AI disclosure
Generated-by: AI
Per
AGENTS.md, the commit intentionally carries noSigned-off-by; the human submitter will review and add it. The problem was diagnosed and reproduced on real hardware by the submitter; the code change and unit test are LLM generated and were compiled and tested as described above.