Bad magic number in super-block while trying to open /dev/nvme0n1p4

[reddor]

Hey y'all,

I'm just riding in my new Steam Deck, and I noticed that when I do "sudo su" in the shell I'll get this message:
tune2fs: Bad magic number in super-block while trying to open /dev/nvme0n1p4

I'm not an expert on file systems, but if I understand this right this is a non-issue, as tune2fs is meant for ext and /dev/nvme0n1p4 is btrfs. But am I right though, or is this a precursor for potential issues? At this point I'm just wondering if anybody else is experiencing the same, as I haven't found any posts related to that.

[retrogunner]

That may not be enough information for anyone to help you. My suggestion is to take your entire terminal scollback buffer (minus any passwords, etc.), paste into a "pastebin" service, then place the link here -- else if you paste the whole scrollback here, it will make for some superlong quotes.

Then, we'll be able to see what you entered, what's going on, and what to ask.

[reddor]

Thanks for your reply! It's simple, only "sudo su" is required. No need for a pastebin IMHO, i literally just set a password (via passwd) and enabled & started sshd via systemctl locally before switching to a remote ssh session, otherwise vanilla device.

Either way, I've been digging around further, I think it's caused by the root user's bash.rc script, which gets executed on login and indeed executes tune2fs:

               if tune2fs -l "$root" | grep -q "read-only"
                then
                        read_only=1
                fi
...

When I manually execute tune2fs ($root resolves to /dev/nvme0n1p4), I get the same error:

(A+)(root@steamdeck ~)# tune2fs -l /dev/nvme0n1p4
tune2fs 1.46.5 (30-Dec-2021)
tune2fs: Bad magic number in super-block while trying to open /dev/nvme0n1p4
/dev/nvme0n1p4 contains a btrfs file system labelled 'rootfs'

All this is part of some code that gathers various info to set the shell prompt when working as root.

I assume the "bad magic number" message gets logged to stderr, which is why I'm seeing only that. Either way, I am now 99.9% sure that this is indeed irrelevant and can be ignored safely.

(And thats why open platforms and devices are so super cool! Sorry I'm just extremely hyped about this and might have overreacted when I saw this, expecting the worst. Maybe this post will be useful to someone else running into the same thing.)

Also obvious disclaimer that one should never use root unless they know what they are doing.

[retrogunner]

I would submit that as a bug report. Sure, it may be safely ignored but that's some poor code there - even as a boot.rc script.
* Nothing there is quoted or bracket'd for protection.
* STDERR should be eaten or redirected elsewhere (hrm, maybe `logger` comes to mind.)
* They should never have used a variable called "$root" for indicating the rootfs volume. They could have used $rootfs or $rootfsdev and that would make more sense.
* tune2fs has had a dangerous past at times. Maybe impact your NVMe's life by altering a disk check frequency.

This is a much simpler & safer test -- using 'test' itself -- NOTE, the "[[" should/could be "[" singles -- silly BBCode is eating the tests:

if [[ ! -w ${root} ]]; then read_only=1; fi
# or
if [[ $(test ! -w ${root}") ]]; then read_only=1; fi
# or a bit grosser without a write test
if [[ $(grep ^${root} /proc/mounts | grep ' ro,') ]]; then read_only=1; fi

[notboxbot]

The original

tune2fs -l "$root" | grep -q "read-only"

apparently checks (in a sloppy way) if the ext3/ext4 feature "Force the kernel to mount the file system read-only" is set.
This does *not* mean that the block device itself is write protected - so I don't think checking for this with "test" will work.
Your third way (checking /proc/mounts) should work, though.

[t-dome]

Originally posted by notboxbot:

The original

tune2fs -l "$root" | grep -q "read-only"

apparently checks (in a sloppy way) if the ext3/ext4 feature "Force the kernel to mount the file system read-only" is set.
This does *not* mean that the block device itself is write protected - so I don't think checking for this with "test" will work.
Your third way (checking /proc/mounts) should work, though.

/dev/nvme0n1p4 on the Deck is btrfs.

[notzippy]

Still an issue

[maxRunner]

I think the main problem is it can be a fairly alarming message, we don't like hearing there's a problem with our super block. It is benign though, hopefully they fix it eventually.

[Jake Sully]

Sudo su does two different things. Sudo makes your main account gain root access and su makes you login to local root account. So try doing just Su or sudo don't do sudo and su at the same time.

[maxRunner]

or do sudo -i

[Amarand Agasi]

Issue resolved by the following fix:

partset="${partlabel#rootfs-}"
                if btrfs property get -ts / | grep -q "ro=true"
                then
                        read_only=1

You can re-write that any way you'd like, but the "btrfs" line is correct for btrfs filesystems.

I used "/" because when I run the following command, it only displays the label:

# btrfs property get -td /dev/nvme0n1p4
label=rootfs

But when I run this command, I get a read-only response I can grep for:

# btrfs property get -ts /
ro=true

Anyway...I know this btrfs thing is new.

There may be a way to map / (the root path) to a different variable. Looks like $root really needs to be the /dev/nvme0n1p4 device, for other items in the .bashrc script. Maybe you could create a $rootpath or something, and then replace $root in the original with $rootpath ? Probably. But seeing as we are explicitly testing for root, and the path for root is probably always going to be / - this is fine by me.

If there is a more graceful solution, please feel free to share.

Hope this helps someone!

[Amarand Agasi]

Also, if anyone here has any Linux questions, I've been doing the Unix/Linux thing since the late 80's so.... Be more than happy to help!

[🅳🅴🅽🅶🅺🅴]

Originally posted by Amarand Agasi:

Also, if anyone here has any Linux questions, I've been doing the Unix/Linux thing since the late 80's so.... Be more than happy to help! :anlpsmile:

Hello man!
I don’t understand, please tell me what commands you entered into the terminal or explain more clearly what steps need to be taken to solve this problem. Thank you.