On 07/14/2017 at 01:29 PM, Dave Young wrote:
On 07/13/17 at 11:43am, Xunlei Pang wrote:
> After the following systemd commit, "x-initrd.mount"
> option became useless actually, we can safely remove
> it now.
>
> commit ce3f6d82b003f365f718f24e48f55b8a0372b924
> Author: nmartensen <nis.martensen(a)web.de>
> Date: Fri Jan 15 07:55:25 2016 +0100
>
> fstab-generator: remove bogus condition
>
> The sysroot mount is already taken care of by the
> add_sysroot_mount function. With this condition
> left in, we can we can get something like this:
>
> initrd-root-fs.target.requires
> `-- usr.mount -> /run/systemd/generator/usr.mount
>
> in the main system (i.e., not in the initramfs). In
> the initramfs, the previous condition already kicks in.
>
> diff --git a/src/fstab-generator/fstab-generator.c
> <snip>
> if (initrd)
> post = SPECIAL_INITRD_FS_TARGET;
> - else if (mount_in_initrd(me))
> - post = SPECIAL_INITRD_ROOT_FS_TARGET;
> else if (mount_is_network(me))
> post = SPECIAL_REMOTE_FS_TARGET;
> else
>
> "mount_in_initrd(me)" is true with "x-initrd.mount" option,
> the behaviour of systemd fstab generator changed after the
> above-mentioned patch, it always generates local mount units
> required by local-fs.target regardless of "x-initrd.mount".
>
> After failure, it enters dracut emergency, further triggers
> kdump emergency service, thus there is no problem.
>
> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com>
> ---
> mkdumprd | 15 +--------------
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/mkdumprd b/mkdumprd
> index 5a25853..468b564 100644
> --- a/mkdumprd
> +++ b/mkdumprd
> @@ -103,20 +103,7 @@ to_mount() {
> # kernel, filter it out here.
> _options=$(echo $_options | sed 's/noauto//')
> _options=${_options/#ro/rw} #mount fs target as rw in 2nd kernel
> - # "x-initrd.mount" mount failure will trigger isolate emergency
service
> - # W/o this, systemd won't isolate, thus we won't get to emergency.
Hi Xunlei,
After the systemd changes (already in Fedora?), have you tested the
local mount failure test case? Can kdump emergency take effect?
Yes, this systemd change has been in Fedora for a long time(at least half year).
Regards,
Xunlei
> - # This is not applicable to remote fs mount, because if we
use
> - # "x-initrd.mount", remote mount will become required by
> - # "initrd-root-fs.target", instead of "remote-fs.target".
That's how it is
> - # handled within systemd internal. We need remote mount to be required
> - # "remote-fs.target", because we need to bring up network before any
remote
> - # mount and "remote-fs.target" can be a checkpoint of that.
> - # If remote mount fails, dracut-initqueue will still start and once
> - # dracut-initqueue finishes, kdump service will start. Because remote mount
> - # failed, kdump service will fail and it will lead to kdump error handler.
> - if ! is_nfs_dump_target; then
> - _options="$_options,x-initrd.mount"
> - fi
> +
> _mntopts="$_target $_fstype $_options"
> #for non-nfs _dev converting to use udev persistent name
> if [ -b "$_source" ]; then
> --
> 1.8.3.1
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
Thanks
Dave