[PATCH] dracut-module-setup: Return from iscsi path immediately for hardward iscsi without iBFT

[Minfei Huang]

On 09/30/15 at 02:47am, Dave Young wrote:
> I do not think it depends on rd. param for non-boot device.
> 
> rd.* is for dracut only, it is not kernel params, so dracut will check these param
> and do some setup.  For non-boot device, it is not mandatory for dracut to handle
> these setup. Since it is userspace scripts, one can setup them after bootup
> 
> [offlineimap is slow, thus reply in web mail, sorry for top reply]

As my known, the boot device should be exported before loading the
dracut code.

Maybe I should test such a case without rd.* to boot from the iSCSI
exported device.

Thanks
Minfei

> 
> ----- Original Message -----
> From: "Minfei Huang" <mhuang at redhat.com>
> To: "Dave Young" <dyoung at redhat.com>
> Cc: kexec at lists.fedoraproject.org, bhe at redhat.com
> Sent: Wednesday, September 30, 2015 2:44:04 PM
> Subject: Re: [PATCH] dracut-module-setup: Return from iscsi path immediately	for hardward iscsi without iBFT
> 
> On 09/30/15 at 02:37pm, Dave Young wrote:
> > > > I think 1st kernel parameter is only for boot device. non-boot you still need
> > > > pass extra parameter to 2nd kernel cmdline.
> > > > 
> > > > Again about the second question, have you consider the situation both 1 and 2 being
> > > > used? ie. 1) for crash device, 2) for root device.
> > > > 
> > > 
> > > I tested both boot and non-boot device as dumping target, and it works
> > > on beaker machine.
> > > 
> > 
> > But how does it work? suppose rd.* param are mandatory, who will pass it to 2nd kernel?
> > Suppose below case:
> > rootfs: a local scsi disk sda
> > after bootup, one can setup a non-boot disk for kdump ie. sdb.
> > 
> > There should be nothing in boot param.
> > 
> > Thanks
> > Dave
> 
> For iSCSI HBA, the only way to bring up is to append the rd.* in the
> command. Thus the kernel will export this device.
> 
> If there is no proper parameter in command, the device cann't be
> visible, including 1st kernel.
> 
> Thanks
> Minfei
> _______________________________________________
> kexec mailing list
> kexec at lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/kexec
> 
>