Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On 07/30/13 at 06:52pm, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jul 31, 2013 at 12:46:22AM +0800, WANG Chao wrote: On 07/31/13 at 12:32am, WANG Chao wrote: On 07/30/13 at 03:46pm, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? rootflags=nofail works. Thanks. Although it results in a little difference between my approach, I prefer use this one than adding another cmdline param. I just find nofail option only works when mnt device doesn't exists. I think we treat nofail slightly differently, and don't make the .mount unit a requirement for local-fs.target or initrd-fs.target. Yes, I don't want sysroot.mount unit to be a requirement for initrd-root-fs.target. rootflags=nofail doesn't 100% work in this case. So a new paratmeter/flag has to be created for generating a sysroot.mount that Wants by initrd-root-fs.target. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tuesday 2013-07-30 20:41, Vivek Goyal wrote: FYI, I don't see any CC's on the original mail as displayed on GMane via NNTP... Neither do I, with a normal (non-NTTP, non-Gmail) setup. I am CCed in original mail and that's why I got a copy of it in my Inbox. If you did, you should be able to locate the second copy, received from the mailing list software. I am not sure how did Tom receive that mail. If my email id somehow automatically got stripped, I have no idea how that can happen. I am trying to look into systemd-devel archives but there does not seem to be any info who is CCed on the mail. Because there was no one CCed. Which either means that the original sender issued two different mail envelopes with two different mail bodies, or that the ML software stripped the CCs. Looking at the Message-Id and perhaps Received: field could perhaps reveal different messages and/or the path where one envelope was split. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Fri, Aug 02, 2013 at 12:15:32PM +0200, Jan Engelhardt wrote: On Tuesday 2013-07-30 20:41, Vivek Goyal wrote: FYI, I don't see any CC's on the original mail as displayed on GMane via NNTP... Neither do I, with a normal (non-NTTP, non-Gmail) setup. I am CCed in original mail and that's why I got a copy of it in my Inbox. If you did, you should be able to locate the second copy, received from the mailing list software. I have received only one copy. Did not receive any copy from mailing list. I think that is because I have not changed default user options in mailing list settings which allow one to specifiy whether to send mailing list copy or not if one is explicitly CCed in mail. I am not sure how did Tom receive that mail. If my email id somehow automatically got stripped, I have no idea how that can happen. I am trying to look into systemd-devel archives but there does not seem to be any info who is CCed on the mail. Because there was no one CCed. Which either means that the original sender issued two different mail envelopes with two different mail bodies, or that the ML software stripped the CCs. I suspect that's the case here. Somehow ML stripped CC. In reply mails CC are intact. So not sure why it will happen only with first mail. Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
'Twas brillig, and WANG Chao at 01/08/13 06:36 did gyre and gimble: On 07/30/13 at 04:40pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 4:13 PM, Harald Hoyer har...@redhat.com wrote: On 07/30/2013 03:46 PM, Zbigniew Jędrzejewski-Szmek wrote: Maybe rootfsflags=nofail could do be used as this flag? rootfsflags=nofail sounds ok, if it is not used for booting the initial system. Yeah, you are right, this looks like it should just work. Though the behavior of initrd-parse-etc.service and initrd-switch-root.service will be non-deterministic if this flag is specified (unless I'm missing something). Maybe they should be explicitly ordered After/Wants=sysroot.mount ? That may cause a long timeout, but at least there will be no emergency mode. No, guys, nofail mount option will *only* work when device (or should I say filesystem) doesn't exist. From mount(8): [..] _nofail_ Do not report errors for this device if it does not exist. I'm not sure that description is 100% true under systemd. Looking at the code, it seems to control the dependencies of the mount units (namely changing a Requires= to the softer Wants=) So if filesystem is corrupted or something else fails the sysroot.mount, initrd-root-fs.target will never be reached. Is this actually true? Given the above comment? But that said, it could easily be that the / mountpoint is handled specially in systemd (I've not looked at the code that closely) which may explain why nofail doesn't work for it like it would for other mounts... 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: introduce rd.weak_sysroot to bypass failures in sysroot.mount
[Resend because I fail at reply-all] 'Twas brillig, and WANG Chao at 01/08/13 06:36 did gyre and gimble: On 07/30/13 at 04:40pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 4:13 PM, Harald Hoyer har...@redhat.com wrote: On 07/30/2013 03:46 PM, Zbigniew Jędrzejewski-Szmek wrote: Maybe rootfsflags=nofail could do be used as this flag? rootfsflags=nofail sounds ok, if it is not used for booting the initial system. Yeah, you are right, this looks like it should just work. Though the behavior of initrd-parse-etc.service and initrd-switch-root.service will be non-deterministic if this flag is specified (unless I'm missing something). Maybe they should be explicitly ordered After/Wants=sysroot.mount ? That may cause a long timeout, but at least there will be no emergency mode. No, guys, nofail mount option will *only* work when device (or should I say filesystem) doesn't exist. From mount(8): [..] _nofail_ Do not report errors for this device if it does not exist. I'm not sure that description is 100% true under systemd. Looking at the code, it seems to control the dependencies of the mount units (namely changing a Requires= to the softer Wants=) It may be worth trying to push an updated description into the mount man page to mention systemd's behaviour here? So if filesystem is corrupted or something else fails the sysroot.mount, initrd-root-fs.target will never be reached. Is this actually true? Given the above comment? It could easily be that the / mountpoint is handled more specially in systemd tho' (I've not looked at the code that closely). 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: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On 08/01/13 at 08:49am, Colin Guthrie wrote: [Resend because I fail at reply-all] 'Twas brillig, and WANG Chao at 01/08/13 06:36 did gyre and gimble: On 07/30/13 at 04:40pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 4:13 PM, Harald Hoyer har...@redhat.com wrote: On 07/30/2013 03:46 PM, Zbigniew Jędrzejewski-Szmek wrote: Maybe rootfsflags=nofail could do be used as this flag? rootfsflags=nofail sounds ok, if it is not used for booting the initial system. Yeah, you are right, this looks like it should just work. Though the behavior of initrd-parse-etc.service and initrd-switch-root.service will be non-deterministic if this flag is specified (unless I'm missing something). Maybe they should be explicitly ordered After/Wants=sysroot.mount ? That may cause a long timeout, but at least there will be no emergency mode. No, guys, nofail mount option will *only* work when device (or should I say filesystem) doesn't exist. From mount(8): [..] _nofail_ Do not report errors for this device if it does not exist. I'm not sure that description is 100% true under systemd. Looking at the code, it seems to control the dependencies of the mount units (namely changing a Requires= to the softer Wants=) rootflags=nofail only results in mount -o nofail /dev/root /sysroot OTOH, bool variable nofail from add_mount(.., bool nofail, ..) is used to changing Requires= to Wants. It may be worth trying to push an updated description into the mount man page to mention systemd's behaviour here? Nothing to do with systemd. systemd will just pass nofail and other mount options to mount. So if filesystem is corrupted or something else fails the sysroot.mount, initrd-root-fs.target will never be reached. Is this actually true? Given the above comment? It could easily be that the / mountpoint is handled more specially in systemd tho' (I've not looked at the code that closely). Yes, that's true. sysroot.mount is automatically generated and mandatory be required by initrd-root-fs.target. Thanks WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On 07/30/2013 09:14 PM, Vivek Goyal wrote: On Wed, Jul 31, 2013 at 12:46:22AM +0800, WANG Chao wrote: On 07/31/13 at 12:32am, WANG Chao wrote: On 07/30/13 at 03:46pm, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? rootflags=nofail works. Thanks. Although it results in a little difference between my approach, I prefer use this one than adding another cmdline param. I just find nofail option only works when mnt device doesn't exists. What if the filesytem is corrupted? sysroot.mount will and initrd-root-fs.target will never reach. Right. In kdump environment, for most of the users default of dropping into a shell does not make sense. If some server crashes some where and we are not able to take dump due to some failure, most of the users will like that system reboots automatically and services are back up online. I see that right now rd.action_on_fail is parsed by emergency.service and service does not start if this parameter is specified. Can't we interpret this parameter little differently. That is this parameter modifies the OnFailure= behavior. So by default OnFailure= is emergency.service which is equivalent to a shell. A user can force change of behavior by specifying command line. rd.action_on_failure=shell (OnFailure=emergency.service) rd.action_on_failure=reboot (OnFailure=reboot) rd.action_on_failure=continue (OnFailure=continue) Now action_on_failure=continue will effectively pretend that unit start was successful and go ahead with starting next unit. This might be little contentious though as other dependent units will fail in unknown ways. Now by default kdump can use rd.acton_on_failure=continue and try to save dump. If it can't due to previous failures, then it will anyway reboot the system. Also if emergency.service stops parsing rd.action_on_failure, then kdump module will be able to start emergency.service too when it sees there is a problem. Right now when kdump module tries to start emergency.service it fails because it looks at acton_on_fail parameter (Another issue Bao is trying to solve). Thanks Vivek Why not install your own version of emergency.service in the kdump dracut module, which parses rd.action_on_failure and acts accordingly. Or replace emergency.service in the dracut cmdline hook according to rd.action_on_failure. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
'Twas brillig, and Harald Hoyer at 31/07/13 11:19 did gyre and gimble: On 07/30/2013 09:14 PM, Vivek Goyal wrote: On Wed, Jul 31, 2013 at 12:46:22AM +0800, WANG Chao wrote: On 07/31/13 at 12:32am, WANG Chao wrote: On 07/30/13 at 03:46pm, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? rootflags=nofail works. Thanks. Although it results in a little difference between my approach, I prefer use this one than adding another cmdline param. I just find nofail option only works when mnt device doesn't exists. What if the filesytem is corrupted? sysroot.mount will and initrd-root-fs.target will never reach. Right. In kdump environment, for most of the users default of dropping into a shell does not make sense. If some server crashes some where and we are not able to take dump due to some failure, most of the users will like that system reboots automatically and services are back up online. I see that right now rd.action_on_fail is parsed by emergency.service and service does not start if this parameter is specified. Can't we interpret this parameter little differently. That is this parameter modifies the OnFailure= behavior. So by default OnFailure= is emergency.service which is equivalent to a shell. A user can force change of behavior by specifying command line. rd.action_on_failure=shell (OnFailure=emergency.service) rd.action_on_failure=reboot (OnFailure=reboot) rd.action_on_failure=continue (OnFailure=continue) Now action_on_failure=continue will effectively pretend that unit start was successful and go ahead with starting next unit. This might be little contentious though as other dependent units will fail in unknown ways. Now by default kdump can use rd.acton_on_failure=continue and try to save dump. If it can't due to previous failures, then it will anyway reboot the system. Also if emergency.service stops parsing rd.action_on_failure, then kdump module will be able to start emergency.service too when it sees there is a problem. Right now when kdump module tries to start emergency.service it fails because it looks at acton_on_fail parameter (Another issue Bao is trying to solve). Thanks Vivek Why not install your own version of emergency.service in the kdump dracut module, which parses rd.action_on_failure and acts accordingly. Or replace emergency.service in the dracut cmdline hook according to rd.action_on_failure. I was going to suggest this yesterday but as I'm not familiar with kdump stuff I wasn't sure if I'd missed something, so kept quiet. Glad the suggestion has come up now tho' :) As for the 2nd option above, if emergency.service was replaced at runtime it would require a systemctl daemon-reload which is probably not idea. Maybe better to replace it statically in the kdump module as per your first suggest and make it implement the logic needed at runtime if/when it's called would be better. 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: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Wed, Jul 31, 2013 at 12:19:06PM +0200, Harald Hoyer wrote: On 07/30/2013 09:14 PM, Vivek Goyal wrote: On Wed, Jul 31, 2013 at 12:46:22AM +0800, WANG Chao wrote: On 07/31/13 at 12:32am, WANG Chao wrote: On 07/30/13 at 03:46pm, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? rootflags=nofail works. Thanks. Although it results in a little difference between my approach, I prefer use this one than adding another cmdline param. I just find nofail option only works when mnt device doesn't exists. What if the filesytem is corrupted? sysroot.mount will and initrd-root-fs.target will never reach. Right. In kdump environment, for most of the users default of dropping into a shell does not make sense. If some server crashes some where and we are not able to take dump due to some failure, most of the users will like that system reboots automatically and services are back up online. I see that right now rd.action_on_fail is parsed by emergency.service and service does not start if this parameter is specified. Can't we interpret this parameter little differently. That is this parameter modifies the OnFailure= behavior. So by default OnFailure= is emergency.service which is equivalent to a shell. A user can force change of behavior by specifying command line. rd.action_on_failure=shell (OnFailure=emergency.service) rd.action_on_failure=reboot (OnFailure=reboot) rd.action_on_failure=continue (OnFailure=continue) Now action_on_failure=continue will effectively pretend that unit start was successful and go ahead with starting next unit. This might be little contentious though as other dependent units will fail in unknown ways. Now by default kdump can use rd.acton_on_failure=continue and try to save dump. If it can't due to previous failures, then it will anyway reboot the system. Also if emergency.service stops parsing rd.action_on_failure, then kdump module will be able to start emergency.service too when it sees there is a problem. Right now when kdump module tries to start emergency.service it fails because it looks at acton_on_fail parameter (Another issue Bao is trying to solve). Thanks Vivek Why not install your own version of emergency.service in the kdump dracut module, which parses rd.action_on_failure and acts accordingly. Or replace emergency.service in the dracut cmdline hook according to rd.action_on_failure. That is doable but I think there is still one more issue. What happens to rest of the systemd services. Once a service fails, systemd will recognize it as failure and start emergency.service. Once emergency.service exits, what will systemd do. Will it continue to start other services which are dependent on failed service. I will guess it will not start. Because dependent services are supposed to be started only if previous service started successfully. If that's the case, then just replacing emergency.service is not a solution. In fact, I think that's how things are currently working. emergency.service does not start if acton_on_fail=continue is specified on command line. ConditionKernelCommandLine=!action_on_fail=continue So core of the problem here is that systemd needs to be aware that user wants to continue to start other services despite the fact that previous service failed. And using action_on_failure= command line to trigger change of behavior is one way of doing it. Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Wed, Jul 31, 2013 at 09:44:01AM -0400, Vivek Goyal wrote: On Wed, Jul 31, 2013 at 12:19:06PM +0200, Harald Hoyer wrote: On 07/30/2013 09:14 PM, Vivek Goyal wrote: On Wed, Jul 31, 2013 at 12:46:22AM +0800, WANG Chao wrote: On 07/31/13 at 12:32am, WANG Chao wrote: On 07/30/13 at 03:46pm, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? rootflags=nofail works. Thanks. Although it results in a little difference between my approach, I prefer use this one than adding another cmdline param. I just find nofail option only works when mnt device doesn't exists. What if the filesytem is corrupted? sysroot.mount will and initrd-root-fs.target will never reach. Right. In kdump environment, for most of the users default of dropping into a shell does not make sense. If some server crashes some where and we are not able to take dump due to some failure, most of the users will like that system reboots automatically and services are back up online. I see that right now rd.action_on_fail is parsed by emergency.service and service does not start if this parameter is specified. Can't we interpret this parameter little differently. That is this parameter modifies the OnFailure= behavior. So by default OnFailure= is emergency.service which is equivalent to a shell. A user can force change of behavior by specifying command line. rd.action_on_failure=shell (OnFailure=emergency.service) rd.action_on_failure=reboot (OnFailure=reboot) rd.action_on_failure=continue (OnFailure=continue) Now action_on_failure=continue will effectively pretend that unit start was successful and go ahead with starting next unit. This might be little contentious though as other dependent units will fail in unknown ways. Now by default kdump can use rd.acton_on_failure=continue and try to save dump. If it can't due to previous failures, then it will anyway reboot the system. Also if emergency.service stops parsing rd.action_on_failure, then kdump module will be able to start emergency.service too when it sees there is a problem. Right now when kdump module tries to start emergency.service it fails because it looks at acton_on_fail parameter (Another issue Bao is trying to solve). Thanks Vivek Why not install your own version of emergency.service in the kdump dracut module, which parses rd.action_on_failure and acts accordingly. Or replace emergency.service in the dracut cmdline hook according to rd.action_on_failure. That is doable but I think there is still one more issue. What happens to rest of the systemd services. Once a service fails, systemd will recognize it as failure and start emergency.service. Once emergency.service exits, what will systemd do. Will it continue to start other services which are dependent on failed service. I will guess it will not start. Because dependent services are supposed to be started only if previous service started successfully. If that's the case, then just replacing emergency.service is not a solution. In fact, I think that's how things are currently working. emergency.service does not start if acton_on_fail=continue is specified on command line. ConditionKernelCommandLine=!action_on_fail=continue So core of the problem here is that systemd needs to be aware that user wants to continue to start other services despite the fact that previous service failed. And using action_on_failure= command line to trigger change of behavior is one way of doing it. Ok, I noticed the commit to not run emergency.service in action_on_fail=continue is mentioned. commit dcae873414ff643e1de790f256e414923e2aef8b Author: Harald Hoyer har...@redhat.com Date: Thu May 30 11:14:39 2013 +0200 systemd/emergency.service: do not run for action_on_fail=continue same as for dracut-emergency.service Apart from the issue of other services not starting, we are facing another issue. And that is, kdump module wants to start a bash shell upon failure and start emergency.service. And now that fails because we are booted with action_on_fail=continue. If
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On 07/30/13 at 04:40pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 4:13 PM, Harald Hoyer har...@redhat.com wrote: On 07/30/2013 03:46 PM, Zbigniew Jędrzejewski-Szmek wrote: Maybe rootfsflags=nofail could do be used as this flag? rootfsflags=nofail sounds ok, if it is not used for booting the initial system. Yeah, you are right, this looks like it should just work. Though the behavior of initrd-parse-etc.service and initrd-switch-root.service will be non-deterministic if this flag is specified (unless I'm missing something). Maybe they should be explicitly ordered After/Wants=sysroot.mount ? That may cause a long timeout, but at least there will be no emergency mode. No, guys, nofail mount option will *only* work when device (or should I say filesystem) doesn't exist. From mount(8): [..] _nofail_ Do not report errors for this device if it does not exist. So if filesystem is corrupted or something else fails the sysroot.mount, initrd-root-fs.target will never be reached. Thanks WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao chaow...@redhat.com wrote: If specified kernel command line rd.weak_sysroot, fstab-generate will generate a weaker version of sysroot.mount: - It's not required by initrd-root-fs.target. - It's not before initrd-root-fs.target. So that failure in the weaker sysroot.mount will not fail initrd-root-fs.target. And systemd will try continue rather than entering isolated emergency mode. Can you give an example case where this is useful? I.e., what is the setup and how is boot supposed to succeed with a failing sysroot? -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On 07/30/13 at 02:05pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao chaow...@redhat.com wrote: If specified kernel command line rd.weak_sysroot, fstab-generate will generate a weaker version of sysroot.mount: - It's not required by initrd-root-fs.target. - It's not before initrd-root-fs.target. So that failure in the weaker sysroot.mount will not fail initrd-root-fs.target. And systemd will try continue rather than entering isolated emergency mode. Can you give an example case where this is useful? I.e., what is the setup and how is boot supposed to succeed with a failing sysroot? Some initrd that using systemd, isn't serverd as a general purpose boot initrd. In case of kdump, 2nd kernel initrd is used to mount non-root local/remote filesystem and dump vmcore there. The kdump script is running right before switch-root and will reboot after saving vmcore. So mounting sysroot isn't quite justified in this case. But it's still acceptable (since it's readonly mount), as long as it's not keeping systemd from reaching initrd.target (so kdump script can run later). Thanks WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
[CC harald]
Not sure if this is right way to do or not but I will give more
background about the issue.
This assumption seems to be built into initramfs and systemd that root
should always be mountable. If one can't mount root, it is a fatal
failure.
But in case of kdump initramfs, this assumption is no more valid. Core
might be being saved to a target which is not root (say over ssh). And
even if mounting root fails, it is ok.
So we kind of need a mode (possibly driven by command line option) where
if mouting root failed, it is ok and continue with mouting other targets
and kdump module will then handle errors.
Thanks
Vivek
On Tue, Jul 30, 2013 at 07:53:11PM +0800, WANG Chao wrote:
If specified kernel command line rd.weak_sysroot, fstab-generate will
generate a weaker version of sysroot.mount:
- It's not required by initrd-root-fs.target.
- It's not before initrd-root-fs.target.
So that failure in the weaker sysroot.mount will not fail
initrd-root-fs.target. And systemd will try continue rather than
entering isolated emergency mode.
Signed-off-by: WANG Chao chaow...@redhat.com
---
man/kernel-command-line.xml | 10 ++
man/systemd-fstab-generator.xml | 10 ++
src/fstab-generator/fstab-generator.c | 5 -
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index a4b7d13..0c2e97d 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -274,6 +274,16 @@
/varlistentry
varlistentry
+
termvarnamerd.weak_sysroot/varname/term
+
+listitem
+paraConfigures the sysroot.mount
+logic in initrd. For details, see
+
citerefentryrefentrytitlesystemd-fstab-generator/refentrytitlemanvolnum8/manvolnum/citerefentry./para
+/listitem
+/varlistentry
+
+varlistentry
termvarnamemodules-load=/varname/term
termvarnamerd.modules-load=/varname/term
diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml
index 4bd25bf..de0ed2f 100644
--- a/man/systemd-fstab-generator.xml
+++ b/man/systemd-fstab-generator.xml
@@ -101,6 +101,16 @@
the initrd. /para/listitem
/varlistentry
+varlistentry
+
termvarnamerd.weak_sysroot/varname/term
+
+listitemparaIf specified, systemd will
+ingore failures in sysroot.mount and try to
+continue rather than enter emergency mode.
+It is honored only by initial RAM disk
+(initrd). /para/listitem
+/varlistentry
+
/variablelist
/refsect1
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index c17299f..449e725 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -492,6 +492,7 @@ static int parse_new_root_from_proc_cmdline(void) {
char *w, *state;
int r;
size_t l;
+bool weak = false;
r = read_one_line_file(/proc/cmdline, line);
if (r 0) {
@@ -544,6 +545,8 @@ static int parse_new_root_from_proc_cmdline(void) {
free(opts);
opts = o;
+} else if (streq(word, rd.weak_sysroot)) {
+weak=true;
}
}
@@ -558,7 +561,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, false, false, false,
+r = add_mount(what, /sysroot, type, opts, 0, false, weak, false,
false, NULL, NULL, NULL,
SPECIAL_INITRD_ROOT_FS_TARGET, /proc/cmdline);
return (r 0) ? r : 0;
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tue, Jul 30, 2013 at 2:27 PM, WANG Chao chaow...@redhat.com wrote: On 07/30/13 at 02:05pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao chaow...@redhat.com wrote: - It's not before initrd-root-fs.target. In case of kdump, 2nd kernel initrd is used to mount non-root local/remote filesystem and dump vmcore there. The kdump script is running right before switch-root and will reboot after saving vmcore. So mounting sysroot isn't quite justified in this case. But it's still acceptable (since it's readonly mount), as long as it's not keeping systemd from reaching initrd.target (so kdump script can run later). If you don't have the Before=initrd-root-fs.target it means that you'll have a race: sometimes the rootfs will be mounted before kdump does whatever it does, and sometimes it won't. Would an option be to not specify a root= at all in your case? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On 07/30/2013 03:46 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? Zbyszek rootfsflags=nofail sounds ok, if it is not used for booting the initial system. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tue, Jul 30, 2013 at 4:02 PM, Tom Gundersen t...@jklm.no wrote: On Tue, Jul 30, 2013 at 2:27 PM, WANG Chao chaow...@redhat.com wrote: On 07/30/13 at 02:05pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao chaow...@redhat.com wrote: - It's not before initrd-root-fs.target. In case of kdump, 2nd kernel initrd is used to mount non-root local/remote filesystem and dump vmcore there. The kdump script is running right before switch-root and will reboot after saving vmcore. So mounting sysroot isn't quite justified in this case. But it's still acceptable (since it's readonly mount), as long as it's not keeping systemd from reaching initrd.target (so kdump script can run later). If you don't have the Before=initrd-root-fs.target it means that you'll have a race: sometimes the rootfs will be mounted before kdump does whatever it does, and sometimes it won't. Would an option be to not specify a root= at all in your case? Nothing should make assumptions about root= not specified at the kernel command line. It is reserved to make auto-discovery by partition type UUID work. It needs an explicit value to trigger non-common, non-default behavior; otherwise things would likely break in the future. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tue, Jul 30, 2013 at 02:05:08PM +0200, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao chaow...@redhat.com wrote: If specified kernel command line rd.weak_sysroot, fstab-generate will generate a weaker version of sysroot.mount: - It's not required by initrd-root-fs.target. - It's not before initrd-root-fs.target. So that failure in the weaker sysroot.mount will not fail initrd-root-fs.target. And systemd will try continue rather than entering isolated emergency mode. Can you give an example case where this is useful? I.e., what is the setup and how is boot supposed to succeed with a failing sysroot? Hi, Can you please not drop people listed in CC in original thread from conversation. Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tue, Jul 30, 2013 at 04:02:17PM +0200, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 2:27 PM, WANG Chao chaow...@redhat.com wrote: On 07/30/13 at 02:05pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao chaow...@redhat.com wrote: - It's not before initrd-root-fs.target. In case of kdump, 2nd kernel initrd is used to mount non-root local/remote filesystem and dump vmcore there. The kdump script is running right before switch-root and will reboot after saving vmcore. So mounting sysroot isn't quite justified in this case. But it's still acceptable (since it's readonly mount), as long as it's not keeping systemd from reaching initrd.target (so kdump script can run later). If you don't have the Before=initrd-root-fs.target it means that you'll have a race: sometimes the rootfs will be mounted before kdump does whatever it does, and sometimes it won't. Would an option be to not specify a root= at all in your case? Not specifying root= is not an option as it serves as backup dump target for us. So our primary target might be send dump over network but for some reason it fails, based on user config option, we will dump core to root in /var/crash. Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tue, Jul 30, 2013 at 4:13 PM, Harald Hoyer har...@redhat.com wrote: On 07/30/2013 03:46 PM, Zbigniew Jędrzejewski-Szmek wrote: Maybe rootfsflags=nofail could do be used as this flag? rootfsflags=nofail sounds ok, if it is not used for booting the initial system. Yeah, you are right, this looks like it should just work. Though the behavior of initrd-parse-etc.service and initrd-switch-root.service will be non-deterministic if this flag is specified (unless I'm missing something). Maybe they should be explicitly ordered After/Wants=sysroot.mount ? That may cause a long timeout, but at least there will be no emergency mode. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On 07/30/13 at 09:51am, Vivek Goyal wrote:
On Tue, Jul 30, 2013 at 07:53:11PM +0800, WANG Chao wrote:
If specified kernel command line rd.weak_sysroot, fstab-generate will
generate a weaker version of sysroot.mount:
- It's not required by initrd-root-fs.target.
- It's not before initrd-root-fs.target.
So that failure in the weaker sysroot.mount will not fail
initrd-root-fs.target. And systemd will try continue rather than
entering isolated emergency mode.
Signed-off-by: WANG Chao chaow...@redhat.com
Chao, so why rd.action_on_fail=continue is not sufficient here? So if
mounting root fails, and if rd.action_on_fail=continue, then systemd
should just continue.
rd.action_on_fail is a check condition switch for
dracut-emergency.service. It only controls whether the emergency service
can be started or not.
If sysroot.mount fails, initrd-root-fs.target won't be reached. Our
kdump script running under dracut-pre-pivot.service, which has a
dependency list:
dracut-pre-pivot.service
- initrd.target
- initrd-root-fs.target
- sysroot.mount
If rd.action_on_fail=continue isn't set, a failing sysroot.mount will
trigger emergency service and emergency service is started. Kdump fails.
If rd.action_on_fail=continue is set, a failing sysroot.mount will also
trigger emergency service, but emergency service wouldn't be started.
Because that service is switched off and can't be started. Then systemd
will hang (we haven't reached initrd-root-fs.target yet) because the
left services will only run after initrd-root-fs.target.
Or it will be considered an initramfs parameter and we need to come
up with a new one for systemd?
dracut can't do it. systemd is hard-coded to mount root (sysroot.mount).
Or may be if rd.action_on_fail is set, it automtically does some
action which conveys to systemd to continue after failures.
rd.action_on_fail is just simply mask emergency.service. It can't let
systemd continue against failures.
Thanks,
WANG Chao
Thanks
Vivek
---
man/kernel-command-line.xml | 10 ++
man/systemd-fstab-generator.xml | 10 ++
src/fstab-generator/fstab-generator.c | 5 -
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index a4b7d13..0c2e97d 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -274,6 +274,16 @@
/varlistentry
varlistentry
+
termvarnamerd.weak_sysroot/varname/term
+
+listitem
+paraConfigures the sysroot.mount
+logic in initrd. For details, see
+
citerefentryrefentrytitlesystemd-fstab-generator/refentrytitlemanvolnum8/manvolnum/citerefentry./para
+/listitem
+/varlistentry
+
+varlistentry
termvarnamemodules-load=/varname/term
termvarnamerd.modules-load=/varname/term
diff --git a/man/systemd-fstab-generator.xml
b/man/systemd-fstab-generator.xml
index 4bd25bf..de0ed2f 100644
--- a/man/systemd-fstab-generator.xml
+++ b/man/systemd-fstab-generator.xml
@@ -101,6 +101,16 @@
the initrd. /para/listitem
/varlistentry
+varlistentry
+
termvarnamerd.weak_sysroot/varname/term
+
+listitemparaIf specified, systemd will
+ingore failures in sysroot.mount and try to
+continue rather than enter emergency mode.
+It is honored only by initial RAM disk
+(initrd). /para/listitem
+/varlistentry
+
/variablelist
/refsect1
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index c17299f..449e725 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -492,6 +492,7 @@ static int parse_new_root_from_proc_cmdline(void) {
char *w, *state;
int r;
size_t l;
+bool weak = false;
r = read_one_line_file(/proc/cmdline, line);
if (r 0) {
@@ -544,6 +545,8 @@ static int parse_new_root_from_proc_cmdline(void) {
free(opts);
opts = o;
+} else if (streq(word, rd.weak_sysroot)) {
+weak=true;
}
}
@@ -558,7 +561,7 @@ static int
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On 07/30/13 at 04:02pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 2:27 PM, WANG Chao chaow...@redhat.com wrote: On 07/30/13 at 02:05pm, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao chaow...@redhat.com wrote: - It's not before initrd-root-fs.target. In case of kdump, 2nd kernel initrd is used to mount non-root local/remote filesystem and dump vmcore there. The kdump script is running right before switch-root and will reboot after saving vmcore. So mounting sysroot isn't quite justified in this case. But it's still acceptable (since it's readonly mount), as long as it's not keeping systemd from reaching initrd.target (so kdump script can run later). If you don't have the Before=initrd-root-fs.target it means that you'll have a race: sometimes the rootfs will be mounted before kdump does whatever it does, and sometimes it won't. Would an option be to not specify a root= at all in your case? We share the same concern. A simple way is the script check if root is mounted and determine the next step. But strip root= doesn't sound good to me :( ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On 07/30/13 at 03:46pm, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? rootflags=nofail works. Thanks. Although it results in a little difference between my approach, I prefer use this one than adding another cmdline param. Thanks again. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Wed, Jul 31, 2013 at 12:46:22AM +0800, WANG Chao wrote: On 07/31/13 at 12:32am, WANG Chao wrote: On 07/30/13 at 03:46pm, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? rootflags=nofail works. Thanks. Although it results in a little difference between my approach, I prefer use this one than adding another cmdline param. I just find nofail option only works when mnt device doesn't exists. I think we treat nofail slightly differently, and don't make the .mount unit a requirement for local-fs.target or initrd-fs.target. Zbyszek What if the filesytem is corrupted? sysroot.mount will and initrd-root-fs.target will never reach. -- they are not broken. they are refucktored -- alxchk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
'Twas brillig, and Vivek Goyal at 30/07/13 15:26 did gyre and gimble: On Tue, Jul 30, 2013 at 02:05:08PM +0200, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao chaow...@redhat.com wrote: If specified kernel command line rd.weak_sysroot, fstab-generate will generate a weaker version of sysroot.mount: - It's not required by initrd-root-fs.target. - It's not before initrd-root-fs.target. So that failure in the weaker sysroot.mount will not fail initrd-root-fs.target. And systemd will try continue rather than entering isolated emergency mode. Can you give an example case where this is useful? I.e., what is the setup and how is boot supposed to succeed with a failing sysroot? Hi, Can you please not drop people listed in CC in original thread from conversation. FYI, I don't see any CC's on the original mail as displayed on GMane via NNTP... 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: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tue, Jul 30, 2013 at 07:34:01PM +0100, Colin Guthrie wrote: 'Twas brillig, and Vivek Goyal at 30/07/13 15:26 did gyre and gimble: On Tue, Jul 30, 2013 at 02:05:08PM +0200, Tom Gundersen wrote: On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao chaow...@redhat.com wrote: If specified kernel command line rd.weak_sysroot, fstab-generate will generate a weaker version of sysroot.mount: - It's not required by initrd-root-fs.target. - It's not before initrd-root-fs.target. So that failure in the weaker sysroot.mount will not fail initrd-root-fs.target. And systemd will try continue rather than entering isolated emergency mode. Can you give an example case where this is useful? I.e., what is the setup and how is boot supposed to succeed with a failing sysroot? Hi, Can you please not drop people listed in CC in original thread from conversation. FYI, I don't see any CC's on the original mail as displayed on GMane via NNTP... I am CCed in original mail and that's why I got a copy of it in my Inbox. I am not sure how did Tom receive that mail. If my email id somehow automatically got stripped, I have no idea how that can happen. I am trying to look into systemd-devel archives but there does not seem to be any info who is CCed on the mail. Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Tue, Jul 30, 2013 at 8:41 PM, Vivek Goyal vgo...@redhat.com wrote: On Tue, Jul 30, 2013 at 07:34:01PM +0100, Colin Guthrie wrote: 'Twas brillig, and Vivek Goyal at 30/07/13 15:26 did gyre and gimble: FYI, I don't see any CC's on the original mail as displayed on GMane via NNTP... I am CCed in original mail and that's why I got a copy of it in my Inbox. I am not sure how did Tom receive that mail. If my email id somehow automatically got stripped, I have no idea how that can happen. I am trying to look into systemd-devel archives but there does not seem to be any info who is CCed on the mail. I don't know how that happened (I always use Reply to All). I received the email via systemd-devel (using GMail) and I see no cc's in the original mail. I see cc's in the follow-up emails just fine though... Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount
On Wed, Jul 31, 2013 at 12:46:22AM +0800, WANG Chao wrote: On 07/31/13 at 12:32am, WANG Chao wrote: On 07/30/13 at 03:46pm, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 30, 2013 at 09:43:16AM -0400, Vivek Goyal wrote: [CC harald] Not sure if this is right way to do or not but I will give more background about the issue. This assumption seems to be built into initramfs and systemd that root should always be mountable. If one can't mount root, it is a fatal failure. But in case of kdump initramfs, this assumption is no more valid. Core might be being saved to a target which is not root (say over ssh). And even if mounting root fails, it is ok. So we kind of need a mode (possibly driven by command line option) where if mouting root failed, it is ok and continue with mouting other targets and kdump module will then handle errors. Maybe rootfsflags=nofail could do be used as this flag? rootflags=nofail works. Thanks. Although it results in a little difference between my approach, I prefer use this one than adding another cmdline param. I just find nofail option only works when mnt device doesn't exists. What if the filesytem is corrupted? sysroot.mount will and initrd-root-fs.target will never reach. Right. In kdump environment, for most of the users default of dropping into a shell does not make sense. If some server crashes some where and we are not able to take dump due to some failure, most of the users will like that system reboots automatically and services are back up online. I see that right now rd.action_on_fail is parsed by emergency.service and service does not start if this parameter is specified. Can't we interpret this parameter little differently. That is this parameter modifies the OnFailure= behavior. So by default OnFailure= is emergency.service which is equivalent to a shell. A user can force change of behavior by specifying command line. rd.action_on_failure=shell (OnFailure=emergency.service) rd.action_on_failure=reboot (OnFailure=reboot) rd.action_on_failure=continue (OnFailure=continue) Now action_on_failure=continue will effectively pretend that unit start was successful and go ahead with starting next unit. This might be little contentious though as other dependent units will fail in unknown ways. Now by default kdump can use rd.acton_on_failure=continue and try to save dump. If it can't due to previous failures, then it will anyway reboot the system. Also if emergency.service stops parsing rd.action_on_failure, then kdump module will be able to start emergency.service too when it sees there is a problem. Right now when kdump module tries to start emergency.service it fails because it looks at acton_on_fail parameter (Another issue Bao is trying to solve). Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
