Re: [systemd-devel] systemd-fsck-root semantics
Am 02.07.2014 14:29, schrieb Daniel Drake: If I'm reading things right, actually the default behaviour is (when no hints are supplied in kernel cmdline) : 1. systemd runs fsck on root from initramfs 2. systemd mounts root fs ro 3. switch-root onto real system 4. systemd-fsck-root runs 5. systemd-remount-fs remounts / as rw Also just noticed another interesting thing - systemd-fsck-root.service is only loaded dynamically, when /etc/fstab has a non-zero passno for /. So maybe the idea is that anyone running a regular and modern dracut/systemd setup sets passno=0 for / in fstab, with the knowledge that fsck of / is done by the initramfs. Tom and me are thought this through a couple of months ago when I started looking into using Arch's mkinitcpio with systemd. We submitted a few changes to fsck handling back then. This is the setup we want to support (this is now the default in a new Arch installation): 1) fsck in initramfs 2) initramfs mounts rw 3) no re-fsck in the system This is still supported, for legacy systems that have not been reconfigured properly: 1) no fsck in initramfs, or no initramfs 2) initramfs or kernel mount ro 3) fsck in the system 4) remount rw in the system This setup works, but is not optimal: 1) fsck in initramfs 2) initramfs mounts ro 3) re-fsck in the system 4) remount rw in the system In this case, I always recommend mounting rw right away. However, you can also configure your fstab to skip fsck - I don't see why anyone would prefer this though. For your read-only case, you have two options: * Have an fstab entry for / with passno=0 * Don't list / in fstab I prefer the last option, since there is no benefit in adding / to fstab - IMO, the correct mount options should always be given via the kernel commandline to make remounting unnecessary. In my opinion, there is no need to change anything in systemd here, since all the right configuration options are already there. 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] systemd-fsck-root semantics
On Thu, Jul 03, 2014 at 11:49:20AM +0200, Thomas Bächler wrote: Am 02.07.2014 14:29, schrieb Daniel Drake: If I'm reading things right, actually the default behaviour is (when no hints are supplied in kernel cmdline) : 1. systemd runs fsck on root from initramfs 2. systemd mounts root fs ro 3. switch-root onto real system 4. systemd-fsck-root runs 5. systemd-remount-fs remounts / as rw Also just noticed another interesting thing - systemd-fsck-root.service is only loaded dynamically, when /etc/fstab has a non-zero passno for /. So maybe the idea is that anyone running a regular and modern dracut/systemd setup sets passno=0 for / in fstab, with the knowledge that fsck of / is done by the initramfs. Tom and me are thought this through a couple of months ago when I started looking into using Arch's mkinitcpio with systemd. We submitted a few changes to fsck handling back then. This is the setup we want to support (this is now the default in a new Arch installation): 1) fsck in initramfs 2) initramfs mounts rw 3) no re-fsck in the system This is what we want. We also want this to work: 1) fsck in the initramfs 2) initramfs mounts ro 3) no re-fsck or remount in the system This is still supported, for legacy systems that have not been reconfigured properly: 1) no fsck in initramfs, or no initramfs 2) initramfs or kernel mount ro 3) fsck in the system 4) remount rw in the system This setup works, but is not optimal: 1) fsck in initramfs 2) initramfs mounts ro 3) re-fsck in the system 4) remount rw in the system In this case, I always recommend mounting rw right away. However, you can also configure your fstab to skip fsck - I don't see why anyone would prefer this though. For your read-only case, you have two options: * Have an fstab entry for / with passno=0 * Don't list / in fstab I prefer the last option, since there is no benefit in adding / to fstab - IMO, the correct mount options should always be given via the kernel commandline to make remounting unnecessary. In my opinion, there is no need to change anything in systemd here, since all the right configuration options are already there. You're right that everything *can* be configured to work properly. But if any fs was already checked in the initramfs, systemd should be always smart enough to avoid checking it again in the main system. I think that this is works for all filesystems except root. For root it breaks when the fs is mounted ro when transitioning to main system. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Thu, Jul 3, 2014 at 2:14 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Jul 03, 2014 at 11:49:20AM +0200, Thomas Bächler wrote: Am 02.07.2014 14:29, schrieb Daniel Drake: If I'm reading things right, actually the default behaviour is (when no hints are supplied in kernel cmdline) : 1. systemd runs fsck on root from initramfs 2. systemd mounts root fs ro 3. switch-root onto real system 4. systemd-fsck-root runs 5. systemd-remount-fs remounts / as rw Also just noticed another interesting thing - systemd-fsck-root.service is only loaded dynamically, when /etc/fstab has a non-zero passno for /. So maybe the idea is that anyone running a regular and modern dracut/systemd setup sets passno=0 for / in fstab, with the knowledge that fsck of / is done by the initramfs. Tom and me are thought this through a couple of months ago when I started looking into using Arch's mkinitcpio with systemd. We submitted a few changes to fsck handling back then. This is the setup we want to support (this is now the default in a new Arch installation): 1) fsck in initramfs 2) initramfs mounts rw 3) no re-fsck in the system This is what we want. We also want this to work: 1) fsck in the initramfs 2) initramfs mounts ro 3) no re-fsck or remount in the system Hm, the only way this would get re-fscked in the system is if it is explicitly configured to be in /etc/fstab... Shouldn't we just give people what they ask for? Otherwise passno= for the rootfs would have no effect at all in this setup (the rootfs is fscked unconditionally in the initrd regardless of what /etc/fstab says (obviously)). This is still supported, for legacy systems that have not been reconfigured properly: 1) no fsck in initramfs, or no initramfs 2) initramfs or kernel mount ro 3) fsck in the system 4) remount rw in the system This setup works, but is not optimal: 1) fsck in initramfs 2) initramfs mounts ro 3) re-fsck in the system 4) remount rw in the system In this case, I always recommend mounting rw right away. However, you can also configure your fstab to skip fsck - I don't see why anyone would prefer this though. For your read-only case, you have two options: * Have an fstab entry for / with passno=0 * Don't list / in fstab I prefer the last option, since there is no benefit in adding / to fstab - IMO, the correct mount options should always be given via the kernel commandline to make remounting unnecessary. In my opinion, there is no need to change anything in systemd here, since all the right configuration options are already there. You're right that everything *can* be configured to work properly. But if any fs was already checked in the initramfs, systemd should be always smart enough to avoid checking it again in the main system. I think that this is works for all filesystems except root. For root it breaks when the fs is mounted ro when transitioning to main system. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Thu, Jul 03, 2014 at 02:23:57PM +0200, Tom Gundersen wrote: On Thu, Jul 3, 2014 at 2:14 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Jul 03, 2014 at 11:49:20AM +0200, Thomas Bächler wrote: Am 02.07.2014 14:29, schrieb Daniel Drake: If I'm reading things right, actually the default behaviour is (when no hints are supplied in kernel cmdline) : 1. systemd runs fsck on root from initramfs 2. systemd mounts root fs ro 3. switch-root onto real system 4. systemd-fsck-root runs 5. systemd-remount-fs remounts / as rw Also just noticed another interesting thing - systemd-fsck-root.service is only loaded dynamically, when /etc/fstab has a non-zero passno for /. So maybe the idea is that anyone running a regular and modern dracut/systemd setup sets passno=0 for / in fstab, with the knowledge that fsck of / is done by the initramfs. Tom and me are thought this through a couple of months ago when I started looking into using Arch's mkinitcpio with systemd. We submitted a few changes to fsck handling back then. This is the setup we want to support (this is now the default in a new Arch installation): 1) fsck in initramfs 2) initramfs mounts rw 3) no re-fsck in the system This is what we want. We also want this to work: 1) fsck in the initramfs 2) initramfs mounts ro 3) no re-fsck or remount in the system Hm, the only way this would get re-fscked in the system is if it is explicitly configured to be in /etc/fstab... Shouldn't we just give people what they ask for? Otherwise passno= for the rootfs would have no effect at all in this setup (the rootfs is fscked unconditionally in the initrd regardless of what /etc/fstab says (obviously)). Well, passno=1 means it should be checked... once. It would be rather lame to require the user to set it to 0 because the system forgets whether it has already checked the fs or not. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Jul 3, 2014, at 6:23 AM, Tom Gundersen t...@jklm.no wrote: Hm, the only way this would get re-fscked in the system is if it is explicitly configured to be in /etc/fstab... Shouldn't we just give people what they ask for? In practice, often the wrong thing is happening these days. Users and distros appear to routinely not understand what fs_passno should be set to, and set it incorrectly. Even man 5 fstab has wrong information The root filesystem should be specified with a fs_passno of 1. And on Fedora Rawhide it looks like either a systemd unit or the initramfs is causing fsck to be run on XFS and Btrfs file systems, even when fs_passno is 0. What about a new fs_passno value of -1 that means use default for this file system type, and systemd spawns fsck based on the recommendation of that file system's devs? For FAT, ext, and HFS+ clearly the default is to fsck. For XFS, Btrfs, ZFS, NTFS, the default is not to fsck. Otherwise passno= for the rootfs would have no effect at all in this setup (the rootfs is fscked unconditionally in the initrd regardless of what /etc/fstab says (obviously)). Well it doesn't hurt to fsck e.g. XFS, but it's effectively a no op so it's superfluous, just like it is for Btrs and ZFS. The fstab fs_passno and fsck at boot time paradigm has changed since its inception. And I think systemd systems can do this smarter while still being generic about it. The use case and mount point really doesn't matter, it's the file system type that dictates whether fsck ought to be run. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Thu, 2014-07-03 at 12:00 -0600, Chris Murphy wrote: What about a new fs_passno value of -1 that means use default for this file system type, and systemd spawns fsck based on the recommendation of that file system's devs? How should the file system devs communicate their current recommendation? If your answer is they tell systemd developers, who set that in systemd source, and then systemd is shipped to users, that seems less than optimal. The don't ship fsck.foo or symlink fsck.foo to /bin/true methods seem much better from the point of view that the default is communicated with the filesystem tools. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Jul 3, 2014, at 12:43 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: On Thu, 2014-07-03 at 12:00 -0600, Chris Murphy wrote: What about a new fs_passno value of -1 that means use default for this file system type, and systemd spawns fsck based on the recommendation of that file system's devs? How should the file system devs communicate their current recommendation? If your answer is they tell systemd developers, who set that in systemd source, and then systemd is shipped to users, that seems less than optimal. Why? It's static. I don't expect the recommendations to ever change, let alone often. The don't ship fsck.foo or symlink fsck.foo to /bin/true methods seem much better from the point of view that the default is communicated with the filesystem tools. OK, then this sounds like the switch is the existence of fsck.foo, not the value of the root entry's fs_passno, in which case fs_passno for / is being deprecated by systemd. That's not going to be obvious to anyone. For many years now the fsck.foo is also a flag for a missing device. Hence upstream xfs-progs provides fsck.xfs, and Btrfs devs just added fsck.btrfs, for this purpose. So you're suggesting either a.) distros need to remove fsck.foo if they use systemd; or b.) upstream fs projects need to stop shipping fsck.foo and distros need to add them if they don't use systemd and still need an fsck to check for missing devices. What will actually happen in practice is fsck.foo will continue to exist, and will be a no op for those filesystems that don't do fsck. Which is what happens now. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Wed, Jul 02, 2014 at 12:39:54PM +0100, Daniel Drake wrote: Hi, I'm trying to understand dracut/systemd fsck behaviour, in the context of an ext4 filesystem root mounted read-only from dracut, remaining read-only even when the system is fully booted (kiosk-style). I see that systemd's fstab-generator rightly creates a mount unit for /sysroot from the initramfs, and causes e2fsck to be run on it from inside the dracut initramfs, before it is mounted. So far so good. Then the system continues booting, switches root, and then system-fsck-root.service starts from the root fs, and runs fsck on / again. This is the bit I don't understand - we already checked from the initramfs, why check again now? There used to be a marker file in /run to let systemd know that the initramfs already checked it, but that was removed in commit 956eaf2b8d6c024705ddadc7393bc707de02. Thinking about it, I'm not sure how the new systemd would know that systemd-fsck@dev-something.service from the initramfs is the same thing as systemd-fsck-root.service. Maybe that's the problem? Currently systemd-fsck-root.service does nothing if / is mounted rw, which of course is used by almost everybody, so I think you might be using codepaths that are rarely tested. Also, systemd-fsck-root.service in itself seems a little questionable, is it really safe in any context to run fsck on a mounted partition? That could modify data structures which have already been cached in memory in the kernel fs driver. In fact, e2fsck refuses to run on partitions that are mounted, even ones that are ro. Isn't it how it always has been, until initramfs became common? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Wed, Jul 2, 2014 at 1:13 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Thinking about it, I'm not sure how the new systemd would know that systemd-fsck@dev-something.service from the initramfs is the same thing as systemd-fsck-root.service. Maybe that's the problem? Currently systemd-fsck-root.service does nothing if / is mounted rw, which of course is used by almost everybody, so I think you might be using codepaths that are rarely tested. If I'm reading things right, actually the default behaviour is (when no hints are supplied in kernel cmdline) : 1. systemd runs fsck on root from initramfs 2. systemd mounts root fs ro 3. switch-root onto real system 4. systemd-fsck-root runs 5. systemd-remount-fs remounts / as rw Also just noticed another interesting thing - systemd-fsck-root.service is only loaded dynamically, when /etc/fstab has a non-zero passno for /. So maybe the idea is that anyone running a regular and modern dracut/systemd setup sets passno=0 for / in fstab, with the knowledge that fsck of / is done by the initramfs. Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Wed, 02.07.14 12:39, Daniel Drake (dr...@endlessm.com) wrote: Then the system continues booting, switches root, and then system-fsck-root.service starts from the root fs, and runs fsck on / again. This is the bit I don't understand - we already checked from the initramfs, why check again now? I think the idea is that the unit is still around, hence won't get started a second time. Also, systemd-fsck-root.service in itself seems a little questionable, is it really safe in any context to run fsck on a mounted partition? That could modify data structures which have already been cached in memory in the kernel fs driver. In fact, e2fsck refuses to run on partitions that are mounted, even ones that are ro. Well this is how things were traditionally done on initrd-less systems. It's really a horrible thing to do, and people really shouldn't do it. I certainly wouldn't run my systems like that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Wed, Jul 2, 2014 at 1:36 PM, Lennart Poettering lenn...@poettering.net wrote: Then the system continues booting, switches root, and then system-fsck-root.service starts from the root fs, and runs fsck on / again. This is the bit I don't understand - we already checked from the initramfs, why check again now? I think the idea is that the unit is still around, hence won't get started a second time. dracut doesn't include systemd-fsck-root in the initramfs. I think there is good reason for that - systemd-fsck-root causes fsck to run on /, but at this point in the initramfs, / is a ramdisk and the thing that needs checking is at /sysroot. Also, systemd-fsck-root.service in itself seems a little questionable, is it really safe in any context to run fsck on a mounted partition? That could modify data structures which have already been cached in memory in the kernel fs driver. In fact, e2fsck refuses to run on partitions that are mounted, even ones that are ro. Well this is how things were traditionally done on initrd-less systems. It's really a horrible thing to do, and people really shouldn't do it. I certainly wouldn't run my systems like that. I agree, but am a little worried that systemd might do this kind-of by default. I now realise that this is a distro choice, they should probably set passno=0 in fstab, I wonder if they actually do... Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
'Twas brillig, and Daniel Drake at 02/07/14 13:29 did gyre and gimble: On Wed, Jul 2, 2014 at 1:13 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Thinking about it, I'm not sure how the new systemd would know that systemd-fsck@dev-something.service from the initramfs is the same thing as systemd-fsck-root.service. Maybe that's the problem? Currently systemd-fsck-root.service does nothing if / is mounted rw, which of course is used by almost everybody, so I think you might be using codepaths that are rarely tested. If I'm reading things right, actually the default behaviour is (when no hints are supplied in kernel cmdline) : 1. systemd runs fsck on root from initramfs 2. systemd mounts root fs ro I'd have thought that there would be more steps here... e.g.: 2a. Check /sysroot/forcefsck file's existence and run fsck if so. 3. switch-root onto real system 4. systemd-fsck-root runs 5. systemd-remount-fs remounts / as rw Also just noticed another interesting thing - systemd-fsck-root.service is only loaded dynamically, when /etc/fstab has a non-zero passno for /. So maybe the idea is that anyone running a regular and modern dracut/systemd setup sets passno=0 for / in fstab, with the knowledge that fsck of / is done by the initramfs. I don't really see why there would be a problem checking the /sysroot/etc/fstab here while still in the initramfs and doing the same thing in the pre-switchroot environment (perhaps umounting it again and mounting it fresh after the fsck if this is still something that is needed these days?), but as you point out I'm not sure what mechanism is used to tell e.g. systemd-fsck-root.service to do nothing... it would be easy to conditionalise this with some touched flag files in /run/initramfs/ tree if needed. 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] systemd-fsck-root semantics
'Twas brillig, and Daniel Drake at 02/07/14 13:43 did gyre and gimble: On Wed, Jul 2, 2014 at 1:36 PM, Lennart Poettering lenn...@poettering.net wrote: Then the system continues booting, switches root, and then system-fsck-root.service starts from the root fs, and runs fsck on / again. This is the bit I don't understand - we already checked from the initramfs, why check again now? I think the idea is that the unit is still around, hence won't get started a second time. dracut doesn't include systemd-fsck-root in the initramfs. I think there is good reason for that - systemd-fsck-root causes fsck to run on /, but at this point in the initramfs, / is a ramdisk and the thing that needs checking is at /sysroot. Does it really use the mountpoint? I thought the mountpoint was pretty much irrelevant. It should be all about the device-node. Also, systemd-fsck-root.service in itself seems a little questionable, is it really safe in any context to run fsck on a mounted partition? That could modify data structures which have already been cached in memory in the kernel fs driver. In fact, e2fsck refuses to run on partitions that are mounted, even ones that are ro. Well this is how things were traditionally done on initrd-less systems. It's really a horrible thing to do, and people really shouldn't do it. I certainly wouldn't run my systems like that. I agree, but am a little worried that systemd might do this kind-of by default. I now realise that this is a distro choice, they should probably set passno=0 in fstab, I wonder if they actually do... Whatever the outcome, systemd upstream should certainly do only safe things by default. The fact the unit is triggered automatically by the generator is IMO not by default, but your concern re the pass number is certainly justifiable. I guess that as most people use initramfs', an extra ConditionPathExists!=/run/initfamfs/skip-root-fsck wouldn't go astray, and dracut+co could learn to touch that file if they've properly analysed and taken care of root fsck'ing for you. There may of course be much nicer ways! 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] systemd-fsck-root semantics
'Twas brillig, and Colin Guthrie at 02/07/14 14:07 did gyre and gimble: I guess that as most people use initramfs', an extra ConditionPathExists!=/run/initfamfs/skip-root-fsck wouldn't go astray, and dracut+co could learn to touch that file if they've properly analysed and taken care of root fsck'ing for you. There may of course be much nicer ways! Actually there is nothing stopping dracut and co creating a /run/systemd/system/systemd-fsck-root.service symlink to /dev/null... that would achieve much the same result, although arguably may be less obvious to a user wondering why their fsck is not being run. 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] systemd-fsck-root semantics
On Jul 2, 2014, at 5:39 AM, Daniel Drake dr...@endlessm.com wrote: Hi, I'm trying to understand dracut/systemd fsck behaviour, in the context of an ext4 filesystem root mounted read-only from dracut, remaining read-only even when the system is fully booted (kiosk-style). I see that systemd's fstab-generator rightly creates a mount unit for /sysroot from the initramfs, and causes e2fsck to be run on it from inside the dracut initramfs, before it is mounted. So far so good. It's not wrong, but it seems unnecessary to fsck an ro file system. How is it becoming inconsistent if it's read only? Then the system continues booting, switches root, and then system-fsck-root.service starts from the root fs, and runs fsck on / again. This is the bit I don't understand - we already checked from the initramfs, why check again now? I'd say we're in a transitional state between whether initramfs and systemd should do fsck. And also whether fsck is the rule or exception. The three main Linux file systems used today: ext3/4, XFS, and Btrfs, two of three don't need and can't do fsck at boot. So the concept is obsolete for the majority (of file systems, not installations), with ext3/4 being the exception. At the moment throwing me for a loop is what to do about the EFI System partition on UEFI computers, which is FAT16/32. So it's back to 1985 and dealing with a non-journaled file system. Very often unclean shutdowns are causing FAT inconsistencies, I'd say more than half the time. Sometimes a boot time automatic fsck fixes these, other times they aren't and a manual fsck is needed. But this message is really easy to miss because the file system still gets mounted and it's just a matter of time before such a file system is beyond repair. So I'm not a fan of always mounting the ESP rw at /boot/efi as most (all?) Linux distros currently do (Window and OS X do not persistently mount the ESP, they're only mounted on demand for bootloader or firmware updates) as it seems too fragile. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Wed, Jul 02, 2014 at 12:33:01PM -0600, Chris Murphy wrote: On Jul 2, 2014, at 5:39 AM, Daniel Drake dr...@endlessm.com wrote: Hi, I'm trying to understand dracut/systemd fsck behaviour, in the context of an ext4 filesystem root mounted read-only from dracut, remaining read-only even when the system is fully booted (kiosk-style). I see that systemd's fstab-generator rightly creates a mount unit for /sysroot from the initramfs, and causes e2fsck to be run on it from inside the dracut initramfs, before it is mounted. So far so good. It's not wrong, but it seems unnecessary to fsck an ro file system. How is it becoming inconsistent if it's read only? You still need to remount / rw for administration tasks or updates. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpyyl9U8mlO8.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
В Wed, 2 Jul 2014 12:33:01 -0600 Chris Murphy li...@colorremedies.com пишет: On Jul 2, 2014, at 5:39 AM, Daniel Drake dr...@endlessm.com wrote: Hi, I'm trying to understand dracut/systemd fsck behaviour, in the context of an ext4 filesystem root mounted read-only from dracut, remaining read-only even when the system is fully booted (kiosk-style). I see that systemd's fstab-generator rightly creates a mount unit for /sysroot from the initramfs, and causes e2fsck to be run on it from inside the dracut initramfs, before it is mounted. So far so good. It's not wrong, but it seems unnecessary to fsck an ro file system. How is it becoming inconsistent if it's read only? How do you know it was not mounted rw last time? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
