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

You saw this?

https://bbs.archlinux.org/viewtopic.php?id=167153

1 Like

Yes, posted #5 before, are you talking about something specific i may have missed?

Sorry crazy morning…I am reading through it now. Of course i have to filter out the normal snarkiness of the posts lol.

3 Likes

That’s just part of 0,01% Arch experience we lack here at EndeavourOS :rofl:
I have really hard time reading this stuff, not because of snarkiness even, but due to some weird language, maybe that’s just me

What do you have (sorry if already posted) on this line in /boot/grub/grub.cfg
linux /boot/vmlinuz-linux root=UUID=b321c71c-efa6-4225-8d97-87d75afe6250 rw quiet loglevel=3 nowatchdog

1 Like

Yep, we already came through this (just quickly scan this and 6 posts below)

That works for removing message, but this is not a solution really if you think about it:confused:

1 Like

Just trying to follow that thread…what about here:

linux	${rel_dirname}/${basename} root=${linux_root_device_thisversion} rw ${args}

in /etc/grub.d/10_linux?

So far looks like an old bug came back not sure…

There is also this…

"In /etc/default there is a grub.pacsave

I have restored this file grub.pacsave as the original grub (rename grub file)

grub-mkconfig -o /boot/grub/grub.cfg

The warning message has disappeared"

I don’t have a .pacsave but there is a grub.bak

  1. /etc/grub.d/_linux

Not sure…need to check more, give me a minute

  1. In /etc/default there is a grub.pacsave

I’ve carefully followed all .pacnew / .pacsave cahnges, besides it happened after freeze so if that would be the case probably i’d see this on each boot after last update, but i haven’t seen this message before mentioned freeze

The last page of that thread talks about this happening from a .pacnew file. i think your freeze was coincidental and the resulting reboot brought out the message.

1 Like

If that meaning 10_linux, then here’s mine:

linux	${rel_dirname}/${basename} root=${linux_root_device_thisversion} ${grub_root_fs_mode} ${args}

What’s yours?

1 Like
linux	${rel_dirname}/${basename} root=${linux_root_device_thisversion} rw ${args}

sorry about the typo yes /etc/grub.d/10_linux

1 Like

That’s interesting…In my other 2 systems i don’t have rw as well, but you have it :thinking:

1 Like

That thread is hard to follow even for me a native english speaker lol some of those people are using testing branch some not…Man i miss @gohlip at times like this lol.

2 Likes

Just checked on an EndeavourOS and pure Arch system. Both have rw in that line as shown by @BONK.

2 Likes

Well…I guess i should follow you then guys, however i really don’t understand what is going on and why things are after freeze as they are :exploding_head:

However, i’m certain that disks and RAM are totally fine

2 Likes

I think you just missed a .pacnew somewhere along the line. Mostly they are harmless until something like this. It is even easier to keep up on them now that we have the handy new button on the welcome app.

Oh and your hardware is fine. From what i can gather from that thread the warning is because your system is fscking itself twice.

2 Likes

Adding rw to /etc/grub.d/10_linux and updating grub removed the message.
I really hope it haven’t removed the auto-fsck on failure features…

I’ve marked @BONK as solution, but thank you all for help, really appreciate it! :penguin:

I really doubt it, since i was using hooks to report pacnew stuff & meld all along :upside_down_face:
But who knows, it’s still possible i guess…

Exactly, my system for some reason just couldn’t be satisfied with fscking itself just once :rofl:

3 Likes

After some reading on the ArchWiki I’ve come to the conclusion that using the rw option on the kernel line is the way to go. It’s the recommended default and should be safe to use.


  1. ArchWiki: Kernel parameters

mkinitcpio uses ro as default value when neither rw or ro is set by the boot loader. Boot loaders may set the value to use, for example GRUB uses rw by default […]

  1. ArchWiki: fsck

Boot time checking

Mechanism

There are two players involved:

  1. mkinitcpio offers you the option to fsck your root file system before mounting it via the fsck hook. If you do this, you should mount root read-write via the appropriate rw kernel parameter.[1]
  2. systemd will fsck all file systems having a fsck pass number greater than 0 (either from /etc/fstab or a user-supplied unit file). For the root file system, it also has to be mounted read-only initially with the kernel parameter ro and only then remounted read-write from fstab (note that the defaults mount option implies rw).

The first option is the recommended default, and what you will end up with if you follow the Installation guide.

  1. mkinitcpio.git

Add an annoying warning in case the root device is fsck’d and about to
be mounted RO.
[…]
# ensure that root is going to be mounted rw. Otherwise, systemd
# might fsck the device again. Annoy the user so that they fix this.
if [ “${rwopt:-ro}” != ‘rw’ ]; then
echo “********************** WARNING *********************"
echo "
"
echo "
The root device is not configured to be mounted "
echo "
read-write! It may be fsck’d again later. "
echo "
*”
echo “*****************************************************”
fi

I especially like the “Annoy the user so that they fix this.” part. At least in your case this seems to work :grin:

3 Likes

WTF!!! :rofl:
They literally just trolled the crap out of me?!

That was not straightforward at all…

2 Likes

Nah more like…

2 Likes