root device not read-write warning

falconindy · 2013-07-25 11:53:38

Rog wrote:

if systemd 206 checks root file system integrity at boot,

systemd has always done this...

Rog wrote:

can i remove fsck in mkinitcpio.conf ?

I suggest you read the thread...

4javier · 2013-07-25 12:01:51

falconindy wrote:

Yes. But only if it's fsck'd in early userspace.

So, now a typical configuration could be: fsck hook, root partition mounted rw, and value 0 for pass field in fstab, right?

P.S.
if somebody doesn't use fsck hook, and let systemd check the root ro partition and then remount it rw, what need is there to set pass field to 1?

falconindy · 2013-07-25 12:44:17

4javier wrote:

if somebody doesn't use fsck hook, and let systemd check the root ro partition and then remount it rw, what need is there to set pass field to 1?

If you don't set the passno and you aren't using the fsck hook, why would you expect the filesystem to be checked?

cm · 2013-07-25 13:22:40

4javier wrote:

Maybe the "automatic ro issue" is due to line 138 of /util/grub.d/10_linux.in?
	linux	${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}

That looks like it should be removed but I don't know enough about all the grub include files to know for sure. Why don't you open a bug report suggesting removal?

cm · 2013-07-25 13:24:31

If I remove the 'fsck' hook and replace the others 4 hooks with 'systemd' at least on a luks rootfs machine I'm not prompted for the root partitions pass anymore and cannot boo that system. That makes me believe it's not right or not that simple.

4javier · 2013-07-25 13:41:17

falconindy wrote:

If you don't set the passno and you aren't using the fsck hook, why would you expect the filesystem to be checked?

I thought the fstab field was considered only for the per-boot-number check performed by the system (just to be clear, the check that has 30 as default frequency), and that systemd executed a root fsck at every boot on its own, regardless of fstab field.

cm wrote:

That looks like it should be removed but I don't know enough about all the grub include files to know for sure. Why don't you open a bug report suggesting removal?

I think it just needs to edit that line in a patch already shipped with grub package in the official Arch repo (archlinux_grub_mkconfig_fixes.patch). But ther's a dev involved in this thread, he surely knows better if this change has to be done.

Last edited by 4javier (2013-07-25 13:48:00)

falconindy · 2013-07-25 14:27:45

cm wrote:

If I remove the 'fsck' hook and replace the others 4 hooks with 'systemd' at least on a luks rootfs machine I'm not prompted for the root partitions pass anymore and cannot boo that system. That makes me believe it's not right or not that simple.

Of course it doesn't work. Perhaps you should look at what the hook does.

$ mkinitcpio -H systemd
==> Help for hook 'systemd':
This will install a basic systemd setup in your initramfs, and is meant to
replace the 'base', 'usr', 'udev' and 'timestamp' hooks. Other hooks would need
to be ported, and may not work as intended. You also may wish to still include
the 'base' hook (before this hook) to ensure that a rescue shell exists on your
initramfs.

I've clearly stated in this thread that using the systemd hook is an option, and not a requirement. Please, re-read the thread.

4javier wrote:

I thought the fstab field was considered only for the per-boot-number check performed by the system (just to be clear, the check that has 30 as default frequency), and that systemd executed a root fsck at every boot on its own, regardless of fstab field.

Uh, no... fstab(5) documents the purpose of this field:

The sixth field (fs_passno).
This field is used by the fsck(8) program to determine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a
fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not
present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.

falconindy wrote:

Before this thread gets littered with misinformation and "workarounds"...

Oh well, I tried.

Last edited by falconindy (2013-07-25 14:54:05)

cm · 2013-07-25 15:01:28

falconindy wrote:

I think you need to re-read my post more carefully. You're wrong on several accounts. No, fsck isn't a problem. No, systemd is not mandatory.

The mandatoryness I meant is that there's no archlinux without systemd and therefore it's a perfectly good idea to make use of systemd in mkinicpio.conf. Sorry that I was not precise enough.

cm · 2013-07-25 15:06:00

falconindy wrote:

$ mkinitcpio -H systemd
==> Help for hook 'systemd':
This will install a basic systemd setup in your initramfs, and is meant to
replace the 'base', 'usr', 'udev' and 'timestamp' hooks. Other hooks would need
to be ported, and may not work as intended. You also may wish to still include
the 'base' hook (before this hook) to ensure that a rescue shell exists on your
initramfs.

I've clearly stated in this thread that using the systemd hook is an option, and not a requirement. Please, re-read the thread.

I don't think I misread that because I have only replaced 'base' and 'udev' with 'systemd' and while keeping 'encrypt' still there I removed 'fsck'.

old and working

HOOKS="base udev modconf block encrypt filesystems keyboard fsck autodetect"

new and failing

HOOKS="systemd modconf block encrypt filesystems keyboard autodetect"

for worst case scenarios it should be

HOOKS="systemd base modconf block encrypt filesystems keyboard autodetect"

Is this wrong?

Last edited by cm (2013-07-25 15:06:59)

falconindy · 2013-07-25 15:08:55

What's unclear about "other hooks would need to be ported and may not work as intended"?

Last edited by falconindy (2013-07-25 15:09:07)

cm · 2013-07-25 17:57:51

falconindy wrote:

What's unclear about "other hooks would need to be ported and may not work as intended"?

It's unclear that using the 'systemd' hook to replace the 4 hooks may not work at all and the text should warn about that.
The current text tries but doesn't make that clear enough and is ambiguous in meaning if you ask me. The text kinda suggest
that it should work in most configurations.

Last edited by cm (2013-07-25 18:00:01)

Scimmia · 2013-07-25 18:14:07

"may not work as intended" is about as clear as it gets.

alphaniner · 2013-07-25 18:23:36

@cm

I think if you re-read it having discarded your original interpretation, you'll find that it means just what falconindy says it means.

FWIW, on several occasions I've read "scanned" some doc he wrote and gotten the wrong idea, only to re-read actually read it after realizing I got it wrong and find there was no good reason for my confusion.

Last edited by alphaniner (2013-07-25 18:23:54)

cfr · 2013-07-25 20:52:52

'May' is multiply ambiguous but the context should do a considerable amount to disambiguate it.

cm · 2013-07-26 10:10:35

What do we do about grub-mkconfig and 'ro'? It shouldn't add that automatically anymore should it?

cm · 2013-07-26 10:12:30

Leonid.I wrote:

cm wrote:
I considered using syslinux instead but couldn't figure out how I can install it somewhere else than MBR.
Don't bother I see the warning with syslinux 6.01.

Correct me but with syslinux you always configure it manually by hand and it shouldn't add 'ro' itself.
So for syslinux you should just edit the config.

Lone_Wolf · 2013-07-26 10:59:16

cm wrote:

falconindy wrote:
I think you need to re-read my post more carefully. You're wrong on several accounts. No, fsck isn't a problem. No, systemd is not mandatory.
The mandatoryness I meant is that there's no archlinux without systemd and therefore it's a perfectly good idea to make use of systemd in mkinicpio.conf. Sorry that I was not precise enough.

An archlinux system is what the user makes of it.
Technically it's possible to remove systemd completely and replace it.
Also there are some archlinux users (like me) that use systemd for udev, but don't boot with systemd.

If mkinitcpio only worked when systemd is the init program, this would leave those people out in the cold.

I'm very glad falconindy made clear that the new systemd hook is not mandatory.

4javier · 2013-07-26 11:32:26

@falconindy
but from man systemd-fsck-root.service

fsck.mode=
One of auto, force, skip. Controls the mode of operation. The default is auto, and ensures that file system checks are done when the file
system checker deems them necessary.

Then, by default, systemd will not check root at every boot. What am i missing?

falconindy · 2013-07-26 13:10:17

4javier wrote:

@falconindy
but from man systemd-fsck-root.service
fsck.mode=
One of auto, force, skip. Controls the mode of operation. The default is auto, and ensures that file system checks are done when the file
system checker deems them necessary.
Then, by default, systemd will not check root at every boot. What am i missing?

The doc is misleading. fsck runs on every bootup when the mode is explicitly 'auto' or unset. It may not do a full consistency check on every bootup (which is what people usually refer to when they think of fsck). Using fsck.mode=force means that a consistency check will always be done.

4javier · 2013-07-26 13:22:36

Ok. It should be the same difference between "fsck" and "e2fsck -f". Thanks for the explanations.

cm · 2013-07-28 12:05:38

tpowa fixed it in grub 2.00.5043-3 https://projects.archlinux.org/svntogit … 5d7edda21a

mcloaked · 2013-08-04 09:47:23

This discussion seems to relate to changes in systemd 206 - however for users who have only [core] and not the [testing] repo enabled we now have the situation where for a standard install, and with everything up to date, that once the grub config is updated then the warning at boot:

*  The root device is not configured to be mounted  *
*  read-write! It may be fsck'd again later.        *

appears despite systemd being still at version systemd 204-3 in [core] - so the question really is for a user who has a standard install with an untouched set of configs for mkinitcpio and booting via grub - what is the safe and optimal way to get the system boot which will ensure a secure filesystem? Was the original poster using the [testing] repo - it was not clear as I read the posts.

I guess the question is does systemd 204 still do a filesystem check on the root filesystem without the fsck hook in the mkinitcpio.conf file?

man systemd-fsck-root.service seems to imply that it will check the root filesystem provided there is no related parameter passed in the kernel line for boot.

What if the user has a system that is up to date and booted via a different method than grub? For example I have a standard system with only [core] and not [testing] and booting via rEFInd - grub is not even installed in this system - yet the command

sudo systemctl status systemd-fsck-root

shows that the root filesystem has indeed been checked and the output of that command shows the set of recent root filesystem checks.

On the other hand maybe this will all simply resolve itself without having to intervene at all once the latest systemd and mkinitcpio are released to [core].

Maybe this is a case for having some clear guidance in the arch wiki concerning grub? There is no mention of mkinitcpio in the grub section of the wiki. In the mkinitcpio section of the wiki there is some guidance about HOOKS - and concerning fsck it says

"Adds the fsck binary and filesystem-specific helpers. If added after the autodetect hook, only the helper specific to your root filesystem will be added. Usage of this hook is strongly recommended, and it is required with a separate /usr partition."

So it is indeed still ambiguous since the arch wiki is saying that the fsck hook is strongly recommended and yet there is advice that this is no longer needed since systemd will be doing the root file system check.

So it would be nice to have a clear set of statements that allow the user to make a good and properly considered decision about how to set up the relevant set of packages pertaining to boot as well as systemd since a "standard" install is giving a warning that is not easy to interpret as is clear from this thread.

On the other hand maybe this will resolve itself without the need for user intervention when systemd 206 and the latest mkinitcpio are released to [core]?

Last edited by mcloaked (2013-08-04 09:50:58)

Biowaste · 2013-08-04 12:26:01

cm wrote:

What do we do about grub-mkconfig and 'ro'? It shouldn't add that automatically anymore should it?

I'm confused about this as well. I was under the impression one should generally never edit grub.cfg directly (and then I'd have to manually change it every time I use grub-mkconfig), so I've changed the ro in this line in /etc/grub.d/10_linux to rw:

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

cfr · 2013-08-04 14:16:53

I've changed 'ro' to 'rw' in all my kernel command lines for both grub and rEFInd but have left the fsck hook in mkinitcpio.conf. On the other hand, this is easy for me as I maintain grub.cfg manually in any case. (That is, I never use grub-mkconfig to overwrite grub.cfg. If I want to test something, I output to /tmp/grub.cfg and check whatever but I don't use grub-mkconfig to maintain grub.cfg at all.)

EDIT: I am not using testing.

Last edited by cfr (2013-08-04 14:17:24)

falconindy · 2013-08-04 14:17:29

mcloaked wrote:

This discussion seems to relate to changes in systemd 206

No, it's very much related to changes in mkinitcpio 0.15. I've stated this before

mcloaked wrote:

I guess the question is does systemd 204 still do a filesystem check on the root filesystem without the fsck hook in the mkinitcpio.conf file?

systemd has always run fsck at bootup unless told not to (via fstab or the kernel cmdline).

mcloaked wrote:

So it would be nice to have a clear set of statements that allow the user to make a good and properly considered decision about how to set up the relevant set of packages pertaining to boot as well as systemd since a "standard" install is giving a warning that is not easy to interpret as is clear from this thread.
On the other hand maybe this will resolve itself without the need for user intervention when systemd 206 and the latest mkinitcpio are released to [core]?

I'll quote myself again:

falconindy wrote:

Regardless of what precipitated the change (yes, it's systemd 206), mounting your disk read-only after fsck'ing it is odd choice.

Arch Linux

#26 2013-07-25 11:53:38

Re: root device not read-write warning

#27 2013-07-25 12:01:51

Re: root device not read-write warning

#28 2013-07-25 12:44:17

Re: root device not read-write warning

#29 2013-07-25 13:22:40

Re: root device not read-write warning

#30 2013-07-25 13:24:31

Re: root device not read-write warning

#31 2013-07-25 13:41:17

Re: root device not read-write warning

#32 2013-07-25 14:27:45

Re: root device not read-write warning

#33 2013-07-25 15:01:28

Re: root device not read-write warning

#34 2013-07-25 15:06:00

Re: root device not read-write warning

#35 2013-07-25 15:08:55

Re: root device not read-write warning

#36 2013-07-25 17:57:51

Re: root device not read-write warning

#37 2013-07-25 18:14:07

Re: root device not read-write warning

#38 2013-07-25 18:23:36

Re: root device not read-write warning

#39 2013-07-25 20:52:52

Re: root device not read-write warning

#40 2013-07-26 10:10:35

Re: root device not read-write warning

#41 2013-07-26 10:12:30

Re: root device not read-write warning

#42 2013-07-26 10:59:16

Re: root device not read-write warning

#43 2013-07-26 11:32:26

Re: root device not read-write warning

#44 2013-07-26 13:10:17

Re: root device not read-write warning

#45 2013-07-26 13:22:36

Re: root device not read-write warning

#46 2013-07-28 12:05:38

Re: root device not read-write warning

#47 2013-08-04 09:47:23

Re: root device not read-write warning

#48 2013-08-04 12:26:01

Re: root device not read-write warning

#49 2013-08-04 14:16:53

Re: root device not read-write warning

#50 2013-08-04 14:17:29

Re: root device not read-write warning

Board footer