mount other than rootfs problem

mount other than rootfs problem

[Dave Young]

Hi,

In current dracut modules there's still fstab-sys for mount something
other than root, So how about add a similar module ie. fstab-kdump which
contains the kdump target device/fstype, add mount-kdump.sh to mount all
the stuff. For rootfs we can use dracut mount point.

As discussion in mail archive I see nfs is a main problem for this
issue. I did not understand why nfs is special, could someone explain a bit?

-- 
Thanks
Dave

Re: mount other than rootfs problem

[Cong Wang]

于 2011年09月29日 10:55, Dave Young 写道:
> Hi,
>
> In current dracut modules there's still fstab-sys for mount something
> other than root, So how about add a similar module ie. fstab-kdump which
> contains the kdump target device/fstype, add mount-kdump.sh to mount all
> the stuff. For rootfs we can use dracut mount point.

I doubt fstab-sys module could mount all kinds of block devices, e.g.
LVM or RAID, because I see no code to detect/handle LVM/RAID in fstab-sys
or fs-lib module.

>
> As discussion in mail archive I see nfs is a main problem for this
> issue. I did not understand why nfs is special, could someone explain a bit?
>

Yeah, one reason that I can remember is that it depends on network module
which handles root device per nic.

But, we certainly want to find a way to handle non-root devices no matter
which kind it is, and a generic interface to express that we want to mount
some specific devices and let dracut to handle the module dependencies.

Thanks.

Re: mount other than rootfs problem

[Dave Young]

On 09/29/2011 11:18 PM, Cong Wang wrote:

> 于 2011年09月29日 10:55, Dave Young 写道:
>> Hi,
>>
>> In current dracut modules there's still fstab-sys for mount something
>> other than root, So how about add a similar module ie. fstab-kdump which
>> contains the kdump target device/fstype, add mount-kdump.sh to mount all
>> the stuff. For rootfs we can use dracut mount point.
> 
> I doubt fstab-sys module could mount all kinds of block devices, e.g.
> LVM or RAID, because I see no code to detect/handle LVM/RAID in fstab-sys
> or fs-lib module.


I just tried a simple lvm mount, it was skipped due to there's no dev
nodes. making the fstab-sys module depends on lvm also does not work,
but mannually call lvm_scan in rdshell, then mannually mounting the lvm
volume can success

So If we properly deal with the dependency issue it should be possible
to resolve. There's dracut module dependency currently, but question is
that is there dependency of hooks? such as make the mount-sys hook
depends on the lvm setup code, is it possible with current interface?

> 
>>
>> As discussion in mail archive I see nfs is a main problem for this
>> issue. I did not understand why nfs is special, could someone explain
>> a bit?
>>
> 
> Yeah, one reason that I can remember is that it depends on network module
> which handles root device per nic.
> 
> But, we certainly want to find a way to handle non-root devices no matter
> which kind it is, and a generic interface to express that we want to mount
> some specific devices and let dracut to handle the module dependencies.
> 
> Thanks.



-- 
Thanks
Dave

Re: mount other than rootfs problem

[Cong Wang]

于 2011年09月30日 10:17, Dave Young 写道:
> On 09/29/2011 11:18 PM, Cong Wang wrote:
>
>> 于 2011年09月29日 10:55, Dave Young 写道:
>>> Hi,
>>>
>>> In current dracut modules there's still fstab-sys for mount something
>>> other than root, So how about add a similar module ie. fstab-kdump which
>>> contains the kdump target device/fstype, add mount-kdump.sh to mount all
>>> the stuff. For rootfs we can use dracut mount point.
>>
>> I doubt fstab-sys module could mount all kinds of block devices, e.g.
>> LVM or RAID, because I see no code to detect/handle LVM/RAID in fstab-sys
>> or fs-lib module.
>
>
> I just tried a simple lvm mount, it was skipped due to there's no dev
> nodes. making the fstab-sys module depends on lvm also does not work,
> but mannually call lvm_scan in rdshell, then mannually mounting the lvm
> volume can success
>

Yeah, this is not strange, I bet you can also pass "rd_LVM_LV=" to
mount the target device.

> So If we properly deal with the dependency issue it should be possible
> to resolve. There's dracut module dependency currently, but question is
> that is there dependency of hooks? such as make the mount-sys hook
> depends on the lvm setup code, is it possible with current interface?
>

I don't think so, you called 'lvm_scan' and did mount manually, lvm
module itself will not mount it unless you add "rd_LVM_LV=". So, this
a not only a problem of module dependency, but also a problem
of lvm module code. For kdump, even using "rd_LVM_LV=" is not a good
choice, because we still need to convert the device name (or UUID) into
the correct kernel cmdline.

If some hook need some other module, then the whole module itself should
depend on that module, which can be expressed in depend().

Re: mount other than rootfs problem

[Dave Young]

On 09/30/2011 11:27 AM, Cong Wang wrote:

> 于 2011年09月30日 10:17, Dave Young 写道:
>> On 09/29/2011 11:18 PM, Cong Wang wrote:
>>
>>> 于 2011年09月29日 10:55, Dave Young 写道:
>>>> Hi,
>>>>
>>>> In current dracut modules there's still fstab-sys for mount something
>>>> other than root, So how about add a similar module ie. fstab-kdump
>>>> which
>>>> contains the kdump target device/fstype, add mount-kdump.sh to mount
>>>> all
>>>> the stuff. For rootfs we can use dracut mount point.
>>>
>>> I doubt fstab-sys module could mount all kinds of block devices, e.g.
>>> LVM or RAID, because I see no code to detect/handle LVM/RAID in
>>> fstab-sys
>>> or fs-lib module.
>>
>>
>> I just tried a simple lvm mount, it was skipped due to there's no dev
>> nodes. making the fstab-sys module depends on lvm also does not work,
>> but mannually call lvm_scan in rdshell, then mannually mounting the lvm
>> volume can success
>>
> 
> Yeah, this is not strange, I bet you can also pass "rd_LVM_LV=" to
> mount the target device.


Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
being called automaticlly via dependencies it will be good. OTOH fstab
is better than cmdlines as an interface for multi-target dumping

> 
>> So If we properly deal with the dependency issue it should be possible
>> to resolve. There's dracut module dependency currently, but question is
>> that is there dependency of hooks? such as make the mount-sys hook
>> depends on the lvm setup code, is it possible with current interface?
>>
> 
> I don't think so, you called 'lvm_scan' and did mount manually, lvm
> module itself will not mount it unless you add "rd_LVM_LV=". So, this
> a not only a problem of module dependency, but also a problem
> of lvm module code.


Yes, agree

>For kdump, even using "rd_LVM_LV=" is not a good
> choice, because we still need to convert the device name (or UUID) into
> the correct kernel cmdline.


not understand yet, could you help to explain or give an example?

> 
> If some hook need some other module, then the whole module itself should
> depend on that module, which can be expressed in depend().
> 



-- 
Thanks
Dave

Re: mount other than rootfs problem

[Cong Wang]

于 2011年09月30日 11:40, Dave Young 写道:
> On 09/30/2011 11:27 AM, Cong Wang wrote:
>
>> 于 2011年09月30日 10:17, Dave Young 写道:
>>> On 09/29/2011 11:18 PM, Cong Wang wrote:
>>>
>>>> 于 2011年09月29日 10:55, Dave Young 写道:
>>>>> Hi,
>>>>>
>>>>> In current dracut modules there's still fstab-sys for mount something
>>>>> other than root, So how about add a similar module ie. fstab-kdump
>>>>> which
>>>>> contains the kdump target device/fstype, add mount-kdump.sh to mount
>>>>> all
>>>>> the stuff. For rootfs we can use dracut mount point.
>>>>
>>>> I doubt fstab-sys module could mount all kinds of block devices, e.g.
>>>> LVM or RAID, because I see no code to detect/handle LVM/RAID in
>>>> fstab-sys
>>>> or fs-lib module.
>>>
>>>
>>> I just tried a simple lvm mount, it was skipped due to there's no dev
>>> nodes. making the fstab-sys module depends on lvm also does not work,
>>> but mannually call lvm_scan in rdshell, then mannually mounting the lvm
>>> volume can success
>>>
>>
>> Yeah, this is not strange, I bet you can also pass "rd_LVM_LV=" to
>> mount the target device.
>
>
> Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
> being called automaticlly via dependencies it will be good. OTOH fstab
> is better than cmdlines as an interface for multi-target dumping

Yes, but the problem is that lvm is supposed to handle this, what
we need to do is invent some interface to tell lvm module to mount
some specified device parsed in kdump module.

>
>>
>>> So If we properly deal with the dependency issue it should be possible
>>> to resolve. There's dracut module dependency currently, but question is
>>> that is there dependency of hooks? such as make the mount-sys hook
>>> depends on the lvm setup code, is it possible with current interface?
>>>
>>
>> I don't think so, you called 'lvm_scan' and did mount manually, lvm
>> module itself will not mount it unless you add "rd_LVM_LV=". So, this
>> a not only a problem of module dependency, but also a problem
>> of lvm module code.
>
>
> Yes, agree
>
>> For kdump, even using "rd_LVM_LV=" is not a good
>> choice, because we still need to convert the device name (or UUID) into
>> the correct kernel cmdline.
>
>
> not understand yet, could you help to explain or give an example?
>

Sure, for example, on my machine I need to convert /dev/mapper/vg_cr0-lv_home
to rd_LVM_LV=vg_cr0/lv_home.

Re: mount other than rootfs problem

[Vivek Goyal]

On Fri, Sep 30, 2011 at 11:40:12AM +0800, Dave Young wrote:

[..]
> 
> Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
> being called automaticlly via dependencies it will be good. OTOH fstab
> is better than cmdlines as an interface for multi-target dumping

Agreed that fstab.sys looks like a good interface to mouting non-root devices.

> 
> > 
> >> So If we properly deal with the dependency issue it should be possible
> >> to resolve. There's dracut module dependency currently, but question is
> >> that is there dependency of hooks? such as make the mount-sys hook
> >> depends on the lvm setup code, is it possible with current interface?
> >>
> > 
> > I don't think so, you called 'lvm_scan' and did mount manually, lvm
> > module itself will not mount it unless you add "rd_LVM_LV=". So, this
> > a not only a problem of module dependency, but also a problem
> > of lvm module code.
> 

lv_scan.sh seems to be parsing those rd_LVM_LV command line options to
come up with list of VGs and LVs to scan for. May be some script (probably
fstab-sys module) can leave some additional files in /tmp/ which lists
additional VGs and LVs to scan for. And this will be prepared by fstab-sys
module.

This is similar to lv_scan.sh reading /tmp/.lvm_scan-* files.

> 
> Yes, agree
> 
> >For kdump, even using "rd_LVM_LV=" is not a good
> > choice, because we still need to convert the device name (or UUID) into
> > the correct kernel cmdline.
> 
> 
> not understand yet, could you help to explain or give an example?

I think what he meant was that kdump.conf allows specifying UUID or LABEL
of the device to dump to. Assuming that these can directly be specified
in fstab.sys, or fstab-kdump.sys, then logic should be able to parse the
UUIDs, LABELs, and then traverse down the stack, figure out all the
dependencies.

Thanks
Vivek

Re: mount other than rootfs problem

[Vivek Goyal]

On Fri, Sep 30, 2011 at 02:38:39PM -0400, Vivek Goyal wrote:
> On Fri, Sep 30, 2011 at 11:40:12AM +0800, Dave Young wrote:
> 
> [..]
> > 
> > Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
> > being called automaticlly via dependencies it will be good. OTOH fstab
> > is better than cmdlines as an interface for multi-target dumping
> 
> Agreed that fstab.sys looks like a good interface to mouting non-root devices.

Having said that, looks like dracut builds all the state using command
line options. All the lvms, iscsi root, fcoe targets etc. So they might
expect everything to be passed on command line. In that case it will
become hard from kdump perspective.

Thanks
Vivek

Re: mount other than rootfs problem

[Cong Wang]

于 2011年10月01日 03:03, Vivek Goyal 写道:
> On Fri, Sep 30, 2011 at 02:38:39PM -0400, Vivek Goyal wrote:
>> On Fri, Sep 30, 2011 at 11:40:12AM +0800, Dave Young wrote:
>>
>> [..]
>>>
>>> Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
>>> being called automaticlly via dependencies it will be good. OTOH fstab
>>> is better than cmdlines as an interface for multi-target dumping
>>
>> Agreed that fstab.sys looks like a good interface to mouting non-root devices.
>
> Having said that, looks like dracut builds all the state using command
> line options. All the lvms, iscsi root, fcoe targets etc. So they might
> expect everything to be passed on command line. In that case it will
> become hard from kdump perspective.

Yeah, the problem is that we still need to detect which module is needed
to mount some specified device, which is duplicated, as the code is already
in these modules (e.g. is_lvm()).

Thanks.

Re: mount other than rootfs problem

[Dave Young]

On 10/01/2011 03:03 AM, Vivek Goyal wrote:

> On Fri, Sep 30, 2011 at 02:38:39PM -0400, Vivek Goyal wrote:
>> On Fri, Sep 30, 2011 at 11:40:12AM +0800, Dave Young wrote:
>>
>> [..]
>>>
>>> Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
>>> being called automaticlly via dependencies it will be good. OTOH fstab
>>> is better than cmdlines as an interface for multi-target dumping
>>
>> Agreed that fstab.sys looks like a good interface to mouting non-root devices.
> 
> Having said that, looks like dracut builds all the state using command
> line options. All the lvms, iscsi root, fcoe targets etc. So they might
> expect everything to be passed on command line. In that case it will
> become hard from kdump perspective.


There's file injection feature in dracut, if the kdump.conf params can
move to cmdline params we can just inject /etc/cmdline instead of pass
them to kexec

> 
> Thanks
> Vivek
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks
Dave

Re: mount other than rootfs problem

[Harald Hoyer]

On 12.10.2011 11:03, Dave Young wrote:
> On 10/01/2011 03:03 AM, Vivek Goyal wrote:
> 
>> On Fri, Sep 30, 2011 at 02:38:39PM -0400, Vivek Goyal wrote:
>>> On Fri, Sep 30, 2011 at 11:40:12AM +0800, Dave Young wrote:
>>>
>>> [..]
>>>>
>>>> Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
>>>> being called automaticlly via dependencies it will be good. OTOH fstab
>>>> is better than cmdlines as an interface for multi-target dumping
>>>
>>> Agreed that fstab.sys looks like a good interface to mouting non-root devices.
>>
>> Having said that, looks like dracut builds all the state using command
>> line options. All the lvms, iscsi root, fcoe targets etc. So they might
>> expect everything to be passed on command line. In that case it will
>> become hard from kdump perspective.
> 
> 
> There's file injection feature in dracut, if the kdump.conf params can
> move to cmdline params we can just inject /etc/cmdline instead of pass
> them to kexec
> 

I will add /etc/cmdline.d/ as a drop in for configs. This can also be used
easily for combined initramfs images.

Re: mount other than rootfs problem

[Vivek Goyal]

On Wed, Oct 12, 2011 at 11:22:34AM +0200, Harald Hoyer wrote:
> On 12.10.2011 11:03, Dave Young wrote:
> > On 10/01/2011 03:03 AM, Vivek Goyal wrote:
> > 
> >> On Fri, Sep 30, 2011 at 02:38:39PM -0400, Vivek Goyal wrote:
> >>> On Fri, Sep 30, 2011 at 11:40:12AM +0800, Dave Young wrote:
> >>>
> >>> [..]
> >>>>
> >>>> Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
> >>>> being called automaticlly via dependencies it will be good. OTOH fstab
> >>>> is better than cmdlines as an interface for multi-target dumping
> >>>
> >>> Agreed that fstab.sys looks like a good interface to mouting non-root devices.
> >>
> >> Having said that, looks like dracut builds all the state using command
> >> line options. All the lvms, iscsi root, fcoe targets etc. So they might
> >> expect everything to be passed on command line. In that case it will
> >> become hard from kdump perspective.
> > 
> > 
> > There's file injection feature in dracut, if the kdump.conf params can
> > move to cmdline params we can just inject /etc/cmdline instead of pass
> > them to kexec
> > 
> 
> I will add /etc/cmdline.d/ as a drop in for configs. This can also be used
> easily for combined initramfs images.

Harald,

We need something so that we can specify top level block device/uuid/label
on either commandline or through /etc/cmdline.d/*.config and then dracut
automatically figures out all the dependencies and packs all the relevant
modules.

For example, one might say in kdump.conf that save the dump to a file
system with UUID=xyz. Now one needs to figure out underlying devices,
traverse through device stack, bring up associated networking and 
traverse through networking stack.

I see in dracut seems to look for root device, and traverses through
block device stack and every modules packs its relevant files if
that type of device is found in stack.

So something like "extra_mount=dev/uuid/label" kind of command line
will help where one can specify extra mount targets which are mounted.

Thanks
Vivek

Re: mount other than rootfs problem

[Harald Hoyer]

On 12.10.2011 21:07, Vivek Goyal wrote:
> On Wed, Oct 12, 2011 at 11:22:34AM +0200, Harald Hoyer wrote:
>> On 12.10.2011 11:03, Dave Young wrote:
>>> On 10/01/2011 03:03 AM, Vivek Goyal wrote:
>>>
>>>> On Fri, Sep 30, 2011 at 02:38:39PM -0400, Vivek Goyal wrote:
>>>>> On Fri, Sep 30, 2011 at 11:40:12AM +0800, Dave Young wrote:
>>>>>
>>>>> [..]
>>>>>>
>>>>>> Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
>>>>>> being called automaticlly via dependencies it will be good. OTOH fstab
>>>>>> is better than cmdlines as an interface for multi-target dumping
>>>>>
>>>>> Agreed that fstab.sys looks like a good interface to mouting non-root devices.
>>>>
>>>> Having said that, looks like dracut builds all the state using command
>>>> line options. All the lvms, iscsi root, fcoe targets etc. So they might
>>>> expect everything to be passed on command line. In that case it will
>>>> become hard from kdump perspective.
>>>
>>>
>>> There's file injection feature in dracut, if the kdump.conf params can
>>> move to cmdline params we can just inject /etc/cmdline instead of pass
>>> them to kexec
>>>
>>
>> I will add /etc/cmdline.d/ as a drop in for configs. This can also be used
>> easily for combined initramfs images.
> 
> Harald,
> 
> We need something so that we can specify top level block device/uuid/label
> on either commandline or through /etc/cmdline.d/*.config and then dracut
> automatically figures out all the dependencies and packs all the relevant
> modules.
> 
> For example, one might say in kdump.conf that save the dump to a file
> system with UUID=xyz. Now one needs to figure out underlying devices,
> traverse through device stack, bring up associated networking and 
> traverse through networking stack.
> 
> I see in dracut seems to look for root device, and traverses through
> block device stack and every modules packs its relevant files if
> that type of device is found in stack.
> 
> So something like "extra_mount=dev/uuid/label" kind of command line
> will help where one can specify extra mount targets which are mounted.
> 
> Thanks
> Vivek

dracut only does this in hostonly mode... I guess, you will need hostonly, too,
to reduce the site of the initramfs.

Re: mount other than rootfs problem

[Vivek Goyal]

On Thu, Oct 13, 2011 at 11:19:03AM +0200, Harald Hoyer wrote:

[..]
> >> I will add /etc/cmdline.d/ as a drop in for configs. This can also be used
> >> easily for combined initramfs images.
> > 
> > Harald,
> > 
> > We need something so that we can specify top level block device/uuid/label
> > on either commandline or through /etc/cmdline.d/*.config and then dracut
> > automatically figures out all the dependencies and packs all the relevant
> > modules.
> > 
> > For example, one might say in kdump.conf that save the dump to a file
> > system with UUID=xyz. Now one needs to figure out underlying devices,
> > traverse through device stack, bring up associated networking and 
> > traverse through networking stack.
> > 
> > I see in dracut seems to look for root device, and traverses through
> > block device stack and every modules packs its relevant files if
> > that type of device is found in stack.
> > 
> > So something like "extra_mount=dev/uuid/label" kind of command line
> > will help where one can specify extra mount targets which are mounted.
> > 
> > Thanks
> > Vivek
> 
> dracut only does this in hostonly mode... I guess, you will need hostonly, too,
> to reduce the site of the initramfs.

Yes, we want to operate in host only mode (-H) as we want to build minimal
initramfs which is sufficient to take dump on that system for a specific
dump target.

Thanks
Vivek

Re: mount other than rootfs problem

[Dave Young]

On 10/01/2011 02:38 AM, Vivek Goyal wrote:

> On Fri, Sep 30, 2011 at 11:40:12AM +0800, Dave Young wrote:
> 
> [..]
>>
>> Add lvm_scan in mount-sys.sh also works, so if we can make lvm_scan
>> being called automaticlly via dependencies it will be good. OTOH fstab
>> is better than cmdlines as an interface for multi-target dumping
> 
> Agreed that fstab.sys looks like a good interface to mouting non-root devices.
> 
>>
>>>
>>>> So If we properly deal with the dependency issue it should be possible
>>>> to resolve. There's dracut module dependency currently, but question is
>>>> that is there dependency of hooks? such as make the mount-sys hook
>>>> depends on the lvm setup code, is it possible with current interface?
>>>>
>>>
>>> I don't think so, you called 'lvm_scan' and did mount manually, lvm
>>> module itself will not mount it unless you add "rd_LVM_LV=". So, this
>>> a not only a problem of module dependency, but also a problem
>>> of lvm module code.
>>
> 
> lv_scan.sh seems to be parsing those rd_LVM_LV command line options to
> come up with list of VGs and LVs to scan for. May be some script (probably
> fstab-sys module) can leave some additional files in /tmp/ which lists
> additional VGs and LVs to scan for. And this will be prepared by fstab-sys
> module.
> 
> This is similar to lv_scan.sh reading /tmp/.lvm_scan-* files.


Seems the /tmp/.lvm_scan-* file is created if blkid contains the LVM_*
signitures, but without lvm cmdline lvm_scan will not be called.

If lvm related cmdlines is set properly a check-for-lvm-devnode-exist
script will be created in initqueue/finished/, as long as the lvm
devnode is not created, lvm_scan will keep doing the scan until timeout.

> 
>>
>> Yes, agree
>>
>>> For kdump, even using "rd_LVM_LV=" is not a good
>>> choice, because we still need to convert the device name (or UUID) into
>>> the correct kernel cmdline.
>>
>>
>> not understand yet, could you help to explain or give an example?
> 
> I think what he meant was that kdump.conf allows specifying UUID or LABEL
> of the device to dump to. Assuming that these can directly be specified
> in fstab.sys, or fstab-kdump.sys, then logic should be able to parse the
> UUIDs, LABELs, and then traverse down the stack, figure out all the
> dependencies.


Maybe the lvm.uuid cmdline can be added for this?

> 
> Thanks
> Vivek



-- 
Thanks
Dave