On 2016/06/12 at 13:16, Xunlei Pang wrote:
On 2016/06/12 at 12:01, Xunlei Pang wrote:
> On 2016/06/12 at 10:35, Dave Young wrote:
>> On 06/12/16 at 10:05am, Xunlei Pang wrote:
>>> On 2016/06/08 at 10:16, Dave Young wrote:
>>>> Hi,
>>>> On 06/06/16 at 05:00pm, Xunlei Pang wrote:
>>>>> On 2016/06/06 at 11:12, Dave Young wrote:
>>>>>> Hi Xunlei,
>>>>>>
>>>>>> On 06/06/16 at 10:43am, Xunlei Pang wrote:
>>>>>>> On 2016/06/06 at 09:55, Dave Young wrote:
>>>>>>>> On 06/06/16 at 09:01am, Xunlei Pang wrote:
>>>>>>>>> On 2016/06/02 at 16:48, Dave Young wrote:
>>>>>>>>>> On 06/02/16 at 04:21pm, Xunlei Pang wrote:
>>>>>>>>>>> On 2016/06/02 at 15:46, Dave Young wrote:
>>>>>>>>>>>> Hi, Xunlei
>>>>>>>>>>>>
>>>>>>>>>>>> Seems I sent wrong draft, here is the
right one:
>>>>>>>>>>>>
>>>>>>>>>>>> Add a question about below
>>>>>>>>>>>> --add-driver "nfs nfsv4"
>>>>>>>>>>>>
>>>>>>>>>>>> Why should we add them? if we addes
dracut 95nfs module then it will install
>>>>>>>>>>>> all the nfs kernel modules and network
module.
>>>>>>>>>>> Yeah, dracut 95nfs module has
>>>>>>>>>>> installkernel() {
>>>>>>>>>>> instmods nfs sunrpc ipv6 nfsv2 nfsv3
nfsv4 nfs_acl nfs_layout_nfsv41_files
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> But actually during my test, I found that if
nfs was not mounted, some of the modules
>>>>>>>>>>> (for example nfsv4)will fail to be installed
by instmods.
>>>>>>>>>> Hmm, it may related to we use hostonly, could you
check the instmods function
>>>>>>>>>> to see if we can handle it without adding drivers
in dracut args?
>>>>>>>>> You're right, it's due to the hostonly dracut
option, and it's not nfs-only, it's a common
>>>>>>>>> issue due to the target not mounted beforehand.
>>>>>>>>>
>>>>>>>>> Currently, I can't think of a nice way to handle
it without adding drivers explicitly.
>>>>>>>> Does --force-add works?
>>>>>>> I doesn't work, the "nfs" dracut module is ok,
it's the "instmods" in dracut's "nfs" that doesn't work.
>>>>>>> But with the other reply to specify the right
"nfsv4" filesytem type, it should work for us.
>>>>>> If --force-add is meant to bypass hostonly then it should be
extended to
>>>>>> also work in instmods then we can use force-add for these --mount
so
>>>>>> that one do not need add extra kernel modules.
>>>>> "--force_add" affects check() in module_setup.sh.
>>>>>
>>>>> For nfs, it is:
>>>>> # called by dracut
>>>>> check() {
>>>>> # If our prerequisites are not met, fail anyways.
>>>>> require_any_binary rpcbind portmap || return 1
>>>>> require_binaries rpc.statd mount.nfs mount.nfs4 umount || return
1
>>>>>
>>>>> [[ $hostonly ]] || [[ $mount_needs ]] && {
>>>>> for fs in "${host_fs_types[@]}"; do
>>>>> [[ "$fs" == "nfs" ]] &&
return 0
>>>>> [[ "$fs" == "nfs3" ]] &&
return 0
>>>>> [[ "$fs" == "nfs4" ]] &&
return 0
>>>>> done
>>>>> return 255
>>>>> }
>>>>> return 0
>>>>> }
>>>>>
>>>>> so only affects the dracut modules to be added.
>>>>>
>>>>> For nfs instmods, dracut handles it in installkernel(), it is:
>>>>> # called by dracut
>>>>> installkernel() {
>>>>> instmods nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl
nfs_layout_nfsv41_files
>>>>> }
>>>>>
>>>>> "The --force-add extension to instmods" will involve many
dracut's fundamental changes.
>>>> So there are two problems here.
>>>>
>>>> 1) --mount parsing and add nfs ko files in another reply
>>>> 2) --force-add only affects module check
>>>>
>>>> For 1), the original logic about nfs module seems wrong. One can setup
>>>> nfs4 in config files, but just use mount -t nfs, it will actually use
>>>> nfs4 kernel module. (Need verification..). If I am right then in case
>>>> mount_needs for nfs all nfs kernel module should be added.
>>> The original design needs nfs to be mounted beforehand, although users
>>> can use "mount -t nfs" for nfs4, but findmnt will get the right
"nfs4" fstype,
>>> also the related modules(nfsv4.ko) were loaded after the mount, so there is
>>> no problem for instmods to install "nfsv4,ko".
>>>
>>> The current implementation of dracut:
>>> function inst1mod() {
>>> <snip>
>>> # If we are building a host-specific initramfs and this
>>> # module is not already loaded, move on to the next one.
>>> [[ $hostonly ]] \
>>> && ! module_is_host_only "$_mod" \
>>> && return 0
>>>
>>> module_is_host_only() {
>>> local _mod=$1
>>> local _modenc a i _k _s _v _aliases
>>> _mod=${_mod##*/}
>>> _mod=${_mod%.ko}
>>> _modenc=${_mod//-/_}
>>>
>>> [[ " $add_drivers " == *\ ${_mod}\ * ]] && return 0
>>>
>>> # check if module is loaded
>>> [[ ${host_modules["$_modenc"]} ]] && return 0
>>>
>>> Thus for $hostonly mode, it will fail to install any ko not loaded if not
explicitly added via "--add-drivers".
>>>
>>> I am not quite clear about "mount_needs" you mentioned, from the
code it seems also to be only related to dracut's module check.
>> mount_needs is introduced for adding dracut modules for --mount needed,
>> but yes it only handles dracut modules in check() function, it may need
>> to extend to inst kernel modules.
>>
>> OTOH, since we have mount_needs why do we need to add 95nfs dracut
>> modules in kdump code? Shouldn't it been added via mount_needs check?
> Yes, agree, I think kdump needn't add "nfs" dracut module explicitly.
> The check_mount should be able to add it properly for us, as we have
> nfs "--mount" info, the host_fs_types[] will contain the "nfs*"
fstype.
>
>> Another issue is we may need use force_add because we are using hostonly
>> mode along with mount_needs, we can not use mount_needs but without
>> respecting hostonly for adding non-hostonly kernel modules..
>> So we should still force add 95nfs dracut modules in out code and extend
>> force add to unset hostonly during handling kernel modules. It make
>> sense because force-add already do that in module check functions it has
>> already unset hostonly that means it has higer priority than hostonly.
> force_add is semantically better for the purpose of this patch, but OTOH this patch
> actually doesn't only deal with nfs, it's for a general purpose
"--mount".
>
> So I would rather rely on mount_needs to force "instmods".
From my tests, unlike nfsv4, nfs/ext[234]/xfs can work properly, becasue in
90kernel-modules/module-setup.sh installkernel():
for i in $(host_fs_all); do
hostonly='' instmods $i
done
So for these fstypes, they have a valid mapping (or same) name to their ko names, say
"xfs.ko" for "xfs", "ext4.ko" for "ext3",
and they can be handled properly(as hostonly was unset).
But for fstype "nfs[2-4]", its ko is "nfsv[2-4].ko", if we do a
mapping like discussed previously, tests show it can work properly:
for i in $(host_fs_all); do
+ if [[ $i = nfs[2-4] ]]; then
+ i=${i/nfs/nfsv}
+ fi
hostonly='' instmods $i
done
This will be a simple fix, and can omit explicitly kdump adding "nfs" dracut
module for all cases.
From "man nfs" : The fstype field contains "nfs". Use of the
"nfs4" fstype in /etc/fstab is deprecated.
So I guess we can add all related ko modules for "nfs" fstype here, like the
patch below?
for i in $(host_fs_all); do
+ if [[ $i = nfs ]]; then
+ # From "man nfs": The fstype field contains
"nfs". Use of the "nfs4" fstype in /etc/fstab is deprecated.
+ # For "nfs" fstype, we better install all the possible ko
modules(from 95nfs/module-setup.sh installkernel).
+ i="nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl
nfs_layout_nfsv41_files"
+ elif [[ $i = nfs[3-4] ]]; then
+ # For example, map nfs4 to use nfsv4.ko
+ i=${i/nfs/nfsv}
+ fi
hostonly='' instmods $i
done
Or, if it is not acceptable on dracut's side, we can add "--add-drivers" for
"nfs sunrpc ipv6 nfsv2 nfsv3 nfsv4 nfs_acl nfs_layout_nfsv41_files"
in kdump code in this patch like that in the early versions, any comment?
Regards,
Xunlei