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.
Regards,
Xunlei
>>> For 2), extend --force-add to installkernel() is also
reasonable, just
>>> pass some variables to instmods function may work like some EVN
>>> varialbes so it only affects the callback from specific dracut module.
>>>
>>> But if 1) works maybe we can leave 2) in todo list and discuss it later
>>> when we have to do it.
>> From my description above, I'm afraid 1) can't work, or do I miss
something?
> Yes, agreed.
>
> Thanks
> Dave
>
>> Regards,
>> Xunlei
>>
>>> Thanks
>>> Dave