Tumbleweed install failed - some btfrs subvolumes mounted RO . Media from 2026-05-19

Background: My tumbleweed system was ‘upgraded’ from booting via grub2 to booting via systemd. Due to bad scripting by opensuse and my too-small-for-systemd /boot partition, it became stuck on Linux 7.0.2 (in spite of installing later kernels).

I decided to do a complete re-install. I overwrote the existing partitions with the non-expert default re-partition scheme of two btfrs partitions, one swap partition, and one EFI parition.

My install media was from two days ago, (I have not tried to pull down a fresh version on the system I’m using to post this report of failure). The new system is unable to finish zypper dup, because /lib/zypper is locked in an RO file system. I can’t delete the look, or change parent directory permissions.

When trying to run use the system , the resulting btfrs root partition “/” and most of its system-related subvolumes are mounted read-only. Things like
zypper lock files can’t be removed, and further updates (via zypper dup) are impossible, because even root is unable to erase lock files and things into /lib or most of /user.

I have started another re-install, and will check whether I can specify that all volumes and subvolumes needing RW permission can assure that during ‘expert’ partitioning. Is this even possible at install time for the subvolume mounts?

I the old days, I could have fixed /etcfstab , but systemd-boot process of filesystem management seems too mysterious 'managed in bad code, rather than files I could fix. Could I maybe fix systemd boot volume mounting errors within files, reached from a “LIVE” startup?

those subvolumes are newly created by the installer.

I have another “smaller” question regarding the default-proposed mounting of the EFI parition at ‘/boot/EFI’ – should that have been /boot’ instead? Some opensuse doco described /boot as the correct mounting for the partition.

in any case. that was also mounted RO, probably making it impossible to add or change boot images to add or prefer newer after later updates (unless scripts for adding new kernels under systmd startup unmounts and then remounts the partition to offer a new kernel image).

KISS - a second shutdown and restart solved the problem.

all filesystems came up as RW, and ‘zypper dup’ was completely successful ((including newer kernel 7.0.9).

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.