On 09/24/13 at 09:43am, Vivek Goyal wrote:
On Tue, Sep 24, 2013 at 01:09:30PM +0800, WANG Chao wrote:
> On 09/23/13 at 03:47pm, Vivek Goyal wrote:
> > On Thu, Sep 05, 2013 at 12:47:22AM +0800, WANG Chao wrote:
> > > 1st kernel uses ip=ibft and rd.iscsi.firmware to log in ibft lun. In 2nd
> > > kernel, ibft lun can be logged in automatically, because 2nd kernel
> > > inherit 1st kernel cmdline.
> > >
> > > Currently kdump will configure netroot=iscsi:xxx if we find iscsi lun
> > > being used. In case of ibft, ip=ibft and rd.iscsi.firmware is enough for
> > > dracut to be aware of, otherwise netroot=iscsi:xxx will only confuse
> > > dracut and fail to log in ibft lun.
> > >
> > > So in kdump module, we should avoid handling iscsi lun if ibft.
> > >
> > > Signed-off-by: WANG Chao <chaowang(a)redhat.com>
> > > ---
> > > dracut-module-setup.sh | 15 +++++++++++++++
> > > 1 file changed, 15 insertions(+)
> > >
> > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > > index 517099c..252d17a 100755
> > > --- a/dracut-module-setup.sh
> > > +++ b/dracut-module-setup.sh
> > > @@ -268,6 +268,16 @@ kdump_install_conf() {
> > > rm -f /tmp/$$-kdump.conf
> > > }
> > >
> > > +kdump_is_ibft() {
> > > + local path=$1
> > > + local tgt_name fw_tgt_name
> > > +
> > > + tgt_name=$(kdump_iscsi_get_rec_val "$path"
"node.name")
> > > + fw_tgt_name=$(/sbin/iscsiadm -m fw 2>/dev/null | awk '$1 ==
"node.name" {print $3}')
> > > +
> > > + [ -n "$fw_tgt_name" ] && strstr
"$fw_tgt_name" "$tgt_name"
> > > +}
> > > +
> > > kdump_iscsi_get_rec_val() {
> > >
> > > local result
> > > @@ -323,6 +333,11 @@ kdump_setup_iscsi_device() {
> > > return 1
> > > fi
> > >
> > > + if kdump_is_ibft ${path}; then
> > > + dinfo "${path} is ibft, skip"
> >
> > So this is relying on the fact that ip=ibft and rd.iscsi.firmware has
> > been passed on command line. Is it always the case in first kernel?
>
> ip=ibft and rd.iscsi.firmware will be appended to cmdline automatically
> after installation. Because both of the cmdline args are *required* to
> boot an ibft box.
Will it not be the case only if root was on a lun as seen by ibft. What
if I have another network card in the system where I am doing regular
software iscsi and that's where my root is. Or my root is on local disk
but I have some iscsi luns exported using ibft and my dump destination
is an ibft lun?
I'm afraid yes. It's the case if root is on lun seen by ibft. I haven't
thought about these complicated you mentioned above.
I think for ibft, we have several combinations:
1. root fs is ibft
2. /boot is ibft, / is sw-iscsi
3. root fs is local, other mount point is ibft
My patch only handles the 1st case.
For the 2nd case, in order to mount /boot, "ip=ibft rd.iscsi.firmware"
has to be in cmdline. So we also need these two args in 2nd kernel
cmdline.
For the 3rd case, 1st kernel cmdline will not have "ip=ibft
rd.iscsi.firmware". To login ibft lun in 2nd kernel, we need to append
these two args to cmdline when generating kdump initrd.
>
> If users want to use ibft, they must have both ip=ibft and
> rd.iscsi.firmware in cmdline. I don't know if dracut or anaconda will
> change about it, but for now it's true.
So you are saying that even if root is not on ibft lun, dracut will
bring up ibft luns? Does not sound right to me. Have you tested it?
In my previous email, by "ibft", I really meant "root fs on a ibft
lun".
I thought ibft was only the case booting OS from iscsi (whole / is
iscsi).
Since you pointed out, now I know ibft lun can be used in many cases and
ibft is not just about boot from iscsi lun. Is that right?
I think if providing ip=ibft and rd.iscsi.firmware, dracut will bring
up ibft luns, even these luns are not root. I didn't test this. Once I
have a chance to borrow a ibft box again, I can test.
>
> > Can't I bring up ibft luns from user space later?
>
> You don't have to manually do this. ibft luns will be brought up in
> initrd.
Only if root is on ibft lun?
No. all luns seen by ibft if providing ip=ibft and rd.iscsi.firmware.
>
> > If yes, it might be better to always append ip=ibft and rd.iscsi.firmware
> > to command line option.
>
> If 1st kernel uses ibft, ip=ibft and rd.iscsi.firmware are already there
> in cmdline.
>
> If 1st kernel doesn't use ibft, I don't see a reason for ibft to be used
> in 2nd kernel.
>
> Providing duplicated ip=ibft might cause some unexpected behavior of
> dracut. I didn't test it. I'm not sure wether it's a good idea or not.
> But if you have strong reason or insist to do this, I'm fine with this.
You can write a function which appends an option to command line only
if it is not present already.
Will do.
So I think when dump target is ibft luns, we can append ip=ibft and
rd.iscsi.firmware to cmdline if they doesn't exist. dracut will bring up
all ibft luns including our dump target. What do you think?
Thanks
WANG Chao