On 03/28/2017 at 05:08 PM, Baoquan He wrote:
On 03/28/17 at 05:03pm, Xunlei Pang wrote:
> On 03/28/2017 at 04:05 PM, Baoquan He wrote:
>> On 03/27/17 at 12:07pm, Xunlei Pang wrote:
>>> I found this problem when debugging "Transaction is destructive"
>>> (see the following patch) issue using nfs, in the case that nfs
>>> is mounted implicitly to the save path other than explicitly
>>> using the "nfs" directive in /etc/kdump.conf,
"is_nfs_dump_target"
>>> will return false, so this nfs mount will be added
"x-initrd.mount"
>>> option wrongly.
>>>
>>> It affects the systemd service behaviours when emergency failure
>>> happens as the code comment described.
>>>
>>> To fix it, we use "is_fs_type_nfs $_fstype" instead.
>>>
>>> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com>
>>> ---
>>> mkdumprd | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/mkdumprd b/mkdumprd
>>> index f30d9c2..f1bac01 100644
>>> --- a/mkdumprd
>>> +++ b/mkdumprd
>>> @@ -120,7 +120,7 @@ to_mount() {
>>> # 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
>>> + if ! is_fs_type_nfs $_fstype; then
>> This sounds reasonable. But one question comes up, checking fedora git
>> log, I found commit about this code adding was merged earlier than the
>> commit de95c74 ("mkdumprd: append "x-initrd.mount" to the mount
options.").
>>
>> May I assume since commit de95c74 has been added, x-initrd.mount adding
>> is not needed anymore?
Seems I copied the wrong commit. I mean this one:
002337c Introduce kdump error handling service
They should be different issues, this one is related to local-fs.target or
remote-fs.target,
according to the comments, if we add x-initrd.mount, it will be regarded as
local-fs.target
related other than remote-fs.target. Systemd handles the two targets in different ways.
Anyway, for nfs dumping using "nfs" directive or just mounted to the save path
should
make no difference.
Regards,
Xunlei
> x-initrd.mount and is_nfs_dump_target judgement are introduced in the same commit
de95c74,
> --- a/mkdumprd
> +++ b/mkdumprd
> @@ -106,6 +106,20 @@ to_mount() {
> _fstype=$(findmnt -k -f -n -r -o FSTYPE $_dev)
> _options=$(findmnt -k -f -n -r -o OPTIONS $_dev)
> _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.
> + # 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
>
> Which code do you mean is earlier than this?
>
> Regards,
> Xunlei
>
>>> _options="$_options,x-initrd.mount"
>>> fi
>>> _mntopts="$_target $_fstype $_options"
>>> --
>>> 1.8.3.1
>>> _______________________________________________
>>> kexec mailing list -- kexec(a)lists.fedoraproject.org
>>> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org