fedora-silverblue / issue-tracker

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

Initramfs unpacking failed: invalid magic as start of compressed archive #493

Closed 0rzech closed 9 months ago

0rzech commented 9 months ago

Describe the bug

Today I did 38.20230926.0 -> 38.20230927.0 upgrade. After restarting the system, the new deployment doesn't boot. Instead I see the Initramfs unpacking failed: invalid magic as start of compressed archive message and nothing happens after it's printed to the screen. The previous deployment boots fine.

To Reproduce

  1. rpm-ostree upgrade to 38.20230927.0
  2. systemctl reboot

Expected behavior System boots normally.

Screenshots N/A

OS version:

fedora:fedora/38/x86_64/silverblue
                Version: 38.20230927.0 (2023-09-27T02:13:44Z)
             BaseCommit: 84a1d651086ddda05cdcd52167919f11688f7c9283687e97118c1f7336284a66
           GPGSignature: Valid signature by 6A51BBABBA3D5467B6171221809A8D7CEB10B464
                   Diff: 14 upgraded
    RemovedBasePackages: firefox firefox-langpacks 117.0.1-1.fc38
        LayeredPackages: <redacted>

Additional context

Upgraded:
  kernel 6.4.15-200.fc38 -> 6.5.5-200.fc38
  kernel-core 6.4.15-200.fc38 -> 6.5.5-200.fc38
  kernel-modules 6.4.15-200.fc38 -> 6.5.5-200.fc38
  kernel-modules-core 6.4.15-200.fc38 -> 6.5.5-200.fc38
  kernel-modules-extra 6.4.15-200.fc38 -> 6.5.5-200.fc38
  mesa-dri-drivers 23.1.7-1.fc38 -> 23.1.8-1.fc38
  mesa-filesystem 23.1.7-1.fc38 -> 23.1.8-1.fc38
  mesa-libEGL 23.1.7-1.fc38 -> 23.1.8-1.fc38
  mesa-libGL 23.1.7-1.fc38 -> 23.1.8-1.fc38
  mesa-libgbm 23.1.7-1.fc38 -> 23.1.8-1.fc38
  mesa-libglapi 23.1.7-1.fc38 -> 23.1.8-1.fc38
  mesa-libxatracker 23.1.7-1.fc38 -> 23.1.8-1.fc38
  mesa-va-drivers 23.1.7-1.fc38 -> 23.1.8-1.fc38
  mesa-vulkan-drivers 23.1.7-1.fc38 -> 23.1.8-1.fc38

I do not see this problem on another machine upgraded from 38.20230925.0 -> 38.20230927.0, but the other one was installed from newer Silverblue iso and doesn't have non-upgradable Secure Boot dbx problem, for instance.

travier commented 9 months ago

I would recommend cleaning up the offending deployment via rpm-ostree cleanup (see the man pages for the exact option) and re-trying the update.

If you can post your full `rpm-ostree status when booted in the "previous" deployment then we can give you the exact command.

0rzech commented 9 months ago
State: idle
Deployments:
  fedora:fedora/38/x86_64/silverblue
                  Version: 38.20230927.0 (2023-09-27T02:13:44Z)
               BaseCommit: 84a1d651086ddda05cdcd52167919f11688f7c9283687e97118c1f7336284a66
             GPGSignature: Valid signature by 6A51BBABBA3D5467B6171221809A8D7CEB10B464
                     Diff: 14 upgraded
      RemovedBasePackages: firefox firefox-langpacks 117.0.1-1.fc38
          LayeredPackages: <redacted>

● fedora:fedora/38/x86_64/silverblue
                  Version: 38.20230926.0 (2023-09-26T00:51:28Z)
               BaseCommit: 5e160c863556300aa1f62a1173766af62fcd7609c945ff1db9823a9a1347a3ea
             GPGSignature: Valid signature by 6A51BBABBA3D5467B6171221809A8D7CEB10B464
      RemovedBasePackages: firefox firefox-langpacks 117.0.1-1.fc38
          LayeredPackages: <redacted>
                   Pinned: yes

  fedora:fedora/38/x86_64/silverblue
                  Version: 38.20230902.0 (2023-09-02T00:45:49Z)
               BaseCommit: c5d9b531556edf56317b4dff2340a5b279c5713ab2db21ca81b8d717e363227e
             GPGSignature: Valid signature by 6A51BBABBA3D5467B6171221809A8D7CEB10B464
      RemovedBasePackages: firefox firefox-langpacks 117.0-1.fc38
          LayeredPackages: <redacted>
                   Pinned: yes

  fedora:fedora/38/x86_64/silverblue
                  Version: 38.20230907.0 (2023-09-07T00:51:19Z)
               BaseCommit: d6d629ece281bcc3d0c424b08bc0489543b2614c72421971e675f4b72cf92503
             GPGSignature: Valid signature by 6A51BBABBA3D5467B6171221809A8D7CEB10B464
      RemovedBasePackages: firefox firefox-langpacks 117.0-1.fc38
          LayeredPackages: <redacted>
                   Pinned: yes

The order of deployments is weird, because I did some rollbacks and cleanups myself.

0rzech commented 9 months ago

So, what I did was a rollback to non 38.20230927.0 deployment and then after rebooting:

rpm-ostree cleanup --base
rpm-ostree cleanup --pending
rpm-ostree cleanup --rollback
rpm-ostree cleanup --repomd

And after rebooting:

rpm-ostree upgrade

which did not download anything from the Internet, so perhaps these cleanups didn't actually delete downloaded deployment.

And again reboot.

Perhaps I have missed something out?

travier commented 9 months ago

Looks good to me. Did it work this time?

0rzech commented 9 months ago

I think this might've been hw problem. It looks like I had a GPU sag and after adding GPU support the system booted fine. Thank you for your help and sorry for the confusion!