root device not read-write warning

cfr · 2013-08-15 22:01:32

markg85 wrote:

I tried every single solution provided in this thread. The message is gone but that's due to the mkinitcpio stuff. I have no "ro" anywhere anymore yet grup itself (at boot) shows me a ro..

What do you mean? The warning discussed in this thread comes from the initramfs - not grub. I'm not sure where grub would show you "ro". Do you mean that if you edit the kernel command line, it includes "ro"?

Please confirm that you do not have a separate /boot partition.

Last edited by cfr (2013-08-15 22:02:42)

Trilby · 2013-08-15 22:13:13

markg85 wrote:

I have no "ro" anywhere anymore yet ...

As has been said at least four times in this thread alone, not having "ro" is not sufficient, as that is the default if nothing is specified. You must include "rw" on the kernel line.

anonymous_user · 2013-08-15 22:22:21

BTW wasn't the grub package recently updated to fix this? Afaik you can just upgrade to the new version and regenerate your config, right?

cfr · 2013-08-15 23:16:43

Trilby wrote:

markg85 wrote:
I have no "ro" anywhere anymore yet ...
As has been said at least four times in this thread alone, not having "ro" is not sufficient, as that is the default if nothing is specified. You must include "rw" on the kernel line.

The grub.cfg posted shows that 'rw' is on the kernel command lines. And anonymous_user is right, I think: merely removing any 'ro' from /etc/default/grub and regenerating grub.cfg is now sufficient to ensure 'rw' on the kernel command line in grub entries.

markg85 · 2013-08-15 23:31:58

cfr wrote:

markg85 wrote:
I tried every single solution provided in this thread. The message is gone but that's due to the mkinitcpio stuff. I have no "ro" anywhere anymore yet grup itself (at boot) shows me a ro..
What do you mean? The warning discussed in this thread comes from the initramfs - not grub. I'm not sure where grub would show you "ro". Do you mean that if you edit the kernel command line, it includes "ro"?
Please confirm that you do not have a separate /boot partition.

What i mean is exactly what i wrote. Grub - at boot - shows me "ro" and no "rw" on the kernel line. Also, lets please not repeat this thread. It was said that initramfs is causing this message but grub (or the kernel lines put in there) are the fix for it. ro -> rw. I know what i'm talking about since i've actually read this thread.

And yes, boot sits nice and cozy with the root partition. It does not have a partition of it's own.

Trilby wrote:

markg85 wrote:
I have no "ro" anywhere anymore yet ...
As has been said at least four times in this thread alone, not having "ro" is not sufficient, as that is the default if nothing is specified. You must include "rw" on the kernel line.

Oh wow, you can act less annoyed. Being friendly wouldn't harm anyone.
You apparently haven't read what i said. If you would have looked in my grub.cfg paste then you would have seen that it includes "rw". And that very fact is what puzzles me because grub - while booting and looking at the kernel line shows "ro" instead of "rw".

Note: can we please drop the "pissed of behaviour" in this thread? It feels a bit hostile in here. I would like it if the replies could be a little more friendly.

markg85 · 2013-08-15 23:35:53

cfr wrote:

Trilby wrote:
markg85 wrote:
I have no "ro" anywhere anymore yet ...
As has been said at least four times in this thread alone, not having "ro" is not sufficient, as that is the default if nothing is specified. You must include "rw" on the kernel line.
The grub.cfg posted shows that 'rw' is on the kernel command lines. And anonymous_user is right, I think: merely removing any 'ro' from /etc/default/grub and regenerating grub.cfg is now sufficient to ensure 'rw' on the kernel command line in grub entries.

I doubt that. When i wrote my message i fully updated my system (with [testing] enabled to be sure that i have the latest grub available) and updated my grub.cfg with grub-mkconfig. After that it didn't work and posted my initial reply to this thread.

Also, /etc/default/grub never had a "ro" to begin with. All i added ever since i have that file is "quiet"

cfr · 2013-08-16 00:20:13

markg85 wrote:

cfr wrote:
Trilby wrote:
As has been said at least four times in this thread alone, not having "ro" is not sufficient, as that is the default if nothing is specified. You must include "rw" on the kernel line.
The grub.cfg posted shows that 'rw' is on the kernel command lines. And anonymous_user is right, I think: merely removing any 'ro' from /etc/default/grub and regenerating grub.cfg is now sufficient to ensure 'rw' on the kernel command line in grub entries.
I doubt that. When i wrote my message i fully updated my system (with [testing] enabled to be sure that i have the latest grub available) and updated my grub.cfg with grub-mkconfig. After that it didn't work and posted my initial reply to this thread.

I think you misunderstood me. Your grub.cfg has 'rw' on the kernel command lines. Your /etc/default/grub does not specify 'rw' but I think this does not, as anonymous_user pointed out, matter with the current version of grub because grub-mkconfig now uses 'rw' in any case. Your grub.cfg apparently confirms that.

Also, /etc/default/grub never had a "ro" to begin with. All i added ever since i have that file is "quiet"

Sure but this does not necessarily matter. As Trilby said, not having 'ro' is insufficient as that's default if nothing is specified. Moreover, with previous versions of grub, even having 'rw' in /etc/default/grub was insufficient because grub-mkconfig added 'ro' regardless. However, as anonymous_user said, that's no longer the case. (Regardless of whether you are using testing or not.)

My response to Trilby was just trying to highlight that the grub.cfg you posted does in fact have 'rw' and not 'ro'.

So the question is where and why 'ro'? If I understand correctly, when at the grub menu, if you edit the kernel command line, you find that 'ro' is there by default rather than 'rw'. Is that correct? That is, that's where you are seeing it?

Have you double-checked grub is using the correct UUID? Although it is hard to see how that could not be the case unless you have multiple installations of Arch.

Trilby · 2013-08-16 00:22:30

Sorry I don't use grub - I didn't look in the hard-to-read generated config, just in the /etc/default/grub where the kernel command line entry was left blank.

markg85 · 2013-08-16 00:39:04

cfr wrote:

So the question is where and why 'ro'? If I understand correctly, when at the grub menu, if you edit the kernel command line, you find that 'ro' is there by default rather than 'rw'. Is that correct? That is, that's where you are seeing it?

Exactly!

cfr wrote:

Have you double-checked grub is using the correct UUID? Although it is hard to see how that could not be the case unless you have multiple installations of Arch.

I actually did check that and the UUID i see at boot matches the one i see in grub.cfg so that seems to be fine.

So the question remains, how can this be possible? What is "changing" my "rw" to "ro"? Since i would expect grub.cfg to be final and used as is. Apparently that isn't the case otherwise i would've seen "rw" and not "ro" in the kernel line at boot.

cfr · 2013-08-16 00:46:24

Why don't you try changing something arbitrary in grub.cfg just to see if that change shows up when you boot? For example, try removing the "quiet" or adding e.g. rd.log (which will just enable logging in early user space). You can do this in /etc/default/grub and regenerate grub.cfg. Just make a backup copy of /etc/default/grub so you can revert the change afterwards.

That will tell you whether your grub.cfg is being ignored (i.e. grub is using a different config file) or whether the problem is specific to 'ro', which seems unlikely.

Scimmia · 2013-08-16 03:37:01

markg85, what version of grub? If it's less than 2.00.5043-3, update your system and try again.

markg85 · 2013-08-16 10:33:33

Scimmia wrote:

markg85, what version of grub? If it's less than 2.00.5043-3, update your system and try again.

└─> pacman -Qi grub
Name : grub
Version : 2.00.5086-1
Description : GNU GRand Unified Bootloader (2)
Architecture : x86_64
URL : https://www.gnu.org/software/grub/
Licenses : GPL3
Groups : None
Provides : grub-common grub-bios grub-efi-x86_64
Depends On : sh xz gettext device-mapper
Optional Deps : freetype2: For grub-mkfont usage
fuse: For grub-mount usage [installed]
dosfstools: For grub-mkrescue FAT FS and EFI support [installed]
efibootmgr: For grub-install EFI support [installed]
libisoburn: Provides xorriso for generating grub rescue iso using grub-mkrescue
os-prober: To detect other OSes when generating grub.cfg in BIOS systems
mtools: For grub-mkrescue FAT FS support
Required By : None
Optional For : None
Conflicts With : grub-common grub-bios grub-efi-x86_64 grub-legacy
Replaces : grub-common grub-bios grub-efi-x86_64
Installed Size : 19380.00 KiB
Packager : Tobias Powalowski <tpowa@archlinux.org>
Build Date : Mon 05 Aug 2013 05:57:13 PM CEST
Install Date : Tue 13 Aug 2013 07:35:27 PM CEST
Install Reason : Explicitly installed
Install Script : Yes
Validated By : Signature

markg85 · 2013-08-16 10:43:02

cfr wrote:

Why don't you try changing something arbitrary in grub.cfg just to see if that change shows up when you boot? For example, try removing the "quiet" or adding e.g. rd.log (which will just enable logging in early user space). You can do this in /etc/default/grub and regenerate grub.cfg. Just make a backup copy of /etc/default/grub so you can revert the change afterwards.
That will tell you whether your grub.cfg is being ignored (i.e. grub is using a different config file) or whether the problem is specific to 'ro', which seems unlikely.

Interesting! I tried that and even entering bogus data in /boot/grub/grub.cfg - ie breaking it on purpose - gives me a working grub as if nothing changed. As if that file is not even used by grub. How can i see where grub tries to load it's config from?

Note: EFI motherboard here (in case it matters?)

Mr.Elendig · 2013-08-16 11:38:51

anonymous_user wrote:

BTW wasn't the grub package recently updated to fix this? Afaik you can just upgrade to the new version and regenerate your config, right?

Only works for new installs because no one ever bothers to take care of their .pacnew files.

Last edited by Mr.Elendig (2013-08-16 11:39:30)

WonderWoofy · 2013-08-16 14:51:13

markg85, your motherboard is UEFI? Are you using UEFI? The location of the grub.cfg in the case of UEFI is different from the legacy bios. I am not a grub user, but I seem to recall that it either reads a config from the same directory from which it was launched... or you can specify where it is located. I know you can at least specify where the grub.efi will live.

There is also the posibility that you created a stand-alone grub as well, which I *think* means that the config is integrated into the grub.efi itself. I ahve never tried this though, so that iis only what I assumed was meant by stand-alone.

Of course, I am not a grub user, so take my advice iwith a handful of salt. But I do know that the grub-efi is much more flexable in terms of file locations than the grub-bios. Hopefully a real UEFI grub user can step in here... cfr?

cfr · 2013-08-16 21:11:18

grub.cfg can go in different places but if you follow current recommendations, it goes in the same place as for a bios install.

Can you post the output of efibootmgr -v after modprobing efivars? But it is the command you used to install grub to disk that is crucial in determining which grub.cfg it uses. By default /boot/grub/grub.cfg but you can specify somewhere else for almost all of the defaults. Can you post that command, too?

Apart from that, the output of ls -R /boot would be useful with the EFI partition mounted wherever you usually mount it.

Mr.Elendig wrote:

anonymous_user wrote:
BTW wasn't the grub package recently updated to fix this? Afaik you can just upgrade to the new version and regenerate your config, right?
Only works for new installs because no one ever bothers to take care of their .pacnew files.

This is false. Regenerating grub.cfg is enough unless you explicitly added 'ro' to /etc/default/grub in which case you also need to remove it. The update affects a file under /etc/grub.d which is not protected by pacman's backup function so updating grub and regenerating grub.cfg should be sufficient subject to the ro-in-/etc/default/grub caveat.

60lpsdf250 · 2013-08-17 00:38:20

falconindy wrote:

Before this thread gets littered with misinformation and "workarounds"...
This is the change in mkinitcpio which generates the warning. It's necessary in response to this systemd commit.
Restated: Previously, if you included the 'fsck' hook in mkinitcpio.conf, early init would write to /run/initramfs/root-fsck after fsck'ing root. This flag file would tell systemd that root has already been checked, and there's no need to check it again. Support for reading this flag file has been removed and now the only indication that systemd should not fsck the root device is that it's mounted read-write. 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.
Yes, using the 'systemd' hook is an option. An option and not a requirement. Just fix your kernel commandline to specify 'rw' instead of 'ro' (or nothing) so that your root device is mounted rw after fsck'ing.

Thank you, this solved my problem. I appreciate your insight.

henk · 2013-08-17 03:16:43

markg85 wrote:

I tried every single solution provided in this thread. The message is gone but that's due to the mkinitcpio stuff. I have no "ro" anywhere anymore yet grup itself (at boot) shows me a ro..

This can happen if this Grub is not controlling the boot, but is just some entry in another bootloader which is not updated to add rw to the kernel line.

DogMatix · 2013-08-18 13:11:58

falconindy wrote:

Before this thread gets littered with misinformation and "workarounds"...
This is the change in mkinitcpio which generates the warning. It's necessary in response to this systemd commit.
Restated: Previously, if you included the 'fsck' hook in mkinitcpio.conf, early init would write to /run/initramfs/root-fsck after fsck'ing root. This flag file would tell systemd that root has already been checked, and there's no need to check it again. Support for reading this flag file has been removed and now the only indication that systemd should not fsck the root device is that it's mounted read-write. 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.
Yes, using the 'systemd' hook is an option. An option and not a requirement. Just fix your kernel commandline to specify 'rw' instead of 'ro' (or nothing) so that your root device is mounted rw after fsck'ing.

Thanks. Read carefully. Understood. Fixed.

GloW_on_dub · 2013-08-25 12:45:57

For grub user who, like me, does not know how to add "rw" in the kernel command line ( from https://wiki.archlinux.org/index.php/Kernel_parameters:
edit /etc/default/grub and add rw at the GRUB_CMDLINE_LINUX_DEFAULT

GRUB_CMDLINE_LINUX_DEFAULT="quiet rw"

Then regenerate your grub.cfg :

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

Thanks falconindy for your explanation.

WonderWoofy · 2013-08-25 13:18:21

@GloW_on_dub, the grub package has been fixed to handle this properly now. There is no need to have rw, as it will be placed in the kernel command line automagically on regeneration.

sr9 · 2017-10-18 18:58:45

Just done with the basic installation only and saw this warning at reboot. Now I'm well versed with how the systemd and fsck hooks go-about this warning and how to solve it (thanks to such amazing contributors)
Just have a last doubt related to the flow of execution -
Initially I had the basic Hooks in /etc/mkiniticpio.conf :-

HOOKS="base udev autodetect ... fsck"

Then I used this workaround :-

FarStar07 wrote:

Hello,
Have you [Testing] enabled? After the last "big" update, the message "root device is not configured read-write..." appeared. But there was a Pacman's warning during the update:
systemd 205 restructures the cgroup hierarchy and changes internal protocols. You should reboot at your earliest convenience. The "timestamp" hook for mkinitcpio no longer exists. If you used this hook, you must remove it from /etc/mkinitcpio.conf. A "systemd" hook has been added which provides this functionality, and more.
So, in /etc/mkinitcpio.conf file, replace the 'base', 'usr', 'udev' and 'timestamp' hooks by systemd hook only.
For information, my hooks line is:
HOOKS="systemd keymap autodetect modconf block keyboard filesystems fsck"
Then, sudo mkinitcpio -p linux in a terminal and reboot. Here, the problem has been solved like that.

now /etc/mkinitcpio.conf has

HOOKS="systemd autodetect ...fsck"

and now the warning is no more.

Query 1
My observation is that since Hooks are executed in the order of their listing so systemd gets executed before fsck hook and systemd thus fsck'd and mounted the filesystem as 'rw' because of which the mkinitcpio doesn't issue a warning.
So is it correct to assume that the code in mkinitcpio as pointed by falconindy here(below) is executed after all the HOOKS have been executed ??

falconindy wrote:

Before this thread gets littered with misinformation and "workarounds"...
This is the change in mkinitcpio which generates the warning. It's necessary in response to this systemd commit.

If yes, can you please explain (or link to a forum post) what is the flow of execution among of these hooks and other commands such as mkinitcpio

Query 2
Now that I have systemd hook before the fsck hook(assuing above observation is correct), does fsck hook again fsck's the filesystem ? and can I remove the fsck hook ?

Query 3
Moreover, just for curiousty how do I permanently set 'rw' in the kernel commandline - I don't have grub config files under /boot or /etc/default directory either as I didn't install the Arch grub (using Ubuntu's grub only) and appending to the commandline at boot time requires it to be done manually each time.

First post, criticism appreciated

jasonwryan · 2017-10-18 19:35:55

This is the [testing] forum, so it is relevant to only packages in that repo. Packages in that repo do not remain there for four years: https://wiki.archlinux.org/index.php/Co … bumping.22

Closing

Arch Linux

#76 2013-08-15 22:01:32

Re: root device not read-write warning

#77 2013-08-15 22:13:13

Re: root device not read-write warning

#78 2013-08-15 22:22:21

Re: root device not read-write warning

#79 2013-08-15 23:16:43

Re: root device not read-write warning

#80 2013-08-15 23:31:58

Re: root device not read-write warning

#81 2013-08-15 23:35:53

Re: root device not read-write warning

#82 2013-08-16 00:20:13

Re: root device not read-write warning

#83 2013-08-16 00:22:30

Re: root device not read-write warning

#84 2013-08-16 00:39:04

Re: root device not read-write warning

#85 2013-08-16 00:46:24

Re: root device not read-write warning

#86 2013-08-16 03:37:01

Re: root device not read-write warning

#87 2013-08-16 10:33:33

Re: root device not read-write warning

#88 2013-08-16 10:43:02

Re: root device not read-write warning

#89 2013-08-16 11:38:51

Re: root device not read-write warning

#90 2013-08-16 14:51:13

Re: root device not read-write warning

#91 2013-08-16 21:11:18

Re: root device not read-write warning

#92 2013-08-17 00:38:20

Re: root device not read-write warning

#93 2013-08-17 03:16:43

Re: root device not read-write warning

#94 2013-08-18 13:11:58

Re: root device not read-write warning

#95 2013-08-25 12:45:57

Re: root device not read-write warning

#96 2013-08-25 13:18:21

Re: root device not read-write warning

#97 2017-10-18 18:58:45

Re: root device not read-write warning

#98 2017-10-18 19:35:55

Re: root device not read-write warning

Board footer