12:29 a.m.
Hardware iscsi can export the iscsi device before starting to load the
kernel code, which setups the iscsi card using the config stored in
hardward iscsi card memory.
kdump need not do anything for this sort of hardware iscsi card, if this
card does not have the feature iBFT. IBFT can export the iscsi
configuration from hardware iscsi card memroy to current running kernel.
Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m
session -r /sys/block/xxx", due to limitation of iscsi info exported by
kernel.
Once the machine is plugged in this sort of hardware iscsi card, kdump
returns as soon as possible.
Signed-off-by: Minfei Huang <mhuang(a)redhat.com>
---
dracut-module-setup.sh | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index 9b398eb..e2fef9b 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -507,16 +507,6 @@ kdump_setup_iscsi_device() {
local netroot_conf="${initdir}/etc/cmdline.d/50iscsi.conf"
local initiator_conf="/etc/iscsi/initiatorname.iscsi"
- dinfo "Found iscsi component $1"
-
- # Check once before getting explicit values, so we can output a decent
- # error message.
-
- if ! /sbin/iscsiadm -m session -r ${path} >/dev/null ; then
- derror "Unable to find iscsi record for $path"
- return 1
- fi
-
tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn\[0\].address")
@@ -583,7 +573,18 @@ kdump_check_iscsi_targets () {
until [[ -d sys || -d iscsi_session ]]; do
cd ..
done
- [[ -d iscsi_session ]] && kdump_setup_iscsi_device "$PWD"
+ if [[ -d iscsi_session ]]; then
+ dinfo "Found iscsi component $PWD"
+
+ # Hardware iscsi without the iBFT will fail to get
+ # iscsi session info, and return non-zero
+ # We need not do anything for this sort of hardware iscsi
+ /sbin/iscsiadm -m session -r "$PWD" 2>&- >/dev/null
+ if [ $? -eq 0 ]; then
+ # start to take care of iBFT
+ kdump_setup_iscsi_device "$PWD"
+ fi
+ fi
)
[[ $hostonly ]] || [[ $mount_needs ]] && {
--
2.1.0
1:39 a.m.
On 09/24/15 at 01:29pm, Minfei Huang wrote:
Hardware iscsi can export the iscsi device before starting to load
the
kernel code, which setups the iscsi card using the config stored in
hardward iscsi card memory.
kdump need not do anything for this sort of hardware iscsi card, if this
card does not have the feature iBFT. IBFT can export the iscsi
configuration from hardware iscsi card memroy to current running kernel.
Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m
session -r /sys/block/xxx", due to limitation of iscsi info exported by
kernel.
Once the machine is plugged in this sort of hardware iscsi card, kdump
returns as soon as possible.
Since we do not know much about iscsi, could you describe the basic infomation
about them?
1. how many type of cases we should consider for iscsi?
2. what is the difference between them, how to diffrentiate them.
3. how to setup them (basic steps)
BTW, I found a basic documentation about initiator and targets:
https://www.thomas-krenn.com/en/wiki/ISCSI_Basics#iSCSI_Initiator
Signed-off-by: Minfei Huang <mhuang(a)redhat.com>
---
dracut-module-setup.sh | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index 9b398eb..e2fef9b 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -507,16 +507,6 @@ kdump_setup_iscsi_device() {
local netroot_conf="${initdir}/etc/cmdline.d/50iscsi.conf"
local initiator_conf="/etc/iscsi/initiatorname.iscsi"
- dinfo "Found iscsi component $1"
-
- # Check once before getting explicit values, so we can output a decent
- # error message.
-
- if ! /sbin/iscsiadm -m session -r ${path} >/dev/null ; then
- derror "Unable to find iscsi record for $path"
- return 1
- fi
-
There may be other case for iscsiadm error out, so silent fail here?
Looks like Vivek intended to add such error message in original code.
tgt_name=$(kdump_iscsi_get_rec_val ${path}
"node.name")
tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn\[0\].address")
@@ -583,7 +573,18 @@ kdump_check_iscsi_targets () {
until [[ -d sys || -d iscsi_session ]]; do
cd ..
done
- [[ -d iscsi_session ]] && kdump_setup_iscsi_device "$PWD"
+ if [[ -d iscsi_session ]]; then
+ dinfo "Found iscsi component $PWD"
+
+ # Hardware iscsi without the iBFT will fail to get
+ # iscsi session info, and return non-zero
+ # We need not do anything for this sort of hardware iscsi
+ /sbin/iscsiadm -m session -r "$PWD" 2>&- >/dev/null
+ if [ $? -eq 0 ]; then
+ # start to take care of iBFT
It was target for software iscsi, so how to take care of iBFT?
+ kdump_setup_iscsi_device "$PWD"
+ fi
+ fi
)
[[ $hostonly ]] || [[ $mount_needs ]] && {
--
2.1.0
_______________________________________________
kexec mailing list
kexec(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/kexec
5:03 a.m.
On 09/25/15 at 02:39pm, Dave Young wrote:
On 09/24/15 at 01:29pm, Minfei Huang wrote:
> Hardware iscsi can export the iscsi device before starting to load the
> kernel code, which setups the iscsi card using the config stored in
> hardward iscsi card memory.
>
> kdump need not do anything for this sort of hardware iscsi card, if this
> card does not have the feature iBFT. IBFT can export the iscsi
> configuration from hardware iscsi card memroy to current running kernel.
> Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m
> session -r /sys/block/xxx", due to limitation of iscsi info exported by
> kernel.
>
> Once the machine is plugged in this sort of hardware iscsi card, kdump
> returns as soon as possible.
Since we do not know much about iscsi, could you describe the basic infomation
about them?
1. how many type of cases we should consider for iscsi?
There are three iscsi initiators we use more frequently.
1) software iscsi initiator
2) iSCSI HBA
3) iBFT
2. what is the difference between them, how to diffrentiate them.
1) software iscsi initiator
- We can setup the iscsi environemnt by using tgt suit. It is more
continent to setup the iscsi without the hardware supporting.
2) iSCSI HBA
- System has no ability to detect the iscsi session config. The
usage of exported iSCSI device is the same as local SCSI device.
3) iBFT
- The iSCSI Bios Firmware Table (iBFT) is a table that is created in
memory which is mapped with the iSCSI card firmware. Thus we can get
the session config according to the command iscsiadm.
3. how to setup them (basic steps)
1) software iscsi initiator
- According to the command iscsiadm to setup the available seesion,
and the session info should be passed manually
2) iSCSI HBA
- Do nothing, except for passing "rd.iscsi.firmware=1" to the
kernel. The iSCSI device will use the config stored in firmware to
setup the session.
3) iBFT
- Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to the kernel
to
setup the session.
Thanks
Minfei
10:10 p.m.
On 09/25/15 at 06:03pm, Minfei Huang wrote:
On 09/25/15 at 02:39pm, Dave Young wrote:
> On 09/24/15 at 01:29pm, Minfei Huang wrote:
> > Hardware iscsi can export the iscsi device before starting to load the
> > kernel code, which setups the iscsi card using the config stored in
> > hardward iscsi card memory.
> >
> > kdump need not do anything for this sort of hardware iscsi card, if this
> > card does not have the feature iBFT. IBFT can export the iscsi
> > configuration from hardware iscsi card memroy to current running kernel.
> > Thus iscsiadm cann't get the iscsi session info using "iscsiadm -m
> > session -r /sys/block/xxx", due to limitation of iscsi info exported by
> > kernel.
> >
> > Once the machine is plugged in this sort of hardware iscsi card, kdump
> > returns as soon as possible.
>
> Since we do not know much about iscsi, could you describe the basic infomation
> about them?
>
> 1. how many type of cases we should consider for iscsi?
There are three iscsi initiators we use more frequently.
1) software iscsi initiator
2) iSCSI HBA
3) iBFT
>
> 2. what is the difference between them, how to diffrentiate them.
1) software iscsi initiator
- We can setup the iscsi environemnt by using tgt suit. It is more
continent to setup the iscsi without the hardware supporting.
2) iSCSI HBA
- System has no ability to detect the iscsi session config. The
usage of exported iSCSI device is the same as local SCSI device.
3) iBFT
- The iSCSI Bios Firmware Table (iBFT) is a table that is created in
memory which is mapped with the iSCSI card firmware. Thus we can get
the session config according to the command iscsiadm.
>
> 3. how to setup them (basic steps)
1) software iscsi initiator
- According to the command iscsiadm to setup the available seesion,
and the session info should be passed manually
2) iSCSI HBA
- Do nothing, except for passing "rd.iscsi.firmware=1" to the
kernel. The iSCSI device will use the config stored in firmware to
setup the session.
So assume your patch is for addressing 2), if it is a boot disk there should
be rd.iscsi.firmware=1 in /proc/cmdline, but if it is not a boot disk, we need
pass this param to second kernel?
What if there's both 2) and 1) existed?
3) iBFT
- Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to the kernel
to
setup the session.
Thanks
Minfei
_______________________________________________
kexec mailing list
kexec(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/kexec
11:01 p.m.
On 09/30/15 at 11:10am, Dave Young wrote:
On 09/25/15 at 06:03pm, Minfei Huang wrote:
> On 09/25/15 at 02:39pm, Dave Young wrote:
> > On 09/24/15 at 01:29pm, Minfei Huang wrote:
> > > Hardware iscsi can export the iscsi device before starting to load the
> > > kernel code, which setups the iscsi card using the config stored in
> > > hardward iscsi card memory.
> > >
> > > kdump need not do anything for this sort of hardware iscsi card, if this
> > > card does not have the feature iBFT. IBFT can export the iscsi
> > > configuration from hardware iscsi card memroy to current running kernel.
> > > Thus iscsiadm cann't get the iscsi session info using "iscsiadm
-m
> > > session -r /sys/block/xxx", due to limitation of iscsi info exported
by
> > > kernel.
> > >
> > > Once the machine is plugged in this sort of hardware iscsi card, kdump
> > > returns as soon as possible.
> >
> > Since we do not know much about iscsi, could you describe the basic infomation
> > about them?
> >
> > 1. how many type of cases we should consider for iscsi?
>
> There are three iscsi initiators we use more frequently.
> 1) software iscsi initiator
> 2) iSCSI HBA
> 3) iBFT
>
> >
> > 2. what is the difference between them, how to diffrentiate them.
>
> 1) software iscsi initiator
> - We can setup the iscsi environemnt by using tgt suit. It is more
> continent to setup the iscsi without the hardware supporting.
>
> 2) iSCSI HBA
> - System has no ability to detect the iscsi session config. The
> usage of exported iSCSI device is the same as local SCSI device.
>
> 3) iBFT
> - The iSCSI Bios Firmware Table (iBFT) is a table that is created in
> memory which is mapped with the iSCSI card firmware. Thus we can get
> the session config according to the command iscsiadm.
> >
> > 3. how to setup them (basic steps)
>
> 1) software iscsi initiator
> - According to the command iscsiadm to setup the available seesion,
> and the session info should be passed manually
>
> 2) iSCSI HBA
> - Do nothing, except for passing "rd.iscsi.firmware=1" to the
> kernel. The iSCSI device will use the config stored in firmware to
> setup the session.
So assume your patch is for addressing 2), if it is a boot disk there should
be rd.iscsi.firmware=1 in /proc/cmdline, but if it is not a boot disk, we need
pass this param to second kernel?
Hi, Dave.
Yes. This patch is to solve the situation 2) non-iBFT iSCSI HBA.
What if there's both 2) and 1) existed?
We can inherit this parameter from 1st kernel. Thus we can do nothing to
bring up the iSCSI device, either boot device or non-boot device.
Thanks
Minfei
>
> 3) iBFT
> - Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to the
kernel to
> setup the session.
12:07 a.m.
On 09/30/15 at 12:01pm, Minfei Huang wrote:
On 09/30/15 at 11:10am, Dave Young wrote:
> On 09/25/15 at 06:03pm, Minfei Huang wrote:
> > On 09/25/15 at 02:39pm, Dave Young wrote:
> > > On 09/24/15 at 01:29pm, Minfei Huang wrote:
> > > > Hardware iscsi can export the iscsi device before starting to load
the
> > > > kernel code, which setups the iscsi card using the config stored in
> > > > hardward iscsi card memory.
> > > >
> > > > kdump need not do anything for this sort of hardware iscsi card, if
this
> > > > card does not have the feature iBFT. IBFT can export the iscsi
> > > > configuration from hardware iscsi card memroy to current running
kernel.
> > > > Thus iscsiadm cann't get the iscsi session info using
"iscsiadm -m
> > > > session -r /sys/block/xxx", due to limitation of iscsi info
exported by
> > > > kernel.
> > > >
> > > > Once the machine is plugged in this sort of hardware iscsi card,
kdump
> > > > returns as soon as possible.
> > >
> > > Since we do not know much about iscsi, could you describe the basic
infomation
> > > about them?
> > >
> > > 1. how many type of cases we should consider for iscsi?
> >
> > There are three iscsi initiators we use more frequently.
> > 1) software iscsi initiator
> > 2) iSCSI HBA
> > 3) iBFT
> >
> > >
> > > 2. what is the difference between them, how to diffrentiate them.
> >
> > 1) software iscsi initiator
> > - We can setup the iscsi environemnt by using tgt suit. It is more
> > continent to setup the iscsi without the hardware supporting.
> >
> > 2) iSCSI HBA
> > - System has no ability to detect the iscsi session config. The
> > usage of exported iSCSI device is the same as local SCSI device.
> >
> > 3) iBFT
> > - The iSCSI Bios Firmware Table (iBFT) is a table that is created in
> > memory which is mapped with the iSCSI card firmware. Thus we can get
> > the session config according to the command iscsiadm.
> > >
> > > 3. how to setup them (basic steps)
> >
> > 1) software iscsi initiator
> > - According to the command iscsiadm to setup the available seesion,
> > and the session info should be passed manually
> >
> > 2) iSCSI HBA
> > - Do nothing, except for passing "rd.iscsi.firmware=1" to the
> > kernel. The iSCSI device will use the config stored in firmware to
> > setup the session.
>
> So assume your patch is for addressing 2), if it is a boot disk there should
> be rd.iscsi.firmware=1 in /proc/cmdline, but if it is not a boot disk, we need
> pass this param to second kernel?
Hi, Dave.
Yes. This patch is to solve the situation 2) non-iBFT iSCSI HBA.
>
> What if there's both 2) and 1) existed?
>
We can inherit this parameter from 1st kernel. Thus we can do nothing to
bring up the iSCSI device, either boot device or non-boot device.
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.
Thanks
Minfei
> >
> > 3) iBFT
> > - Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to
the kernel to
> > setup the session.
1:22 a.m.
On 09/30/15 at 01:07pm, Dave Young wrote:
On 09/30/15 at 12:01pm, Minfei Huang wrote:
> On 09/30/15 at 11:10am, Dave Young wrote:
> > On 09/25/15 at 06:03pm, Minfei Huang wrote:
> > > On 09/25/15 at 02:39pm, Dave Young wrote:
> > > > On 09/24/15 at 01:29pm, Minfei Huang wrote:
> > > > > Hardware iscsi can export the iscsi device before starting to
load the
> > > > > kernel code, which setups the iscsi card using the config stored
in
> > > > > hardward iscsi card memory.
> > > > >
> > > > > kdump need not do anything for this sort of hardware iscsi card,
if this
> > > > > card does not have the feature iBFT. IBFT can export the iscsi
> > > > > configuration from hardware iscsi card memroy to current running
kernel.
> > > > > Thus iscsiadm cann't get the iscsi session info using
"iscsiadm -m
> > > > > session -r /sys/block/xxx", due to limitation of iscsi info
exported by
> > > > > kernel.
> > > > >
> > > > > Once the machine is plugged in this sort of hardware iscsi card,
kdump
> > > > > returns as soon as possible.
> > > >
> > > > Since we do not know much about iscsi, could you describe the basic
infomation
> > > > about them?
> > > >
> > > > 1. how many type of cases we should consider for iscsi?
> > >
> > > There are three iscsi initiators we use more frequently.
> > > 1) software iscsi initiator
> > > 2) iSCSI HBA
> > > 3) iBFT
> > >
> > > >
> > > > 2. what is the difference between them, how to diffrentiate them.
> > >
> > > 1) software iscsi initiator
> > > - We can setup the iscsi environemnt by using tgt suit. It is more
> > > continent to setup the iscsi without the hardware supporting.
> > >
> > > 2) iSCSI HBA
> > > - System has no ability to detect the iscsi session config. The
> > > usage of exported iSCSI device is the same as local SCSI device.
> > >
> > > 3) iBFT
> > > - The iSCSI Bios Firmware Table (iBFT) is a table that is created in
> > > memory which is mapped with the iSCSI card firmware. Thus we can get
> > > the session config according to the command iscsiadm.
> > > >
> > > > 3. how to setup them (basic steps)
> > >
> > > 1) software iscsi initiator
> > > - According to the command iscsiadm to setup the available seesion,
> > > and the session info should be passed manually
> > >
> > > 2) iSCSI HBA
> > > - Do nothing, except for passing "rd.iscsi.firmware=1" to
the
> > > kernel. The iSCSI device will use the config stored in firmware to
> > > setup the session.
> >
> > So assume your patch is for addressing 2), if it is a boot disk there should
> > be rd.iscsi.firmware=1 in /proc/cmdline, but if it is not a boot disk, we need
> > pass this param to second kernel?
>
> Hi, Dave.
>
> Yes. This patch is to solve the situation 2) non-iBFT iSCSI HBA.
>
> >
> > What if there's both 2) and 1) existed?
> >
>
> We can inherit this parameter from 1st kernel. Thus we can do nothing to
> bring up the iSCSI device, either boot device or non-boot device.
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.
Thanks
Minfei
> > >
> > > 3) iBFT
> > > - Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1"
to the kernel to
> > > setup the session.
1:37 a.m.
> 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
1:44 a.m.
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
1:47 a.m.
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]
----- Original Message -----
From: "Minfei Huang" <mhuang(a)redhat.com>
To: "Dave Young" <dyoung(a)redhat.com>
Cc: kexec(a)lists.fedoraproject.org, bhe(a)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(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/kexec
2:07 a.m.
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(a)redhat.com>
To: "Dave Young" <dyoung(a)redhat.com>
Cc: kexec(a)lists.fedoraproject.org, bhe(a)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(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/kexec
10:21 a.m.
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]
----- Original Message -----
From: "Minfei Huang" <mhuang(a)redhat.com>
To: "Dave Young" <dyoung(a)redhat.com>
Cc: kexec(a)lists.fedoraproject.org, bhe(a)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.
Hi.
We needn't to do anything to bring up the iSCSI HBA device, including parameter rd.*.
Following is an example to show the detail. (sdd is non-boot device, and is
exported by non-iBFT hardware iSCSI card)
kdump: dump target is /dev/sdd
kdump: saving to /kdumproot/mnt//var/crash/127.0.0.1-2015-09-30-17:15:12/
[ 106.146401] EXT4-fs (sdd): re-mounted. Opts: data=ordered
kdump: saving vmcore-dmesg.txt
kdump: saving vmcore-dmesg.txt complete
kdump: saving vmcore
Copying data : [100.0 %] -
kdump: saving vmcore complete
BOOT_IMAGE=/vmlinuz-3.10.0-320.el7.x86_64 root=/dev/mapper/rhel_storageqe--8100-root
ro modprobe.blacklist=qla3xxx rd.lvm.lv=rhel_storageqe-8100/root
rd.lvm.lv=rhel_storageqe-8100/swap console=ttyS1,115200 LANG=en_US.UTF-8 irqpoll
nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2
panic=10 rootflags=nofail acpi_no_memhotplug transparent_hugepage=never
disable_cpu_apicid=0 elfcorehdr=852380K
Thanks
Minfei
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.
3124
days inactive
3130
days old
11 comments
2 participants
participants (2)
-
Dave Young -
Minfei Huang