Repository navigation
install: Only remove bootloader dirs from the ESP #2475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
cgwalters
merged 1 commit into
bootc-dev:main
from
ericcurtin:install-preserve-esp-content
Oct 2, 2026
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -16,7 +16,8 @@ | |
| # 3. Three devices, partial ESP: Three disks, ESP on disk1+disk3 only | ||
| # | ||
| # Reboot 2: | ||
| # 4. Single device (no LVM): ESP + root partition on a single disk | ||
| # 4. Single device (no LVM): ESP + root partition on a single disk; | ||
| # also checks that non-bootloader ESP content is preserved | ||
| # 5. No ESP anywhere: Two disks with no ESP; install should fail gracefully | ||
| # | ||
| # This validates the fix for https://github.com/bootc-dev/bootc/issues/481 | ||
|
|
@@ -157,6 +158,17 @@ def validate_esp [esp_partition: string] { | |
| } | ||
| } | ||
|
|
||
| # Mount an ESP partition, run a closure on the mountpoint, and unmount it | ||
| def with_esp [esp_partition: string, f: closure] { | ||
| let esp_mount = "/var/mnt/esp_seed" | ||
| mkdir $esp_mount | ||
| mount $esp_partition $esp_mount | ||
| let r = (do $f $esp_mount) | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Eh it's just a test in a throwaway VM |
||
| umount $esp_mount | ||
| rmdir $esp_mount | ||
| $r | ||
| } | ||
|
|
||
| # Run bootc install to-existing-root from within the container image under test | ||
| def run_install [mountpoint: string] { | ||
| (podman run | ||
|
|
@@ -356,8 +368,15 @@ def test_single_device_no_lvm [] { | |
| mkdir $mountpoint | ||
| mount $"($loop1)p2" $mountpoint | ||
|
|
||
| # Create boot directory | ||
| mkdir $"($mountpoint)/boot" | ||
| # Create /boot/efi so the ESP gets mounted and cleaned | ||
| mkdir $"($mountpoint)/boot/efi" | ||
|
|
||
| # Seed non-bootloader content (as on Asahi) and a stale bootloader dir | ||
| with_esp $"($loop1)p1" {|esp| | ||
| mkdir $"($esp)/m1n1" $"($esp)/EFI/stale" | ||
| "m1n1" | save $"($esp)/m1n1/boot.bin" | ||
| "stale" | save $"($esp)/EFI/stale/x.efi" | ||
| } | ||
|
|
||
| # Show block device hierarchy | ||
| lsblk --pairs --paths --inverse --output NAME,TYPE $"($loop1)p2" | ||
|
|
@@ -366,6 +385,12 @@ def test_single_device_no_lvm [] { | |
|
|
||
| # Validate ESP was installed correctly | ||
| validate_esp $"($loop1)p1" | ||
| let r = (with_esp $"($loop1)p1" {|esp| { | ||
| m1n1: ($"($esp)/m1n1/boot.bin" | path exists) | ||
| stale: ($"($esp)/EFI/stale" | path exists) | ||
| }}) | ||
| assert $r.m1n1 "m1n1/boot.bin was removed from the ESP" | ||
| assert (not $r.stale) "EFI/stale was not removed from the ESP" | ||
| } catch {|e| | ||
| cleanup_simple $loop1 $mountpoint | ||
| rm -f $disk1 | ||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
we're deleting the pre-existing boot entries... so, yes.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we leave both the
.conffile and the PE binary it points to, inside of the ESP, then there's no reason why that entry won't work. These entries probably won't be booting a kernel but maybe could be something firmware relatedThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed it'd be better, but keeping this PR minimal; added a TODO referencing #2243 to be more selective within
EFI/andloader/as a follow-up.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me