Fedora Silverblue 36 will not succesfully deploy after layering packages

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.

2 Likes

Do you get it if you rpm-ostree install --apply-live when you install distrobox (without rebooting)?

Doing an --apply-live does work in the moment, and the status now shows:

State: idle
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`
Deployments:
  fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220813.0 (2022-08-13T00:48:25Z)
               BaseCommit: fe61e57ff1ae2f0788f484e6619e704978ca8dc4df73f1106c4b66cdd8f21f2e
                   Commit: efcd1ee3df0e941ec0ee81ce40f611f811366a6041bef299209cf6073b307a9d
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
                     Diff: 1 added
          LayeredPackages: distrobox

â—Ź fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220813.0 (2022-08-13T00:48:25Z)
             BootedCommit: fe61e57ff1ae2f0788f484e6619e704978ca8dc4df73f1106c4b66cdd8f21f2e
               LiveCommit: efcd1ee3df0e941ec0ee81ce40f611f811366a6041bef299209cf6073b307a9d
                 LiveDiff: 1 added
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
                 Unlocked: transient

  fedora:fedora/36/x86_64/silverblue
                  Version: 36.1.5 (2022-05-04T18:42:06Z)
                   Commit: 16ec3d1166e5281e2deb1beee62e037777bf2d013f82165adf71b7885c5a53f0
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4

distrobox is installed and functional. However after a reboot the status reverts to the same state as before, and the new deployment is gone:

State: idle
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`
Deployments:
â—Ź fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220813.0 (2022-08-13T00:48:25Z)
                   Commit: fe61e57ff1ae2f0788f484e6619e704978ca8dc4df73f1106c4b66cdd8f21f2e
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4

  fedora:fedora/36/x86_64/silverblue
                  Version: 36.1.5 (2022-05-04T18:42:06Z)
                   Commit: 16ec3d1166e5281e2deb1beee62e037777bf2d013f82165adf71b7885c5a53f0
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
1 Like

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.

I’m at the end of my rope with this.

2 Likes

you can bring back grub menu by holding shift during system boot

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.

workaround, update via CLI:
rpm-ostree update
sudo grub2-mkconfig

2 Likes

Looks like we have some similar reports recently. If we keep seeing these, it might be a good candidate for common issues.

https://discussion.fedoraproject.org/t/getting-rpm-ostree-error-cant-rebase-any-thing/76547?u=vwbusguy

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.

2 Likes

same…


❯ rpm-ostree status 
State: idle
Warning: failed to finalize previous deployment
         error: Bootloader write config: grub2-mkconfig: El proceso hijo terminĂł con el cĂłdigo 1
         check `journalctl -b -1 -u ostree-finalize-staged.service`
Deployments:
â—Ź fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220810.0 (2022-08-10T00:46:50Z)
               BaseCommit: 0adbf32421d4bf13c9d691b7ea8019f539f47002988e988078383413bfb73aa5
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
          LayeredPackages: acpid akmod-nvidia gnome-tweaks gparted openssl printer-driver-brlaser starship tailscale
                           terminator xboxdrv xorg-x11-drv-nvidia xorg-x11-drv-nvidia-libs
            LocalPackages: rpmfusion-free-release-36-1.noarch rpmfusion-nonfree-release-36-1.noarch

  fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220803.0 (2022-08-03T00:51:08Z)
               BaseCommit: 92428f2a60603f29cb8ef04b9eba39aefb2c93a07e9035d7cc164709d65dbfaa
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
          LayeredPackages: acpid akmod-nvidia gnome-tweaks gparted openssl printer-driver-brlaser starship tailscale
                           terminator xboxdrv xorg-x11-drv-nvidia xorg-x11-drv-nvidia-libs
            LocalPackages: rpmfusion-free-release-36-1.noarch rpmfusion-nonfree-release-36-1.noarch
1 Like

Could be possibly related to this recently reported bug:

https://bugzilla.redhat.com/show_bug.cgi?id=2118172

4 Likes

I had the same issue. I can confirm that this workaround works. I ran grub2-mkconfig and haven’t had the issue since.

Shame that some users have given up on Silverblue over it. :face_with_diagonal_mouth:

1 Like

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.

2 Likes

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

Yes, I am able to layer new packages without the issue occurring.

2 Likes

Looks like it’s been reported upstream as an rpm-ostree issue. This means it also likely affects Kinoite, IoT, and Fedora CoreOS.

https://github.com/coreos/rpm-ostree/issues/3925

4 Likes

As a work-around, I used the rpm-ostree rollback command. After updating the system and running rpm-ostree status, the warning message is gone.

2 Likes

It sounds like you were able to revert back to before the bug was introduced. I’m curious if you now experience this bug on a future update attempt.

3 Likes

Having the same problem. Was able to fix it by using @fastoslinux’s workaround. Will see if it happens again with next update.

2 Likes