-
Notifications
You must be signed in to change notification settings - Fork 26
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
Adopt fails with error "removing ".btmp.fedora/mmia32.efi": No such file or directory (os error 2)" #762
Comments
Thanks for the reports. Does this mean you have upgraded the OS from older version to Fedora Silverblue 41 latest? Which version are you using for Fedora Silverblue 41? As I remembered, the latest version includes bootloader-update.service, which should automatically update bootloader during booting after upgrade, so you might do not need to update manually. |
Thanks @HuijingHei ! Yes, this was an upgraded system. I have been running Silverblue for a few releases. I updated to the latest Silverblue compose (41.20241105.0 (2024-11-05T00:40:00Z)) and the error has changed:
|
I can not reproduce when I upgrade to 41.20241105.0, maybe there is something different with your env, could you help to output your
|
The listing of |
|
Sorry, forgot this one:
|
Thanks for the testing, this is helpful. Seems the system does not have
We need to ignore the removing if can not find the file, also curious how we could remove |
Thanks @HuijingHei ! I think I might have caused this when fixing a boot error a year or two ago, one of those which had an article in Fedora Magazine. I will wait for the new release. |
Some (arguably broken) EFI systems need 32bits bootloaders binaries to boot an x86_64 one, thus why those are installed by default now in Fedora but may not be on existing systems. In most cases they are indeed not needed but I don't know if there is a way to know for sure. |
So it looks like bootupd should not fail when removing a file if it already does not exist. |
https://github.com/coreos/bootupd/blob/main/src/filetree.rs#L350 looks like this one either should not fail if the file already does not exists or we should test if the file exists before calling it. |
Hello Everybody, I have the same problem! I will give as much information as possible.
sudo bootupctl adopt-and-update -vvvv
sudo systemctl reset-failed bootupd.service
sudo bootupctl status
sudo bootupctl validate
Information about my system:
lsblk
sudo ls -alhR /boot/efi
journalctl -b -u bootloader-update.service --no-page
rpm-ostree status
Hopefully, all the information is helpful! |
The new release rust-bootupd-0.2.25-1.fc41 would fix this issue. |
When can I expect this new package to be available? |
It is still in testing (see https://bodhi.fedoraproject.org/updates/FEDORA-2024-e58e1e6216) and not included in f41 stable yet, you could update bootupd package using |
Mmm, it seem that the new package doesn't solve my problem. My original problem was this: This is what I just did:
As you can see, I still get an error message. When I run:
I get:
My firmware is (seen as) BIOS and not UEFI? Do I need to wait for BIOS support? |
Please open a new issue and provide the output of |
Okay, will do that! |
On a X86-84 system running Fedora Silverblue 41:
The text was updated successfully, but these errors were encountered: