LinuxQuestions.org - Force mount reiserfs partitions in read/write mode on OpenSUSE 15.3

- SUSE / openSUSE (https://www.linuxquestions.org/questions/suse-opensuse-60/)

- - Force mount reiserfs partitions in read/write mode on OpenSUSE 15.3 (https://www.linuxquestions.org/questions/suse-opensuse-60/force-mount-reiserfs-partitions-in-read-write-mode-on-opensuse-15-3-a-4175719701/)

Force mount reiserfs partitions in read/write mode on OpenSUSE 15.3

At some point some jack-ass at SuSE decided for me that I don't need to use reiserfs anymore and pushed out an update that mounts all reiserfs partitions as read only. I've tried editing fstab and doing a manual mount -o remount blah blah but with no luck I cannot get these partitions mounted in write mode.

Anyone know how to get around this?
Thanks in advance.

P.S. Not interested in "migrate to another file system" answers. I have a few PB of data on ReiserFS partitions and I'm not migrating all of that any time soon.

Not a suse nor reiser user in many a long year, but did you happen to get 5.18 recently ?. Are you getting the deprecation message ?.
I wonder if the mount issue is an unintended consequence. Ask 'em. Would have expected others to have noticed by now tho'.

What happens if you roll back to a prior kernel ?.

The 15.3 release notes make it clear reiserfs in supported openSUSE versions is dead. IIRC, reiserfs remains in Knoppix, which means you have a decent live media access option. Note 15.3 support is scheduled for official termination this month. To keep using a supported openSUSE version to access your "few PB of data" as if nothing had changed, you'll need to build a kernel with reiserfs support. openSUSE makes this relatively easy at least conceptually via its Build Service and related tutorial. I have no idea whether or not the current kernel retains a reiserfs build option. Easiest could amount to multibooting 15.2 and latest versions, booting 15.2 for retrieval, latest securely for everything else, a piecemeal approach to migration. Migrating wholesale to a supported filesystem may prove to be the least painful way to maintain access.

I've been using *SUSE since 8.0, but always with EXTx only, shying away from reiserfs, since the beginning as not widely embraced across other distros, later as I learned its full story.

This sucks. All of our file storage servers at our headquarters and in all of our subsidiaries are on ReiserFS file systems because it has proven itself to be absolutely bullet-proof over the many years we've been using it (we've never had a single file system related data loss in all the decades we've been using Reiser). The amount of time (and downtime) required to do a migration of each server will be massive and I can't imagine how I'm going to manage the migration. We're not a big company in the corporate sense, just big in our industry and region. But with a small staff and budget.

It would appear you can do a convert in-place for something like btrfs. Given you are in a corporate environment, your separate/external backups (plural) are of course complete and audited.
Whack some extra disk in place just in case and off you go. No, I haven't tried it, and I bet no-one else has either on PB of reiserfs data. You live on the edge of a crevasse, the ice eventually gives way. That's why you keep all those backups.

Sounds like it's time to bite the bullet.

This 15.3 is an online upgrade from 15.2:

Code:

# inxi -S

System:

  Host: fi965 Kernel: 5.3.18-lp152.41-default arch: x86_64 bits: 64

    Desktop: Trinity v: R14.0.13 Distro: openSUSE Leap 15.3

# uname -r

5.3.18-lp152.41-default

# ls -gG /boot/vmlinuz-5*

-rw-r--r-- 1 10569984 Dec 13 06:48 /boot/vmlinuz-5.3.18-150300.59.106-default

-rw-r--r-- 1  9066752 Jan 24  2022 /boot/vmlinuz-5.3.18-150300.59.43-default

-rw-r--r-- 1  9070848 Mar  7  2022 /boot/vmlinuz-5.3.18-150300.59.54-default

-rw-r--r-- 1  9079040 Jun 17  2022 /boot/vmlinuz-5.3.18-150300.59.76-default

-rw-r--r-- 1 10565888 Aug 10  2022 /boot/vmlinuz-5.3.18-150300.59.90-default

-rw-r--r-- 1  9066720 Oct  7  2021 /boot/vmlinuz-5.3.18-59.27-default

-rw-r--r-- 1  9062624 Nov 24  2021 /boot/vmlinuz-5.3.18-59.37-default

-rw-r--r-- 1  9054144 Jun  4  2021 /boot/vmlinuz-5.3.18-59.5-default

-rw-r--r-- 1  9044208 Sep  4  2020 /boot/vmlinuz-5.3.18-lp152.41-default

Some people report uptimes measured in years, meaning running the same kernel for years without rebooting. Just because you upgrade the distro doesn't mean you're forced to upgrade the kernel. This could buy you some time to come up with and implement a migration plan.

Try as root:

Code:

zypper in reiserfs-kmp-default

Code:

modprobe reiserfs

See:
https://cateee.net/lkddb/web-lkddb/REISERFS_FS.html

Solved it the brute force way

Just FYI.
I resolved this maddening issue by buying a14TB Seagate Express usb 3.2 external drive and backing up each ReiserFS to it, formatting XFS (BTRFS can GTFO) then restoring the data.
Did this for each FS on each server.
Took a lot of days over a couple months.

Big FU to everyone at SuSE that decided to modify MY systems because they think they know what FS I should use.