Rebasing to specific version fails

[cgcomer]

Describe the bug

I've been having issues with Bazzite not updating which may be related to this issue #1239. I have attempted several things including this and this to no avail.

Finally, I decided to attempt to rebase to a specific version of Bazzite (40-stable-20240703).

ccomer@main-bazzite:~$ rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:40-stable-20240703
Pulling manifest: ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:40-stable-20240703
Importing: ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:40-stable-20240703 (digest: sha256:72409340a00bb68365b9863d719c0228c75b08c85073a570a47708625e6a6a6a)
ostree chunk layers already present: 65
custom layers already present: 4
error: Importing: Checking out base commit: Opening content object 77aef39c4ce71b37b26aa6f879f6593872eebf5eeafea29b6ccefb2aaecb79ea: Couldn't find file object '77aef39c4ce71b37b26aa6f879f6593872eebf5eeafea29b6ccefb2aaecb79ea'

As you can see, it immediately failed with an error I can't find good information on.

What did you expect to happen?

To complete a rebase to a specific version of Bazzite stable.

Output of rpm-ostree status

ccomer@main-bazzite:~$ rpm-ostree status
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest: sha256:99cce7eb105cbdc027f1c72399a9ef88458818eeae7a172bbbdc8bb14d2bb22a
                  Version: 40.20240611.0 (2024-06-11T17:00:05Z)
          LayeredPackages: edk2-ovmf qemu virt-manager
            LocalPackages: lact-0.5.4-0.x86_64
                Initramfs: regenerate

Hardware

Operating System: Bazzite 40
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.8.12-301.fsync.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: AMD Radeon RX 6900 XT
Manufacturer: ASUS
Asus Crosshair Hero VIII Wifi
Installed Main Drive: Samsung SSD 970 EVO Plus 2TB NVME (no SMART errors)
BIOS: 4805
Secure Boot: On (despite what Info Center claims)

Extra information or context

Prior attempts to check ostree for errors resulted in the following:
Ostree_Error.txt

comer@main-bazzite:~$ ostree fsck -a --delete
Validating refs...
Validating refs in collections...
Enumerating commits...
Verifying content integrity of 307 commit objects...
fsck objects (1/141729) [             ]   0%In commits c484defc2f9e9e3cb4e096190018702567598b011cdbf894b714f6f0360d8d1d, ba4a4df63a1c1f0fa99c5e0000806050ad9bafa5b3fecd1e2a087dd7471b4cca: fsck content object dbd6f56ad7df7d281fe00effba69a8baf9319eccb9a3fb2dd6ebc79c6ebd2544: Opening content object dbd6f56ad7df7d281fe00effba69a8baf9319eccb9a3fb2dd6ebc79c6ebd2544: openat: Permission denied
Marking commit as partial: c484defc2f9e9e3cb4e096190018702567598b011cdbf894b714f6f0360d8d1d

error: open(state/c484defc2f9e9e3cb4e096190018702567598b011cdbf894b714f6f0360d8d1d.commitpartial): Read-only file system
ccomer@main-bazzite:~$ sudo ostree fsck -a --delete
[sudo] password for ccomer: 
Validating refs...
Validating refs in collections...
Enumerating commits...
Verifying content integrity of 307 commit objects...
fsck objects (141729/141729) [=============] 100%
18 partial commits not verified
error: 18 partial commits from fsck-detected corruption

After another look, it looks like my ostree commit was marked as partial by ostree fsck . How do I get bazzite to repull an updated and complete commit?

[HikariKnight]

Hi @cgcomer sorry for the wait, I have been on vacation and I am now able to look through the issue tracker for a bit.

Not really quite sure how to fix this ostree corruption. Also you ended up getting this issue at a bad timing
https://universal-blue.discourse.group/t/important-announcement-regarding-system-updates-action-needed/2689

Essentially all systems before July 2nd will have to do a manual update using the script below as our signing key for the images have changed
curl -sL https://fix.universal-blue.org/ | sudo bash
You can still give the script a shot though anyway even though your error refers to not being able to verify your system commits, but the update might also be failing because of that and the fact the signing key has changed.

So i am unsure it will help in your unique situation, but worth a shot to try it first.
Can you report back when you tried it?

[cgcomer]

I did run the manual update around the same time it was announced, and I remember it mostly going just fine, with one weird error. I don't remember the specifics, just that it didn't trigger me to panic, so it wasn't some critical error. So I just left it alone, and decided to just let the system try to keep itself updated without my intervention.

A couple of weeks ago when I started my computer it booted to grub with two versions of Bazzite again. When I checked the build version it had updated itself like it is supposed to and is currently showing:

rpm-ostree status
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest: sha256:595da95b9a6fb6fe24839e04e7510f115997474b5591711d25fbdc8f55086995
                  Version: 40.20240803.0 (2024-08-03T15:34:43Z)
          LayeredPackages: edk2-ovmf qemu virt-manager
            LocalPackages: lact-0.5.4-0.x86_64
                Initramfs: regenerate

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest: sha256:3afd6dbff34fa7d118d30c4186ec181c0d80ac64d607e09e6923ae6c7d05cd3c
                  Version: 40.20240802.0 (2024-08-02T16:17:11Z)
          LayeredPackages: edk2-ovmf qemu virt-manager
            LocalPackages: lact-0.5.4-0.x86_64
                Initramfs: regenerate

So whatever the problem was it seems to have resolved itself. Though I haven't attempted a manual system update since then either. Also I am not running into issues with Discover updating flatpaks anymore either. Your guess is as good as mine (better probably).