Closing
]]>HOOKS="base udev autodetect ... fsck"
Then I used this workaround :-
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 ??
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
]]>GRUB_CMDLINE_LINUX_DEFAULT="quiet rw"
Then regenerate your grub.cfg :
grub-mkconfig -o /boot/grub/grub.cfg
Thanks falconindy for your explanation.
]]>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.
]]>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.
]]>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.
]]>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.
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.
]]>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?
]]>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.
]]>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?)
]]>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
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.
]]>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!
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.
]]>