Plasma broken and unable to rebase since yesterday

Aurora
1

I don’t remember when I did it, but my system was on the daily updates and yesterday it got updated to 42.20250424, everything is breaking since then.

  • Plasma crashes every few seconds and comes back, without any logs or error message. Drkonqi is using my cpu at 100% for some reason tho

  • Sometimes I can’t run any programs. If I try them through the terminal, I get this error message: error: Fallo al exportar bpf: System failure beyond the control of libseccomp

  • I can only rebase, specifically, to aurora-hwe-nvidia:42-20250425.1, aurora-hwe-nvidia:42-20250425, and aurora-hwe-nvidia:42-20250423.5. Any other attempt returns a “not enough space on disk”, and the stable image directly says it has an unknown manifest.

  • When using the rebase-helper, on date, I can only see versions from 42.20250423 and newer. Also the GUI rebase from KDE settings always fails, no matter what, because of the space issue.

I have an Asus laptop (A15 FA507RM) with a Nvidia GPU, and my disk has +500GB free, so the space issue must be something else. Any ideas of what could be happening? Am I missing something obvious?

2

Please post the full results of bootc status, thanks!

3

Here

● Booted image: ghcr.io/ublue-os/aurora-hwe-nvidia:42-20250425.1
        Digest: sha256:91750d0cc5f2965d3aad1e78472986f560c807432f27c9eb37ca76fca9dbc950
       Version: latest-42.20250425.1 (2025-04-25 04:57:15 UTC)

  Rollback image: ghcr.io/ublue-os/aurora-hwe-nvidia:42-20250425
          Digest: sha256:452795eb9afcf41c7ddc0817751787a76098bbc268e3bc21a10b8d12e71dd3fa
         Version: latest-42.20250425 (2025-04-25 04:03:52 UTC)
4

can you also show rpm-ostree status -v

5 
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-hwe-nvidia:42-20250425.1 (index: 0)
                   Digest: sha256:91750d0cc5f2965d3aad1e78472986f560c807432f27c9eb37ca76fca9dbc950
                  Version: latest-42.20250425.1 (2025-04-25T04:57:15Z)
                   Commit: 8515dc81647f6adf7a5382b1d745969fb8d7fd0585fae0253f74063447683e2d
                   Staged: no
                StateRoot: default

  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-hwe-nvidia:42-20250425 (index: 1)
                   Digest: sha256:452795eb9afcf41c7ddc0817751787a76098bbc268e3bc21a10b8d12e71dd3fa
                  Version: latest-42.20250425 (2025-04-25T04:03:52Z)
                   Commit: 46b3bb6744b6f78ddbded5635159eec91ea1c81461eeb4fb6ba45b8708bb0772
                StateRoot: default

  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-hwe-nvidia:42-20250423.5 (index: 2)
                   Digest: sha256:6d76eb9ec2890e0c1c452c8c095d619cd7a6f14217781e806b2a47104f6dafd0
                  Version: latest-42.20250423.5 (2025-04-23T18:21:48Z)
                   Commit: 79227c96d318e4a03541476a467556da43e838ca721ca0fd29fd11d9b621469c
                StateRoot: default
6

You have a pinned image.

Your not enough space on disk is referring to /boot being full when attempting to rebased.

1 Like
7

I just unpinned the image and didn’t change anything. Do I have to manually free space on /boot? I’m still new to atomic distros :sweat_smile:

Thanks for the help

8

You can use sudo ostree admin undeploy <index number> to get rid of the older ones (keep one extra that currently works just to be safe)

Then try again

1 Like
9

Rebasing still complained about space, but I could reboot on a new image so I guess it did work. Still can’t seem to go back to stable weekly or daily, only specified versions. I’ll keep looking for a solution because right now every version from the last few days has kde exploding

10

You cant rebase to those as you are on hwe inage. There is only latest available

11

Oh so that’s why I was on latest on the first place. Good to know, so I’ll pin the next good image in case something breaks again. Thanks for all the help

12

I recently had some diskspace issues when rebasing. I was going to the “open” version of nvidia due to the new GPU. I like keeping one recently pinned successful boot as a safety blanket (which might not be necessary) but found I had to get rid of that to able to rebase to the open drivers. While it was mildly uncomfortable, it all worked in the end.

I’d be interested to know, however, if it is easy to expand the size of the boot partition a little to allow for a single pinned image. I’ve checked the discord and searched around a bit but haven’t quite found anything I understand well enough to attempt it. Is there any resource that’s recommended for this?

3 Likes
13

I second this.
I think a bit larger /boot would be better. I’d like to have two, maybe three images in reserve, in case something goes sideways. Oftentimes, sideways isn’t noticed right away.
I guess rebasing to an older image might be a tactic, but I’m not sure how to do that. It also assumes a bootable system.

2 Likes