I tried to rebase one of my laptops to Fedora 33 and after running rpm-ostree rebase I got this error message:
error: Checkout fedora-release-identity-basic-33-0.14.noarch: Hardlinking 04/b11055a235f637376c4e8e42ffa8e70c120496b66d601e824691c7b1a0b8fe.file to os-release: File already exists
Any idea how to fix it? I haven’t really touched the base image, no overlays besides the default ones (openh264) and I also ran rpm-ostree overlay reset. It didn’t help.
Can you post your rpm-ostree status and a little bit more logs?
I would also suggest opening a bug report for rpm-ostree.
Output of rpm-ostree status seems normal:
State: busy
Transaction: upgrade (download only)
Initiator: client(id:gnome-software dbus:1.69 unit:gnome-launched-gnome-software-service.desktop-1401.scope uid:1000)
Deployments:
ostree://fedora:fedora/32/x86_64/silverblue
Version: 32.20200914.0 (2020-09-14T13:10:39Z)
BaseCommit: fdc9c18ee729ab5498ac544752de872e61a697828c7c41513ecf6b2916642d1c
GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0
LayeredPackages: fedora-workstation-repositories
ostree://fedora:fedora/32/x86_64/silverblue
Version: 32.20200911.0 (2020-09-11T14:49:09Z)
BaseCommit: c92767dd4aad7917f08b08121c6c59910055572a1a90a10d961463648e962ff6
GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0
LayeredPackages: fedora-workstation-repositories
What other logs should I look at? I’ve never debugged rpm-ostree before, so I don’t know where to look.
It appears that someone else opened an issue about this 3 hours ago.
https://github.com/coreos/rpm-ostree/issues/2231
It was Jirka (eischmann) who did that…; )
Nevertheless, thanks for linking the issue since I am running Silverblue as well.
Lol, I didn’t catch that it was the same person. Attention to detail
I had the same error. I did a rpm-ostree reset and afterwards: rpm-ostree rebase fedora:fedora/33/x86_64/silverblue and now I see in status the new base:
$ rpm-ostree status
State: idle
Deployments:
ostree://fedora:fedora/33/x86_64/silverblue
Version: 33.20200917.n.0 (2020-09-17T08:03:28Z)
Commit: 2e286e6187204c900eba6d123b3d385383c4d1ab0788afbdc6b18a27546374fc
GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0
Diff: 1090 upgraded, 79 downgraded, 38 removed, 63 added
● ostree://fedora:fedora/32/x86_64/silverblue
Version: 32.20200917.0 (2020-09-17T15:45:15Z)
Commit: 55f1a53590df434f652a3e628d51ef222dab007c506cf60713b0c77491f15d28
GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0
ostree://fedora:fedora/32/x86_64/silverblue
Version: 32.20200917.0 (2020-09-17T15:45:15Z)
BaseCommit: 55f1a53590df434f652a3e628d51ef222dab007c506cf60713b0c77491f15d28
GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0
LayeredPackages: fedora-workstation-repositories
ostree://fedora:fedora/32/x86_64/silverblue
Version: 32.20200905.0 (2020-09-05T18:11:38Z)
BaseCommit: 4150be4c9953a25b2ce8dc4197df6e2221014d23d8a162550dc0391ba13d692b
GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0
LayeredPackages: fedora-workstation-repositories
Pinned: yes
**Unfortunately my F33 is not starting. I only see the small Fedora symbol at the bottom and then **
the boot process stops.
Yep, the problem where F33 beta won’t boot is @ https://discussion.fedoraproject.org/t/latest-f33-build-33-20200915-n-0-fails-to-boot/
The issue exists at:
While both selinux and polkit were among the packages updated, the culprit this time was related to an accidental usage of module-based RPMs built for Fedora’s flatpaks leaking into the Silverblue compose. This was a Silverblue-specific issue, as normal Fedora 33 beta is completely fine.
Hopefully it’ll be resolved in the next compose.
(And hopefully we’ll get gating to prevent builds that have broken tests from being released in the future.)
At least with Silverblue, we can roll back to older versions for the time being.
I hit this same (or very similar) hardlinking issue too, but I also had several different versions of Fedora pinned (with ostree admin pin 0) and a lot of overlays (as I do need various packages at system level to test Cockpit on my local machine, instead of having to always rely on VMs).
I unpinned a bunch of commits and did some resets and flipped between versions trying to figure out the boot bug and couldn’t recreate the hardlink issue locally, even with the same package set I previously had.
Version: 33.20200918.n.0 (2020-09-18T08:06:12Z) fixes the not completing boot issue for me.
Can confirm. It boots now on 33.20200918.n.0 (2020-09-18T08:06:12Z).