Warning: The root device is not configured to be mounted read-write!

So…I had a freeze followed by hard reset, now during each boot i see:

Warning: The root device is not configured to be mounted read-write!
It may be fsck’d later.

Any advice on desirable actions?
Since fsck mentioned i assume that something got damaged during this unfortunate clusterfsck :woozy_face:

Journal other than that seems to be normal


Never been in that situation before :upside_down_face:

btw, initial freeze was during watching something on VLC, here’s journal records:

Jan 21 17:51:01 x133-PC kernel: BUG: kernel NULL pointer dereference, address: 0000000000000020
Jan 21 17:51:01 x133-PC kernel: #PF: supervisor read access in kernel mode
Jan 21 17:51:01 x133-PC kernel: #PF: error_code(0x0000) - not-present page
Jan 21 17:51:01 x133-PC kernel: BUG: unable to handle page fault for address: ffffb1d400d69948
Jan 21 17:51:01 x133-PC kernel: #PF: supervisor read access in kernel mode
Jan 21 17:51:01 x133-PC kernel: #PF: error_code(0x0000) - not-present page
Jan 21 17:51:01 x133-PC kernel: Fixing recursive fault but reboot is needed!

:man_shrugging:

Found this:
https://bbs.archlinux.org/viewtopic.php?id=261618

:thinking:

My situation:
LTS kernel
Nvidia proprietary driver
No swap

1 Like
  1. Boot into a recovery shell or a live environment and fsck the partition
  2. Run a drive health check just in case

(I think a recovery shell will mount the partition ro and so allow an fsck…)

1 Like

Never used it before, could you please give an example for appropriate ext4 command?

For that case only system one or other 4 too? :sweat_smile:

fsck /dev/sda1

They can run in parallel, so I’d just check them all.

smartctl --test=long /dev/sda then check smartctl -a /dev/sda

1 Like

Thx, i’ll do that now :+1:

1 Like

Hmmm…Is this normal that fsck for 4 Tb disk takes…1,5 seconds?


smartctl --test=long /dev/sda

Please wait 272 minutes for test to complete

Jesus! :sweat_smile:

Have no time right now for full smart test (will do in the night for system disk, just in case), i’ve canceled it and checked usual smart (all seems fine no bad sectors of failures), but after i’ve done fsck on all disks i still have that warning message on reboot :thinking:

Something else we are missing?


https://bbs.archlinux.org/viewtopic.php?pid=1303683#p1303683

I’ve re-read this post about 6 times already but still don’t understand wtf he means…Language barrier i suppose :frowning:

Quoting falconindy:
“So, if you now include the ‘fsck’ hook in /etc/mkinitcpio.conf and specify neither ‘ro’ or ‘rw’ on your kernel commandline, or explicitly specify ‘ro’, systemd will fsck your root device again. This is why the warning exists”

Guess this is the important part of his post. So i try to simplify this one:
If fsck hook is in your mkinicpio.conf and you specify either “ro” in your kernel commandline
(-> /etc/default/grub) OR nothing (in your kernel commandline)
THEN
systemd will fsck your root device again. This is why the warning exists

Hope this helps. Maybe you check those points on your system

2 Likes

Thx fir translating that to human language :grin:

Ok…Let’s see, now i have:

  • nothing (in your kernel commandline)
    GRUB_CMDLINE_LINUX_DEFAULT="quiet security=apparmor udev.log_priority=3"
    
  • mkinitcpio.conf
    HOOKS=(base udev autodetect modconf block filesystems keyboard keymap fsck)
    

Just in case i’ve update grub - nothing changed, still have the message…

So, what i don’t understand is why it keeps warning then?

My settings haven’t been changed manually whatsoever, so that freeze + hard reset have lead to something like this failure mechanism to auto-fsck root device, but why it keeps bugging me then, even after manual fsck?

Logically i would assume this mechanism should auto-fsck and then shut up with the warning…

Just a shot in the dark … :wink:

How are you mounting the device in /etc/fstab?
Maybe explicitly mounting as rw could help (rw is usually included in the default mount option).

UUID=ebf74332-5a35-422b-9b69-63412f2a6900 / ext4 defaults,noatime 0 1

Yep, default should already include it indeed according to man and archwiki

Explicit rw should help i guess i’ll try soon, but still it looks very wrong to explicitly set this in case failure-
mechanism decides something…

Very weird mechanism

OK, a quick search suggests two possible fixes for your problem.

It seems it’s the other way around. Actually adding rw should stop the warning.

-OR-

  1. Add or change the following grub option and update grub:
    GRUB_ROOT_FS_RO=false
2 Likes

Thx, i’ve seen those, again same question from post above stands - why the hell it happens that way, it’s really weird… :slight_smile:

# Uncomment to ensure that the root filesystem is mounted read-only so that
# systemd-fsck can run the check automatically
GRUB_ROOT_FS_RO=true

btw, according to comment setting it to false is basically bypass the failure-mechanism with auto-fsck completely…That wouldn’t be desirable

You could convert to btrfs, zfs, … no fsck on those filesystems :grinning_face_with_smiling_eyes:

2 Likes

So, adding explicitly rw to:

GRUB_CMDLINE_LINUX_DEFAULT=

Removes the warning

However, when you reboot and remove rw - it still shows warning.
I don’t understand why it works that way, what happened?

I have a feeling that system tells me that something needs to be repaired for defaults to be adequate again, but what?
I’ve runned fsck on all disks already, nothing found, smart is fine…I’ve rebuild grub…

True! Just hiding the message isn’t actually a fix.

2 Likes

I don’t quite understand.
So adding rw works? If you then remove rw afterwards the message is back again?

If so, why not just leave the option in then? You actually do want to mount the device writable anyway, so I don’t see the downside. Fsck can now potentially run on that device and you don’t have the warning message at boot.

Maybe we’ll never know. Or you could just be one of the first noticing this right now.

1 Like

While i agree with your statement here, i still think that is bad as solution, because:

  • I see no logic in what happened at all and why it’s not resolved with just defaults afterwards

  • This doesn’t look like how auto-fsck failure mechanism should work

  • It looks a lot like either bug or system saying something like:

    ok, there were some failure, so i’ve tried (not sure even how to check it?) to auto-fix problem, but now to remove warning regardless you need to set rw or disable whole mechanism

    So i’m afraid that problem is just still actually there :confused:

Hopefully someone else who may had previous experience could clarify what happened and what we maybe missing here…

1 Like