On 03/28/2017 at 05:55 PM, Baoquan He wrote:
On 03/28/17 at 05:22pm, Xunlei Pang wrote:
> 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:
>>>>> @@ -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.
See this paragraph in git log. Add x-initrd.mount just because emergency
service is triggered in non isolate mode, at that time kdump isolate
service has not been added yet, I believe. So with kdump isolate service
added, any mount failure will trigger isolate kdump error handler, does
it really have chance to care if it's x-initrd.mount added or not?
Now when mount in /etc/fstab fails, systemd would not consider it as
critical and it would continue to boot. In fact, emergency service is
triggered, but not in a isolation mode, and it results in the emergency
service getting shutdown at some point later of the boot process. We
need isolation otherwise we won't see any emergency service.
Hi Baoquan,
I think you are right.
The changelog of commit de95c74a7 ('mkdumprd: append "x-initrd.mount" to the
mount options.')
is misleading at least for now, it may be true when the patch was drafting.
After reading the system code(also confirm to my test results), the current behaviour of
systemd fstab generator is:
1) for "root=X" in the cmdline, it will generate sysroot.mount unit required by
initrd-root-fs.target
2) for mountinfo in /etc/fstab, for non-network mounts, it will generate mount units
required by local-fs.target
3) for mountinfo in /etc/fstab, for network mounts, it will generate mount units required
by remote-fs.target
4) for mountinfo in /sysroot/etc/fstab with "x-initrd.mount" option, it will
generate mount units required by initrd-fs.target
IOW, x-initrd.mount in local(initramfs) /etc/fstab has no effect on the type of required
target.
Regards,
Xunlei
> Anyway, for nfs dumping using "nfs" directive or just
mounted to the save path should
> make no difference.