Fedora Silverblue 36 will not succesfully deploy after layering packages. Using rpm-ostree install to install the package is fine. If you then do an rpm-ostree status before you reboot it will even show the deployment with the packages layered. But upon reboot the new deployment is gone and rpm-ostree status shows this:
Warning: failed to finalize previous deployment
error: Bootloader write config: grub2-mkconfig: Child process exited with code 1
check `journalctl -b -1 -u ostree-finalize-staged.service`
Checking journalctl -b -1 -u ostree-finalize-staged.service as advised returns this:
Aug 13 21:43:44 relic systemd[1]: Finished ostree-finalize-staged.service - OSTree Finalize Staged Deployment.
Aug 13 21:44:08 relic systemd[1]: Stopping ostree-finalize-staged.service - OSTree Finalize Staged Deployment...
Aug 13 21:44:08 relic ostree[4322]: Finalizing staged deployment
Aug 13 21:44:10 relic ostree[4322]: Copying /etc changes: 22 modified, 0 removed, 65 added
Aug 13 21:44:10 relic ostree[4322]: Copying /etc changes: 22 modified, 0 removed, 65 added
Aug 13 21:44:14 relic ostree[4322]: error: Bootloader write config: grub2-mkconfig: Child process exited with code 1
Aug 13 21:44:14 relic systemd[1]: ostree-finalize-staged.service: Control process exited, code=exited, status=1/FAILURE
Aug 13 21:44:14 relic systemd[1]: ostree-finalize-staged.service: Failed with result 'exit-code'.
Aug 13 21:44:14 relic systemd[1]: Stopped ostree-finalize-staged.service - OSTree Finalize Staged Deployment.
Aug 13 21:44:14 relic systemd[1]: ostree-finalize-staged.service: Consumed 4.354s CPU time.
I’m just trying to layer distrobox in this case, but it happens no matter what packages are selected.
I’ve used silverblue in the past and remember getting a bootloader list that shows the available deployements so you can choose a past one to boot if possibe. I don’t get this on the new install. This system used to have normal Fedora on it. I am not sure if that is relevant, but I have a sneaking suspicion it is. I’ve been working on this for a while now, and have totally wiped the disk and even cleared my efi bootloader variables to make sure that everything should be clean and fresh. I have no idea what is causing this.
I get the same issue if I try to enable RPM Fusion using the instructions for silverblue.
Oof. That is so weird. I don’t think I’ve ever encountered this, personally. The closest I’ve seen is when an update was staged, I needed to reboot to install something else once.
I think I may have discovered a clue. I was trying various things after reinstalling again and was ready to give totally wiping the disk and reinstalling another go when I noticed that the bootloader on my usb install media was mangled and wouldn’t start. I removed it and rebooted, which is when I noticed that I actually did get the grub menu and was able to pick between two deployments. I picked the top one and booted, did an rpm-ostree upgrade and restarted, but ran into the same issue and the same failed deployment. The second boot the grub menu didn’t show again.
Now, after thinking maybe I’ll try the reinstall and just make sure the install media is removed in case it’s causing a problem, I am in the same exact spot. After an initial upgrade no further package layering works and no grub menu is visible. So that wasn’t the issue at all.
I did find some people having similar issues at the github issue tracker, but nobody has a real fix.
That’s good to know. Last time I used silverblue you just saw it every boot, but hiding it unless needed is probably cleaner either way.
I’ve given up on this and gone back to normal Fedora Workstation. I’ll give this another try in a few months, maybe, once whatever this is has been worked out. Maybe when Fedora 37 is released.
I was able to find another user on reddit having a similar issue:
Sadly they have also moved on from silverblue over this issue. There are people on the comments there suggesting fixes, but none of them seem to be true solves, just things that can hide the symptom.
Have you done another deployment since the fix? For example can you layer a package? I tired the posted fix and it did work to let me boot into the new deployment that one time, but future deployments ran into the same problem.
i almost did… and I’m seriously thinking about it
I like the idea but the development of packages and developers don’t think on silverblue
happens with a repo file that uses repo_gpgcheck=1 (like tailscale), it turns google software unusable (a bug report exists). of course there’s a workaround (manually set repo_gpgcheck to 0), but then tailscale can’t be upgraded
now this
everytime that an update arrives … silverblue is an afterthought
