search

fedora-silverblue / issue-tracker

Fedora Silverblue issue tracker
https://fedoraproject.org/atomic-desktops/silverblue/
123 stars 3 forks source link

Cannot update silverblue (grub2-mkconfig error) #322

Closed kisccz closed 2 years ago

kisccz commented 2 years ago

Solution

See the article: https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36/

Run:

$ sudo find /boot/efi -exec touch '{}' ';'
$ sudo touch /etc/kernel/cmdline

Then update your system as usual.

Original issue below

This issue tracker is intended only for Silverblue specific issues. We would like to ask you to try to reproduce the issue on a relevant Fedora Workstation release. If you will be able to reproduce there, then please report it in Red Hat Bugzilla or in upstream (preferred for GNOME projects) and not in this issue tracker.

Describe the bug I can't update silverblue. I run rpm-ostree upgrade, then reboot but the update is not implemented. I'm on 36.20220810.0 and want to update to 36.20220812.0

To Reproduce Please describe the steps needed to reproduce the bug:

  1. enter command rpm-ostree upgrade or do it through gnome software
  2. reboot
  3. grub appears with only two options 36.20220810.0 (cuurent version) and 36.20220809.0 (older version), no 36.20220812.0 (version after update)
  4. login, update was not implemented

Expected behavior system to update to newest version 36.20220812.0

Screenshots If applicable, add screenshots to help explain your problem.

OS version:

$ rpm-ostree status -b
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`
BootedDeployment:
● fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220810.0 (2022-08-10T00:46:50Z)
                   Commit: 0adbf32421d4bf13c9d691b7ea8019f539f47002988e988078383413bfb73aa5
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4

Additional context I'm only running silverblue, no dual boot

kisccz commented 2 years ago 
$ journalctl -b -1 -u ostree-finalize-staged.service
Aug 12 14:57:40 host systemd[1]: Finished ostree-finalize-staged.service - OSTree Finalize Staged Deploymen>
Aug 12 14:58:07 host systemd[1]: Stopping ostree-finalize-staged.service - OSTree Finalize Staged Deploymen>
Aug 12 14:58:07 host ostree[5979]: Finalizing staged deployment
Aug 12 14:58:10 host ostree[5979]: Copying /etc changes: 25 modified, 3 removed, 88 added
Aug 12 14:58:10 host ostree[5979]: Copying /etc changes: 25 modified, 3 removed, 88 added
Aug 12 14:58:14 host ostree[5979]: error: Bootloader write config: grub2-mkconfig: Child process exited wit>
Aug 12 14:58:14 host systemd[1]: ostree-finalize-staged.service: Control process exited, code=exited, statu>
Aug 12 14:58:14 host systemd[1]: ostree-finalize-staged.service: Failed with result 'exit-code'.
Aug 12 14:58:14 host systemd[1]: Stopped ostree-finalize-staged.service - OSTree Finalize Staged Deployment.
Aug 12 14:58:14 host systemd[1]: ostree-finalize-staged.service: Consumed 4.975s CPU time.
Zlopez commented 2 years ago

I'm having the same issue with the same ostree image.

bobslept commented 2 years ago

I had the same issue. After some searching I found these issues: https://github.com/coreos/rpm-ostree/issues/3925 https://github.com/coreos/rpm-ostree/issues/3715 https://bugzilla.redhat.com/show_bug.cgi?id=2096192

After that I used the following to fix the issue:

sudo find /boot/efi -exec touch '{}' ';'
rpm-ostree upgrade
sudo ostree admin finalize-staged
systemctl reboot

Edit: Ran into the same issue again today with updating, had to run sudo ostree admin finalize-staged again after upgrade.

Pryka commented 2 years ago

Same issue.

sudo find /boot/efi -exec touch '{}' ';'
rpm-ostree upgrade
sudo ostree admin finalize-staged

did help though.

TheSamsai commented 2 years ago

I ran into the same issue on two separate systems, one running 36.20220810.0 and the other one running 36.20220812.0. Both systems are quite vanilla and I am not running any special kernels on them.

Running

rpm-ostree upgrade
sudo ostree admin finalize-staged

got both updated to 36.20220814.0 successfully.

The somewhat scary thing is that I only noticed the failed update when I was looking at an unrelated issue and noticed the failure in rpm-ostree status. Depending on when and how this gets fixed, Silverblue installations may go without system updates without the user noticing. This might deserve its own issue, but I think there should probably be more notification about failure to update.

bobslept commented 2 years ago

The somewhat scary thing is that I only noticed the failed update when I was looking at an unrelated issue and noticed the failure in rpm-ostree status. Depending on when and how this gets fixed, Silverblue installations may go without system updates without the user noticing. This might deserve its own issue, but I think there should probably be more notification about failure to update.

Yeah I noticed it when I got like 3 times the same packages when upgrading. And was like huh didn't I update those packages already. Very good point.

Zlopez commented 2 years ago

The somewhat scary thing is that I only noticed the failed update when I was looking at an unrelated issue and noticed the failure in rpm-ostree status. Depending on when and how this gets fixed, Silverblue installations may go without system updates without the user noticing. This might deserve its own issue, but I think there should probably be more notification about failure to update.

I agree, I noticed this after 2 days only when trying to layer new package and it wasn't in rpm-ostree status after reboot. And then I found out the error with grub config.

If this means that the current ostree image is corrupted and it couldn't be updated this could lead to systems that will not get any new update without user even noticing this happened.

Pryka commented 2 years ago

The somewhat scary thing is that I only noticed the failed update when I was looking at an unrelated issue and noticed the failure in rpm-ostree status. Depending on when and how this gets fixed, Silverblue installations may go without system updates without the user noticing. This might deserve its own issue, but I think there should probably be more notification about failure to update.

Fully agree, I noticed it on my system only because some folks on Fedora Discord was talking about it, I check it out and boom I was affected also.

tazihad commented 2 years ago

I am facing the same error. Although I can layer other package in 36.1.5 but not with latest version. 

$ rpm-ostree status
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/kinoite
                  Version: 36.20220810.0 (2022-08-10T00:52:28Z)
               BaseCommit: 3ddbe834b41e05e70ae937b37588252643b095ee1bf5865c9c53761ddec65398
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
          LayeredPackages: akmod-nvidia rpmfusion-free-release rpmfusion-nonfree-release xorg-x11-drv-nvidia-cuda

  fedora:fedora/36/x86_64/kinoite
                  Version: 36.1.5 (2022-05-04T18:46:01Z)
               BaseCommit: b1f915998a6d923c1a9180b7a3f68ab779359429b56a7abda27c37cb8064da58
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
          LayeredPackages: akmod-nvidia xorg-x11-drv-nvidia-cuda
            LocalPackages: rpmfusion-free-release-36-1.noarch rpmfusion-nonfree-release-36-1.noarch

This is the error 

$ journalctl -b -1 -u ostree-finalize-staged.service
Aug 14 18:52:25 fedora systemd[1]: Finished ostree-finalize-staged.service - OSTree Finalize Staged Deployment.
Aug 14 18:58:29 fedora systemd[1]: Stopping ostree-finalize-staged.service - OSTree Finalize Staged Deployment...
Aug 14 18:58:29 fedora ostree[2811]: Finalizing staged deployment
Aug 14 18:58:31 fedora ostree[2811]: Copying /etc changes: 9 modified, 1 removed, 83 added
Aug 14 18:58:31 fedora ostree[2811]: Copying /etc changes: 9 modified, 1 removed, 83 added
Aug 14 18:58:41 fedora ostree[2811]: error: Bootloader write config: grub2-mkconfig: Child process exited with code 1
Aug 14 18:58:41 fedora systemd[1]: ostree-finalize-staged.service: Control process exited, code=exited, status=1/FAILURE
Aug 14 18:58:41 fedora systemd[1]: ostree-finalize-staged.service: Failed with result 'exit-code'.
Aug 14 18:58:41 fedora systemd[1]: Stopped ostree-finalize-staged.service - OSTree Finalize Staged Deployment.
Aug 14 18:58:41 fedora systemd[1]: ostree-finalize-staged.service: Consumed 4.302s CPU time.
benkei-kuruma commented 2 years ago

I posted about this on reddit, but I was able to get around this mysterious issue just now with:

rpm-ostree update
sudo grub2-mkconfig

And that's it. No idea why it worked, but here I am (for now).

rscm commented 2 years ago

same here

will try the workaround

❯ 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

this worked, thanks

mikezila commented 2 years ago

I had the same issue with the same symptoms and error messages at the others in this thread. I tried the proposed fixes and was able to get one instance of updating/layer to take, but trying to then do another deployment failed with the same error as before.

ugurcansayan commented 2 years ago

I had the same issue with the same symptoms and error messages at the others in this thread. I tried the proposed fixes and was able to get one instance of updating/layer to take, but trying to then do another deployment failed with the same error as before.

+1 that. They feel like temporary fixes, aka workarounds. Hopefully this issue will get a fix soon. Good luck

If anyone wants to put those workarounds in a single command, you can use the && notation.

Example-1 from https://github.com/fedora-silverblue/issue-tracker/issues/322#issuecomment-1213295354 sudo find /boot/efi -exec touch '{}' ';' && rpm-ostree upgrade && sudo ostree admin finalize-staged

Example-2 from https://github.com/fedora-silverblue/issue-tracker/issues/322#issuecomment-1214451782 rpm-ostree update && sudo grub2-mkconfig

rpm-ostree update is an alias to rpm-ostree upgrade, so you can interchange them.

Please note that you can also add && systemctl reboot at the end of those lines to make your computer reboot in the end.

xrishox commented 2 years ago

is this bug still present in current deployments or was it just if you grabbed it from like august 10-14?

Zlopez commented 2 years ago

I still see it with 36.20220815.0 (2022-08-15T00:52:34Z).

I'm actually not sure if the update will finish even if the fix is introduced in newer version. If not it potentially means we will have plenty of Silverblue systems, that will just stay on those versions that are broken.

basvdlei commented 2 years ago

Looks like grub is trying to write into a read-only etc and failing.

Added the following drop-in:

# /etc/systemd/system/ostree-finalize-staged.service.d/override.conf
[Service]
Environment=OSTREE_DEBUG_GRUB2=1

After running a rpm-ostree install command and rebooting, the unit will show the error that occurred with grub:

$ journalctl -b -1 -u ostree-finalize-staged.service 
Aug 17 12:16:57 systemd[1]: Finished ostree-finalize-staged.service - OSTree Finalize Staged Deployment.
Aug 17 12:18:37 systemd[1]: Stopping ostree-finalize-staged.service - OSTree Finalize Staged Deployment...
Aug 17 12:18:37 ostree[14815]: Finalizing staged deployment
Aug 17 12:18:37 ostree[14815]: Copying /etc changes: 27 modified, 1 removed, 90 added
Aug 17 12:18:37 ostree[14815]: Copying /etc changes: 27 modified, 1 removed, 90 added
Aug 17 12:18:38 ostree[14882]: Generating grub configuration file ...
Aug 17 12:18:38 ostree[14901]: /etc/grub.d/10_linux: line 167: /etc/kernel/cmdline: Read-only file system
Aug 17 12:18:38 ostree[14815]: error: Bootloader write config: grub2-mkconfig: Child process exited with code 1
Aug 17 12:18:38 systemd[1]: ostree-finalize-staged.service: Control process exited, code=exited, status=1/FAILURE
Aug 17 12:18:38 systemd[1]: ostree-finalize-staged.service: Failed with result 'exit-code'.
Aug 17 12:18:38 systemd[1]: Stopped ostree-finalize-staged.service - OSTree Finalize Staged Deployment.
Aug 17 12:18:38 systemd[1]: ostree-finalize-staged.service: Consumed 1.511s CPU time.

This is the section of 10_linux:

   161      local cmdline="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
   162      local -a files=($(get_sorted_bls))
   163  
   164      if [[ ! -f /etc/kernel/cmdline ]]; then
   165      # anaconda has the correct information to do this during install;
   166      # afterward, grubby will take care of syncing on updates.
   167      echo "$cmdline rhgb quiet" > /etc/kernel/cmdline
   168      fi
   169  
   170      for bls in "${files[@]}"; do

The /etc/kernel/cmdline file does not exist on my machine, maybe creating it is enough?

jlebon commented 2 years ago

OK, this history is messy here, but I think essentially there are two separate GRUB issues at hand. The first was GRUB not handling epoch timestamps on the EFI. This was fixed in grub2-2.06-43.fc36, which is already in the latest Silverblue composes.

The second was introduced more recently by https://github.com/rhboot/grub2/commit/0837dcdf17ac0429bafa4dbf063b2a94385c04ca (i.e. https://github.com/rhboot/grub2/pull/105) and it causes issues on libostree systems because we run grub2-mkconfig with /etc mounted read-only. I proposed a fix for that in https://github.com/rhboot/grub2/pull/106. In the meantime, a workaround as suggested above is to manually touch /etc/kernel/cmdline before updating.

subvert0r commented 2 years ago

I posted about this on reddit, but I was able to get around this mysterious issue just now with:

rpm-ostree update
sudo grub2-mkconfig

And that's it. No idea why it worked, but here I am (for now).

This worked and fixed the issue, but can someone explain WHY this fixes the issue?

jlebon commented 2 years ago

It works because grub2-mkconfig runs outside of the systemd unit which enforces /etc being read-only. See the comment above for more details.

afland commented 2 years ago

It works because grub2-mkconfig runs outside of the systemd unit which enforces /etc being read-only. See the comment above for more details.

So are all existing silverblue systems frozen on the version where this bug first appeared, unless they use one of those manual fixes? Or can a grub update be pushed separate from ostree's system image stuff?

juhp commented 2 years ago

(I don't have any /etc/kernel/cmdline or /etc/efi in my vm.)

rpm-ostree update sudo grub2-mkconfig

Should this be the official workaround? (It worked for me too.) I guess this issue is impacting a lot of users.

(Also fwiw my laptop host was still on 36.20220725.0 and upgraded normally to 36.20220819.0 without a hitch.)

tuomastielinen commented 2 years ago

Is this the right command to update GRUB configuration? sudo grub2-mkconfig -o /etc/grub2.cfg

travier commented 2 years ago

I think we should write a Fedora Magazine article about this issue to give it more visibility and clear workaround instructions. I'll work on it next week.

Edit: https://pagure.io/fedora-magazine-newsroom/issue/135

mo8it commented 2 years ago

@travier I agree with needing an article.

We do also need a test that would prevent this from happening again! I am not an expert, but I can imagine that an issue that prevents you from updating the system is hard (or maybe not possible?) to be fixed without user interaction.

We need an integration test that upgrades a base image (image 1) to image 2, overlays a package on it and see if you then have the latest packages and the overlayed package after the reboot into image 2.

Only if the integration test passes, image 1 should be pushed (not image 2, since it might be the image that breaks upgrading).

travier commented 2 years ago

Yes, I think we all agree that we need more testing for Silverblue. We have those kind of tests in Fedora CoreOS for example, but unfortunately due to the way things are setup right now, we can not copy/paste that for Silverblue.

If folks are interested in contributing to make this happen we can start a new issue and discuss our options.

user1-github commented 2 years ago

It seems todays snapshot is also affected by this issue. I'm currently on 36.20220820.0 which works well, but after I installed todays snapshot (which only updates one package), it still boots into 36.20220820.0 after restart, and the update still appears in Gnome software.

I really don't want to mess with grub configuration in the command line, so will I simply be able to update to a future snapshot that doesn't have this issue?

Edit: I just typed "rpm-ostree status -b" and I don't see any warnings/errors unlike previous reports.

rowbawts commented 2 years ago

It seems todays snapshot is also affected by this issue. I'm currently on 36.20220820.0 which works well, but after I installed todays snapshot (which only updates one package), it still boots into 36.20220820.0 after restart, and the update still appears in Gnome software.

I really don't want to mess with grub configuration in the command line, so will I simply be able to update to a future snapshot that doesn't have this issue?

Edit: I just typed "rpm-ostree status -b" and I don't see any warnings/errors unlike previous reports.

What you can do as a workaround to not have to mess with the command line is rollback to a known good deployment and wait until a fixed snapshot is released and update directly to that one. At least I believe that should work.

andigi89 commented 2 years ago

The workaround works for me - it needs some more commands but at least it solves this issue temporarly.

Pazuu commented 2 years ago

Would it be necessary to inform users via Twitter (and even cooler Mastodon) that their systems are not being updated, that there is a workaround and that it is being investigated?

tazihad commented 2 years ago

@user1-github sudo grub2-mkconfig really don't mess with grub. it just rebuilt the config. rpm-ostree update should have done that for us. So, I say it's a good workaround for now.

And I don't think this is an issue users should fix manually. It will just put silverblue project in bad light.

user1-github commented 2 years ago

@zihadio Yeah, but as I said, if I type ""rpm-ostree status -b", I don't get any grub related warnings/errors unlike what people reported here. BTW, I was on Fedora forums lately and it seems there's a broader issue with rpm-ostree that affects not just Silverblue, so maybe it's related to that.

travier commented 2 years ago

See https://github.com/fedora-silverblue/issue-tracker/issues/322#issuecomment-1221293641 for the draft for a Fedora Magazine article for wider communication. I'm waiting to confirm that the issue is fully fixed and that the commands are enough to fix it.

I don't think we can fix users systems in any way here. All impacted users will have to update with those commands.

KurtSchluss commented 2 years ago

I don't think we can fix users systems in any way here. All impacted users will have to update with those commands.

After a rollback to a previous version with rpm-ostree, I was able to proceed with the normal update process. Does anybody else had the same experience?

user1-github commented 2 years ago

@KurtSchluss Which snapshots have you dealt with? A few days ago I did a clean install of Silverblue and updated directly to Snapshot 36.20220820.0 without any issues. But like I said, now there's Snapshot 36.20220822.0 (which only updates one package) and for some reason it didn't apply after restart, so I'm still on 36.20220820.0.

KurtSchluss commented 2 years ago

@KurtSchluss Which snapshots have you dealt with? A few days ago I did a clean install of Silverblue and updated directly to Snapshot 36.20220820.0 without any issues. But like I said, now there's Snapshot 36.20220822.0 (which only updates one package) and for some reason it didn't apply after restart, so I'm still on 36.20220820.0.

I faced the same issue with 36.20220820.0. After rolling back to 36.20220725.0, I was able to directly update to 36.20220822.0.

sstendahl commented 2 years ago

Just today I did an update using rpm-ostree upgrade without any workarounds, and it got successfully build into grub. For reference, I upgraded from 36.20220822.0 to 36.20220824.0. So it seems the issue has been fixed over here. rpm-ostree status doesn't give any complaints either as it used to do.

user1-github commented 2 years ago

Yeah, so it seems 36.20220822.0 and 36.20220824.0 are unaffected by this issue, but 36.20220820.0 is still affected. I tried updating from 36.20220820.0 to 36.20220824.0 and it still didn't apply. And btw, unlike before, now "rpm-ostree status" does show grub errors. So I'm just going to wait for the Fedora Magazine article.

Edit: Nvm, some also have issues with the latest snapshots.

apevec commented 2 years ago

Upgrade w/o workaround from 36.20220822.0 did not work for me:

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.20220822.0 (2022-08-22T00:51:43Z)
...

And today upgrade fails on fedora-cisco-openh264 repomd mismatch:

Updating metadata for 'fedora-cisco-openh264'... done
error: Loading sack: Updating rpm-md repo 'fedora-cisco-openh264': cannot update repo 'fedora-cisco-openh264': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: Downloading successful, but checksum doesn't match. Calculated: 402d3374ade9cd9a8a35f738f1e215c1962d6aedc411524d2050d359519474f92c3826779ac518773fb44a88f0275981ec24976c7eb845dc775d146a18de1376(sha512)  Expected: eb59e9e7cbde672c4321d25dcc33f5eeadcf48a6bcf3dc97740e51961ce7230e44d1108a8b93b6dabf194d7ec6ac0ee0476c112cdbc65f7e972f22d5370c89bb(sha512)
travier commented 2 years ago

@apevec The second issue is likely unrelated and should be fixed with a rpm-ostree cleanup -m and retry.

Edit: See https://github.com/fedora-silverblue/issue-tracker/issues/340

Pryka commented 2 years ago

@apevec The second issue is likely unrelated and fixed with a rpm-ostree cleanup -m and retry.

Same issue with checksum error,

rpm-ostree cleanup -m

is not fixing the problem

Loading sack: Updating rpm-md repo 'fedora-cisco-openh264': cannot update repo 'fedora-cisco-openh264': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: Downloading successful, but checksum doesn't match. Calculated: 402d3374ade9cd9a8a35f738f1e215c1962d6aedc411524d2050d359519474f92c3826779ac518773fb44a88f0275981ec24976c7eb845dc775d146a18de1376(sha512) Expected: eb59e9e7cbde672c4321d25dcc33f5eeadcf48a6bcf3dc97740e51961ce7230e44d1108a8b93b6dabf194d7ec6ac0ee0476c112cdbc65f7e972f22d5370c89bb(sha512)

user1-github commented 2 years ago

@Pryka The last few days I couldn't download openh264 codec from Flathub as well, so maybe that's related? (If the RPM repo relies on ciscobinary.openh264.org like Flathub).

travier commented 2 years ago

The second issue is https://github.com/fedora-silverblue/issue-tracker/issues/340

omac777 commented 2 years ago

So I guess I haven't been successfully upgrading these past couple of weeks. I assumed it was. Yes, I've tried a few things mentioned here and in another related mentioned bug related to upgrading and none work for me as of yet.

rpm-ostree status -b
State: idle
BootedDeployment:
● fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220810.0 (2022-08-10T00:46:50Z)
               BaseCommit: 0adbf32421d4bf13c9d691b7ea8019f539f47002988e988078383413bfb73aa5
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
          LayeredPackages: 'c++-gtk-utils-gtk4-devel' 'gcc-c++' 'ImageMagick-c++-devel' 'qt6-*' adwaita-icon-theme-devel alsa-lib-devel autoconf automake avahi-gobject-devel cairo-gobject-devel chromium clang clapper cmake dbus-devel
                           emacs flatpak-builder gcc gdk-pixbuf2-devel gdk-pixbuf2-xlib-devel gh gimp glade glib-devel gnome-video-effects gnonlin graphene-devel gst123 gstreamer1-devel gstreamer1-plugins-bad-free-devel
                           gstreamer1-plugins-bad-free-extras gstreamer1-plugins-bad-free-fluidsynth gstreamer1-plugins-bad-free-wildmidi gstreamer1-plugins-bad-free-zbar gstreamer1-plugins-base-devel gstreamer1-plugins-base-tools
                           gstreamer1-plugins-good-extras gstreamer1-plugins-good-gtk gstreamer1-rtsp-server-devel gstreamer1-svt-av1 gstreamer1-svt-vp9 gstreamer1-vaapi gstreamermm-devel gtk4-devel gtkmm4.0-devel gtkmm4.0-doc ImageMagick
                           ImageMagick-devel ImageMagick-doc libadwaita-devel libgudev-devel libsoup-devel libsoup3-devel libsqlite3x-devel libtoml-devel libxcb-devel lld meld meson mozilla-openh264 openfortivpn openssl1.1-devel
                           poppler-glib-devel python3-jinja2 python3-pygments python3-toml-adapt python3-typogrify qt6-qt3d-examples qt6-qtbase-examples qt6-qtcharts-examples qt6-qtconnectivity-examples qt6-qtdeclarative-examples
                           qt6-qtmultimedia-examples qt6-qtpositioning-examples qt6-qtquick3d-examples qt6-qtwayland-examples remmina svt-av1 tdlib-devel youtube-dl
davidm@carouselYOW 2022-08-25_16:48:41_EDT : ~
apevec commented 2 years ago

2nd issue is resolved, today 36.20220822.0 -> 36.20220826.0 still showed error: Bootloader write config so workaround ostree admin finalize-staged is still needed.

tazihad commented 2 years ago

I still have issues.

[zihad@fedora zihad]$ rpm-ostree status
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/kinoite
                  Version: 36.20220824.0 (2022-08-24T19:36:40Z)
                   Commit: e0ecc9c08472a8aee1c5fbd65611770c3bf36646979f2a00e38bdf8f33e0c2f7
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4

  fedora:fedora/36/x86_64/kinoite
                  Version: 36.1.5 (2022-05-04T18:46:01Z)
                   Commit: b1f915998a6d923c1a9180b7a3f68ab779359429b56a7abda27c37cb8064da58
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
[zihad@fedora zihad]$ rpm-ostree upgrade --check
1 metadata, 0 content objects fetched; 592 B transferred in 5 seconds; 0 bytes content written
Note: --check and --preview may be unreliable.  See https://github.com/coreos/rpm-ostree/issues/1579
AvailableUpdate:
        Version: 36.20220826.0 (2022-08-26T11:23:21Z)
         Commit: 3251822c1b1b66bb8d2cbf55a5d21877df3aa33edb73dc168dcc97c5a5c48a6d
   GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
           Diff: 17 upgraded
[zihad@fedora zihad]$
meisme-dev commented 2 years ago

2nd issue is resolved, today 36.20220822.0 -> 36.20220826.0 still showed error: Bootloader write config so workaround ostree admin finalize-staged is still needed.

Second issue is still not resolved for me, I ended up just uninstalling openh264 temporarily.

cjao commented 2 years ago

See #322 (comment) for the draft for a Fedora Magazine article for wider communication. I'm waiting to confirm that the issue is fully fixed and that the commands are enough to fix it.

I don't think we can fix users systems in any way here. All impacted users will have to update with those commands.

This bug could be fixed pretty easily in Fedora Workstation using a maintainer script since those run as root. Is there something about Silverblue that technically prevents an automated fix?

cjao commented 2 years ago

Does this also affect "clean" ostree-based systems with no layered packages? Would Fedora/Red Hat Core OS systems also be vulnerable?

Verhoeckx commented 2 years ago

I had the same issue and the workaround (sudo ostree admin finalize-staged) did work for me!

meisme-dev commented 2 years ago

I don't get the error anymore, was it fixed?