mount other than rootfs problem

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?

Quoted 6 lines · 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.

Quoted 6 lines

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.

Quoted 11 lines · Cong Wang

Quoted 6 lines · 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?

Quoted 18 lines · Dave Young

Quoted 14 lines · Cong Wang

Quoted 8 lines · 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.

Quoted 5 lines

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.

Quoted 6 lines

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().

Quoted 25 lines · Cong Wang

Quoted 23 lines · Dave Young

Quoted 10 lines · Cong Wang

Quoted 8 lines · 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.

Quoted 4 lines

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

Quoted 2 lines

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

Quoted 8 lines

Quoted 7 lines

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?

Quoted 4 lines

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

Quoted 3 lines

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?

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

Quoted 8 lines

Quoted 7 lines

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?

Quoted 4 lines

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

Quoted 3 lines

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?

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

[..]

Quoted 4 lines

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.

Quoted 8 lines · Vivek Goyal

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

[..]

Quoted 4 lines

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

Quoted 1 line

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.

Quoted 8 lines · Vivek Goyal

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

[..]

Quoted 4 lines

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

Quoted 1 line

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
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 9 lines · Vivek Goyal

Quoted 8 lines · Vivek Goyal

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

[..]

Quoted 4 lines

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

Quoted 6 lines

Quoted 1 line

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

Quoted 19 lines · Dave Young

Quoted 15 lines · Vivek Goyal

Quoted 9 lines · Vivek Goyal

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

[..]

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 20 lines · Harald Hoyer

Quoted 19 lines · Dave Young

Quoted 15 lines · Vivek Goyal

Quoted 9 lines · Vivek Goyal

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

[..]

Quoted 4 lines

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.

Quoted 7 lines

Quoted 4 lines

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

Quoted 19 lines

Quoted 2 lines

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.

Quoted 5 lines

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.

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

[..]

Quoted 4 lines

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.

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

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?

Quoted 5 lines

Quoted 4 lines

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.

Quoted 9 lines

Yes, agree

Quoted 3 lines

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.

Quoted 1 line

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