-
Notifications
You must be signed in to change notification settings - Fork 28
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
efi: update the ESP by creating a tmpdir and RENAME_EXCHANGE #669
Conversation
3a7cd83
to
f3bb105
Compare
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.
Thanks for working on this!
src/efi.rs
Outdated
fn esp_path_tmp(&self) -> Result<PathBuf> { | ||
self.ensure_mounted_esp(Path::new("/")) | ||
.map(|v| v.join(".EFI.tmp")) | ||
} |
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.
I think it'd be clearer to have just const TEMP_EFI_DIR: &str = ".EFI.tmp";
or so and use it where needed?
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.
But...related to @travier's comment...it'd be good to try to scope this to the "lowest" directory we need to make the change.
For us that means e.g. we only affect EFI/fedora
for example and not all of EFI
.
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.
The bootupd-state.json
also includes BOOT/BOOTX64.EFI
and BOOT/fbx64.efi
under EFI/
, both are from shim-x64, we might never do the update? Is it necessary to check or just do not care?
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.
I think it should be reasonable to prepare both the new BOOT
and fedora
dirs and then do fedora
first, BOOT
second.
I don't think there is a dependency "across" those folders for the bootloader files, i.e. grub.efi may depend on an update shim.efi from the same folder but not on an update fbx.efy from the BOOT folder.
I'm not sure however.
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.
There were some elements in https://lists.fedoraproject.org/archives/list/[email protected]/thread/VRJ7CRQUZ7SNEDW4AIOHKKJ7TMPTOX5A/
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.
See #669 (comment), will prepare both the new BOOT
and fedora
dirs and then do fedora
first, BOOT
second.
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.
I don't think there is a dependency "across" those folders for the bootloader files, i.e. grub.efi may depend on an update shim.efi from the same folder but not on an update fbx.efy from the BOOT folder.
Hmmmm...this kind of rains on the parade here though given that shim
includes files in these two directories, and we can't update it atomically without updating everything in EFI
, which also includes potentially other files we don't manage.
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.
According to @travier 's suggestion, copy first sub dir as temp (like BOOT/foo
-> BOOT.tmp/foo
) and remember, then do remove/addition/change files in temp dir, finally scan temp and do exchange. I think it might be helpful when we do A/B updates, instead of current updates based on loop updates dirs.
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.
Yes, this just means that shim updates won't be transactional, which is unfortunate as shim is the main one we need to update.
It should be an improvement...but...I'm a bit uncertain about saying it's enough that we unconditionally turn on auto-updates by default?
It feels like shim/grub update infrequently enough that in practice we could just accept the hit today of the non-transactionality and recommend turning on auto-updates in various distros/OSes?
I'd be roughly in favor of doing that in FCOS and fedora bootc today just to start.
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 should be an improvement...but...I'm a bit uncertain about saying it's enough that we unconditionally turn on auto-updates by default?
Not sure, is it necessary to check the shim files integrity (like sha512
) after sync to provide more confidence?
b635467
to
e91cab0
Compare
🤔 |
366b8eb
to
a6c8400
Compare
d033a4e
to
ad56520
Compare
|
We've merged the CI fixes. Can you rebase this one? Thanks |
Sure, updated, thanks! |
79cb3ad
to
3cf8636
Compare
Updating
|
If using |
The problem with copying the entire |
Looks like this needs a rebase now btw |
I should emphasize again: thanks for working on this! My feeling on this though is still very mixed not because of any flaw in your code, but because the structure of shim means we will get splits: #669 (comment) There's also the fact that (again no fault of yours) this is just an inherently subtle problem domain, and while you did add a lot of new unit tests, OTOH, if we mess this up we break people's bootloaders. |
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.
Nevertheless, while I haven't yet truly audited the code, it looks overall sane to me and the newly added tests help, so if you feel confident I am OK moving ahead. Adding my approval.
See Timothée's comment coreos#454 (comment) Reuse `TMP_PREFIX`, logic is like this: - `cp -a fedora .btmp.fedora` - We start with a copy to make sure to keep all other files that we do not explicitly track in bootupd - Update the content of `.btmp.fedora` with the new binaries - Exchange `.btmp.fedora` -> `fedora` - Remove now "old" `.btmp.fedora` If we have a file not in a directory in `EFI`, then we can copy it to `.btmp.foo` and then act on it and finally rename it. No need to copy the entire `EFI`. And use `insert()` instead of `push()` to match `starts_with()` when scanning temp files & dirs. Fixes coreos#454
Thanks @cgwalters and @travier for the grate help and a lot of instructions. |
Thanks for the work here Huijing. Let's get this into Rawhide and test it there on full systems. |
Much appreciated for the help from @travier and @cgwalters ! |
See Timothée's comment #454 (comment)
Reuse
TMP_PREFIX
, logic is like this:cp -a fedora .btmp.fedora
that we do not explicitly track in bootupd
.btmp.fedora
with the new binaries.btmp.fedora
->fedora
.btmp.fedora
If we have a file not in a directory in
EFI
, then we can copyit to
.btmp.foo
and then act on it and finally rename it. Noneed to copy the entire
EFI
.Additional info for the logic:
have a file not in a directory, remove it directly
dir; if have a file not in a directory, copy as temp file
And use
insert()
instead ofpush()
to matchstarts_with()
when scanning temp files & dirs.
Fixes #454
filetree: add failpoint when doing exchange
Inspired by #669 (comment)