Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 01.10.2013 02:58, schrieb Lennart Poettering: Originally the intention was that root-fsck.service would run fsck for the root device, anf fsck@.service would be used for the rest. The difference is mostly one about ordering, i.e. root-fsck.service is the only one that is fine with the fs being already mounted. Now, if we have the initrd, then I figure root-fsck.service doesn't make much sense, but there's something missing I think: if we use fsck@.service for the root device, how do we then communicate to the root-fsck.service on the host that the file system has already been checked? How is that supposed to work? Harald? What is the idea here? Can we get some decision here? Right now, we don't get root fsck'ed with 'rw' on the command line, which is worse than fsck'ing twice in the 'ro' case. Colin had the great idea that we drop mask root-fsck.service in /run/systemd/system/ when we run fsck in initrd. For example, the initrd generator could add a service to the initrd that creates the symlink and a .d snippet that makes systemd-fsck@.service require it. This would work without complex changes to the systemd core and hopefully cover all cases. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
On Fri, Oct 04, 2013 at 11:34:44AM +0200, Thomas Bächler wrote:
Am 01.10.2013 02:58, schrieb Lennart Poettering:
Originally the intention was that root-fsck.service would run fsck for
the root device, anf fsck@.service would be used for the rest. The
difference is mostly one about ordering, i.e. root-fsck.service is the
only one that is fine with the fs being already mounted.
Now, if we have the initrd, then I figure root-fsck.service doesn't make
much sense, but there's something missing I think: if we use
fsck@.service for the root device, how do we then communicate to the
root-fsck.service on the host that the file system has already been
checked? How is that supposed to work?
Harald? What is the idea here?
Can we get some decision here? Right now, we don't get root fsck'ed with
'rw' on the command line, which is worse than fsck'ing twice in the 'ro'
case.
Colin had the great idea that we drop mask root-fsck.service in
/run/systemd/system/ when we run fsck in initrd. For example, the initrd
generator could add a service to the initrd that creates the symlink and
a .d snippet that makes systemd-fsck@.service require it. This would
work without complex changes to the systemd core and hopefully cover all
cases.
Hm, why not add ConditionKernelCommandLine=!ro instead to
systemd-root-fsck.service? ('rw' is the default, the lack of 'ro'
means 'rw'.)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 04.10.2013 13:52, schrieb Zbigniew Jędrzejewski-Szmek:
Colin had the great idea that we drop mask root-fsck.service in
/run/systemd/system/ when we run fsck in initrd. For example, the initrd
generator could add a service to the initrd that creates the symlink and
a .d snippet that makes systemd-fsck@.service require it. This would
work without complex changes to the systemd core and hopefully cover all
cases.
Hm, why not add ConditionKernelCommandLine=!ro instead to
systemd-root-fsck.service?
I looked into it and decided against it, since it is not the correct
test case: You can have fsck in initrd and still mount ro - then
systemd-root-fsck will still start and you will have the double-fsck again.
Actually, what you propose is the same as having systemd-root-fsck with
ConditionReadWrite=!/, which is already in place.
('rw' is the default, the lack of 'ro'
means 'rw'.)
Line 383 in src/fstab-generator/fstab-generator.c disagrees.
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 01.10.2013 02:58, schrieb Lennart Poettering: Now, if we have the initrd, then I figure root-fsck.service doesn't make much sense, but there's something missing I think: if we use fsck@.service for the root device, how do we then communicate to the root-fsck.service on the host that the file system has already been checked? How is that supposed to work? This is how I imagine things should work: 1) initrd fsck's the device used for /sysroot. 2) initrd mounts /sysroot as rw 3) initrd fsck's and mounts /usr and friends 4) switch-root 5) the main system only fsck's and mounts whatever isn't mounted yet. This is what we now have as default in new Arch installations (including / being mounted rw in initrd). What we don't have by default yet is initrd being handled by systemd. In the systemd case, step 1) was missing and the root device was never fsck'ed, thus the patch. The beauty of this setup is that systemd implicitly does everything right, there is no need to serialize any fsck state between initrd and main system. In the setup I am aiming for as a default, neither systemd-root-fsck.service nor systemd-remount-fs.service are needed and both can go away (in fact, I always mask the latter, since that saves me a few milliseconds). The only use case I see for both using fsck in initrd and having / mounted read-only during switch-root is a read-only root file system. In that light, I don't think there is anything to fix. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
'Twas brillig, and Thomas Bächler at 01/10/13 10:18 did gyre and gimble: Am 01.10.2013 02:58, schrieb Lennart Poettering: Now, if we have the initrd, then I figure root-fsck.service doesn't make much sense, but there's something missing I think: if we use fsck@.service for the root device, how do we then communicate to the root-fsck.service on the host that the file system has already been checked? How is that supposed to work? This is how I imagine things should work: 1) initrd fsck's the device used for /sysroot. 2) initrd mounts /sysroot as rw Why is it the initrd's job to do the rw mount? It should likely mount as ro pretty much always no? It's up to the booted system to remount rw if so desired (i.e. in the fstab). Of course the initrd could check the /sysroot/etc/fstab for this info (it may need to look at this for the /usr mount anyway), but something still makes me think it's up to the system to do the remount rw if needed. I get your point below about not needing remount-fs.service tho', so would be interested in Harald's opinon too :) 3) initrd fsck's and mounts /usr and friends 4) switch-root 5) the main system only fsck's and mounts whatever isn't mounted yet. This is generally OK, but we have to differentiate between initrd boots and non-initrd boots too - as Lennart said, root-fsck is only really sensible if and only if no initrd is used. This is what we now have as default in new Arch installations (including / being mounted rw in initrd). What we don't have by default yet is initrd being handled by systemd. In the systemd case, step 1) was missing and the root device was never fsck'ed, thus the patch. The beauty of this setup is that systemd implicitly does everything right, there is no need to serialize any fsck state between initrd and main system. In the setup I am aiming for as a default, neither systemd-root-fsck.service nor systemd-remount-fs.service are needed and both can go away (in fact, I always mask the latter, since that saves me a few milliseconds). I think everyone agrees that systemd-root-fsck is not needed if you have an initrd. It's only meant for initrd-less boots. Perhaps, the initrd should just drop a masking symlink in /run/systemd/system for that service to ensure it's not run? Likewise the initrd could do the masking for the remount service too such that someone booting without an initrd could still get it? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 01.10.2013 12:15, schrieb Colin Guthrie: 'Twas brillig, and Thomas Bächler at 01/10/13 10:18 did gyre and gimble: Am 01.10.2013 02:58, schrieb Lennart Poettering: Now, if we have the initrd, then I figure root-fsck.service doesn't make much sense, but there's something missing I think: if we use fsck@.service for the root device, how do we then communicate to the root-fsck.service on the host that the file system has already been checked? How is that supposed to work? This is how I imagine things should work: 1) initrd fsck's the device used for /sysroot. 2) initrd mounts /sysroot as rw Why is it the initrd's job to do the rw mount? It should likely mount as ro pretty much always no? It's up to the booted system to remount rw if so desired (i.e. in the fstab). Why should I mount the file system ro only to mount it rw a few milliseconds later? The only reason that was ever done is that file system checks are usually impossible on rw file systems. Since we avoid those anyway with initrd setups, there is no reason left. I can pass the file system with root=, the option with rootflags= and optionally the fs type with rootfstype=. This way, I don't even need to configure my root file system in fstab (and I've started omitting it entirely from my fstabs since the line had no effect anyway). 3) initrd fsck's and mounts /usr and friends 4) switch-root 5) the main system only fsck's and mounts whatever isn't mounted yet. This is generally OK, but we have to differentiate between initrd boots and non-initrd boots too - as Lennart said, root-fsck is only really sensible if and only if no initrd is used. Yes, I think that's what we should go for: systemd-root-fsck is only for initrd-less systems. I think everyone agrees that systemd-root-fsck is not needed if you have an initrd. If that is so, I am happy. It's only meant for initrd-less boots. Perhaps, the initrd should just drop a masking symlink in /run/systemd/system for that service to ensure it's not run? I like that. Likewise the initrd could do the masking for the remount service too such that someone booting without an initrd could still get it? Maybe - I personally mask the service on all my systems (it noticably slowed down a non-SSD boot on an old machine). I don't think it should be needed on a properly configured system with initrd. Even on a non-initrd system, all it should change is the rw/ro flag, the rest can be configured properly right from the start. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
On Mon, 30.09.13 00:32, Thomas Bächler (tho...@archlinux.org) wrote:
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 9efccb9..6cecb4e 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -449,7 +449,7 @@ static int parse_new_root_from_proc_cmdline(void) {
}
log_debug(Found entry what=%s where=/sysroot type=%s, what, type);
-r = add_mount(what, /sysroot, type, opts, 0, noauto, nofail, false,
+r = add_mount(what, /sysroot, type, opts, 1, noauto, nofail, false,
SPECIAL_INITRD_ROOT_FS_TARGET, /proc/cmdline);
Hmm, Harald, how is this supposed to work?
Originally the intention was that root-fsck.service would run fsck for
the root device, anf fsck@.service would be used for the rest. The
difference is mostly one about ordering, i.e. root-fsck.service is the
only one that is fine with the fs being already mounted.
Now, if we have the initrd, then I figure root-fsck.service doesn't make
much sense, but there's something missing I think: if we use
fsck@.service for the root device, how do we then communicate to the
root-fsck.service on the host that the file system has already been
checked? How is that supposed to work?
Harald? What is the idea here?
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
