[PATCH 1/2] kdump/fadump: fix network interface name when switching from fadump to kdump
When a remote dump target is specified, kdump dracut module prefixes 'kdump-' to network interface name (ifname) as kernel assigned names are not persistent. In fadump mode, kdump dracut module is added to the default initrd, which adds the 'kdump-' prefix to the ifname of the prodcution kernel itself. If fadump mode is disabled after this, kdump dracut module picks the ifname that is already prefixed with 'kdump-' in the production kernel and adds another 'kdump-' to it, making the ifname something like kdump-kdump-eth0 for kdump kernel. Eventually, kdump kernel fails with below traces:
dracut-initqueue[246]: RTNETLINK answers: Network is unreachable dracut-initqueue[246]: arping: Device kdump-kdump-eth0 not available.
The ip command shows the below:
kdump:/# ip addr show kdump-kdump-eth0 2: kdump-kdump-eth: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 \ qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 22:82:87:7b:98:02 brd ff:ff:ff:ff:ff:ff inet6 2002:903:15f:550:2082:87ff:fe7b:9802/64 scope global \ mngtmpaddr dynamic valid_lft 2591890sec preferred_lft 604690sec inet6 fe80::2082:87ff:fe7b:9802/64 scope link valid_lft forever preferred_lft forever kdump:/#
The trailing 0 from kdump-kdump-eth0 is missing in the ifname, probably truncated while setting.
This patch fixes this by avoiding addition of the prefix 'kdump-' when such prefix is already present in the ifname.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com --- dracut-module-setup.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 68e0ff8..490501a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -161,7 +161,8 @@ kdump_get_perm_addr() { kdump_setup_ifname() { local _ifname
- if [[ $1 =~ eth* ]]; then + # If ifname has 'kdump-' prefix, don't add it again + if [[ $1 =~ eth* ]] && [[ ! $1 =~ ^kdump-* ]]; then _ifname="kdump-$1" else _ifname="$1"
When fadump mode is enabled, the default initrd is rebuilt with kdump dracut module. As the default initrd is altered, the original default initrd is backed up. But we are not restoring it when fadump mode is disabled. This patch tries to restore the backed up default initrd on disabling fadump mode.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com --- kdumpctl | 42 ++++++++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/kdumpctl b/kdumpctl index 8d0ab81..8d883de 100755 --- a/kdumpctl +++ b/kdumpctl @@ -154,9 +154,6 @@ rebuild_fadump_initrd() { local target_initrd_tmp
- # backup fadump initrd for reference before replacing it - backup_initrd - # this file tells the initrd is fadump enabled touch /tmp/fadump.initramfs target_initrd_tmp="$TARGET_INITRD.tmp" @@ -190,8 +187,17 @@ rebuild_kdump_initrd() rebuild_initrd() { if [ $DEFAULT_DUMP_MODE == "fadump" ]; then + # backup initrd for reference before replacing it + # with fadump aware initrd + backup_restore_default_initrd "backup" + rebuild_fadump_initrd else + # check if a backup of default initrd exists. If yes, + # it signifies a switch from fadump mode. So, restore + # the backed up default initrd. + backup_restore_default_initrd "restore" + rebuild_kdump_initrd fi
@@ -220,15 +226,31 @@ check_executable() done }
-backup_initrd() +backup_restore_default_initrd() { - local target_initrd_bak + local default_initrd + local default_initrd_bak + local action=$1 + + default_initrd="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}.img" + default_initrd_bak="${KDUMP_BOOTDIR}/.initramfs-${kdump_kver}.img.default"
- # Check if backup initrd is already present. - target_initrd_bak="$TARGET_INITRD.bak" - if [ ! -e $target_initrd_bak ];then - echo "Backing up $TARGET_INITRD" - cp $TARGET_INITRD $target_initrd_bak + if [[ $action != "restore" ]]; then + if [ ! -e $default_initrd_bak ]; then + echo "Backing up $default_initrd" + cp $default_initrd $default_initrd_bak + fi + else + # If a backup initrd exists, we must be switching back from + # fadump to kdump. Restore the original default initrd. + if [ -f $default_initrd_bak ];then + mv $default_initrd_bak $default_initrd + if [[ $? -eq 0 ]]; then + echo -n "Default initrd is restored as fadump mode " + echo "is disabled" + sync + fi + fi fi }
Hi, Hari
The fix looks good, but I have a question about the kernel version maybe we did not notice it when we review previous fadump patches.
On 09/07/16 at 06:10pm, Hari Bathini wrote:
When fadump mode is enabled, the default initrd is rebuilt with kdump dracut module. As the default initrd is altered, the original default initrd is backed up. But we are not restoring it when fadump mode is disabled. This patch tries to restore the backed up default initrd on disabling fadump mode.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com
kdumpctl | 42 ++++++++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/kdumpctl b/kdumpctl index 8d0ab81..8d883de 100755 --- a/kdumpctl +++ b/kdumpctl @@ -154,9 +154,6 @@ rebuild_fadump_initrd() { local target_initrd_tmp
- # backup fadump initrd for reference before replacing it
- backup_initrd
- # this file tells the initrd is fadump enabled touch /tmp/fadump.initramfs target_initrd_tmp="$TARGET_INITRD.tmp"
@@ -190,8 +187,17 @@ rebuild_kdump_initrd() rebuild_initrd() { if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
# backup initrd for reference before replacing it# with fadump aware initrdbackup_restore_default_initrd "backup"- rebuild_fadump_initrd else
# check if a backup of default initrd exists. If yes,# it signifies a switch from fadump mode. So, restore# the backed up default initrd.backup_restore_default_initrd "restore"- rebuild_kdump_initrd fi
@@ -220,15 +226,31 @@ check_executable() done }
-backup_initrd() +backup_restore_default_initrd() {
- local target_initrd_bak
- local default_initrd
- local default_initrd_bak
- local action=$1
- default_initrd="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}.img"
- default_initrd_bak="${KDUMP_BOOTDIR}/.initramfs-${kdump_kver}.img.default"
Hari,
$kdump_kver is the kdump kernel version, it may be different with the default kernel version. Acording to my understanding the default initrd should use the normal boot kernel version like `uname -r`
- # Check if backup initrd is already present.
- target_initrd_bak="$TARGET_INITRD.bak"
- if [ ! -e $target_initrd_bak ];then
echo "Backing up $TARGET_INITRD"cp $TARGET_INITRD $target_initrd_bak
- if [[ $action != "restore" ]]; then
if [ ! -e $default_initrd_bak ]; thenecho "Backing up $default_initrd"cp $default_initrd $default_initrd_bakfi- else
# If a backup initrd exists, we must be switching back from# fadump to kdump. Restore the original default initrd.if [ -f $default_initrd_bak ];thenmv $default_initrd_bak $default_initrdif [[ $? -eq 0 ]]; thenecho -n "Default initrd is restored as fadump mode "echo "is disabled"syncfifi}
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
On Monday 12 September 2016 07:42 AM, Dave Young wrote:
Hi, Hari
The fix looks good, but I have a question about the kernel version maybe we did not notice it when we review previous fadump patches.
Hi Dave,
Thanks for the review..
On 09/07/16 at 06:10pm, Hari Bathini wrote:
When fadump mode is enabled, the default initrd is rebuilt with kdump dracut module. As the default initrd is altered, the original default initrd is backed up. But we are not restoring it when fadump mode is disabled. This patch tries to restore the backed up default initrd on disabling fadump mode.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com
kdumpctl | 42 ++++++++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/kdumpctl b/kdumpctl index 8d0ab81..8d883de 100755 --- a/kdumpctl +++ b/kdumpctl @@ -154,9 +154,6 @@ rebuild_fadump_initrd() { local target_initrd_tmp
- # backup fadump initrd for reference before replacing it
- backup_initrd
- # this file tells the initrd is fadump enabled touch /tmp/fadump.initramfs target_initrd_tmp="$TARGET_INITRD.tmp"
@@ -190,8 +187,17 @@ rebuild_kdump_initrd() rebuild_initrd() { if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
# backup initrd for reference before replacing it# with fadump aware initrdbackup_restore_default_initrd "backup"- rebuild_fadump_initrd else
# check if a backup of default initrd exists. If yes,# it signifies a switch from fadump mode. So, restore# the backed up default initrd.backup_restore_default_initrd "restore"- rebuild_kdump_initrd fi
@@ -220,15 +226,31 @@ check_executable() done }
-backup_initrd() +backup_restore_default_initrd() {
- local target_initrd_bak
- local default_initrd
- local default_initrd_bak
- local action=$1
- default_initrd="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}.img"
- default_initrd_bak="${KDUMP_BOOTDIR}/.initramfs-${kdump_kver}.img.default"
Hari,
$kdump_kver is the kdump kernel version, it may be different with the default kernel version. Acording to my understanding the default initrd should use the normal boot kernel version like `uname -r`
Ah! true. That is the right thing to do...
- Hari
- # Check if backup initrd is already present.
- target_initrd_bak="$TARGET_INITRD.bak"
- if [ ! -e $target_initrd_bak ];then
echo "Backing up $TARGET_INITRD"cp $TARGET_INITRD $target_initrd_bak
- if [[ $action != "restore" ]]; then
if [ ! -e $default_initrd_bak ]; thenecho "Backing up $default_initrd"cp $default_initrd $default_initrd_bakfi- else
# If a backup initrd exists, we must be switching back from# fadump to kdump. Restore the original default initrd.if [ -f $default_initrd_bak ];thenmv $default_initrd_bak $default_initrdif [[ $? -eq 0 ]]; thenecho -n "Default initrd is restored as fadump mode "echo "is disabled"syncfifi
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
Hi, Hari
Thanks for sending the patches.
The issue will not happen if we restore default initrd in patch 2/2, right? So patch 1/2 is not necessary?
On 09/07/16 at 06:10pm, Hari Bathini wrote:
When a remote dump target is specified, kdump dracut module prefixes 'kdump-' to network interface name (ifname) as kernel assigned names are not persistent. In fadump mode, kdump dracut module is added to the default initrd, which adds the 'kdump-' prefix to the ifname of the prodcution kernel itself. If fadump mode is disabled after this, kdump dracut module picks the ifname that is already prefixed with 'kdump-' in the production kernel and adds another 'kdump-' to it, making the ifname something like kdump-kdump-eth0 for kdump kernel. Eventually, kdump kernel fails with below traces:
dracut-initqueue[246]: RTNETLINK answers: Network is unreachable dracut-initqueue[246]: arping: Device kdump-kdump-eth0 not available.
The ip command shows the below:
kdump:/# ip addr show kdump-kdump-eth0 2: kdump-kdump-eth: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 \ qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 22:82:87:7b:98:02 brd ff:ff:ff:ff:ff:ff inet6 2002:903:15f:550:2082:87ff:fe7b:9802/64 scope global \ mngtmpaddr dynamic valid_lft 2591890sec preferred_lft 604690sec inet6 fe80::2082:87ff:fe7b:9802/64 scope link valid_lft forever preferred_lft forever kdump:/#
The trailing 0 from kdump-kdump-eth0 is missing in the ifname, probably truncated while setting.
This patch fixes this by avoiding addition of the prefix 'kdump-' when such prefix is already present in the ifname.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com
dracut-module-setup.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 68e0ff8..490501a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -161,7 +161,8 @@ kdump_get_perm_addr() { kdump_setup_ifname() { local _ifname
- if [[ $1 =~ eth* ]]; then
- # If ifname has 'kdump-' prefix, don't add it again
- if [[ $1 =~ eth* ]] && [[ ! $1 =~ ^kdump-* ]]; then _ifname="kdump-$1" else _ifname="$1"
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
Hi Dave,
On Monday 12 September 2016 07:35 AM, Dave Young wrote:
Hi, Hari
Thanks for sending the patches.
The issue will not happen if we restore default initrd in patch 2/2, right? So patch 1/2 is not necessary?
Actually, the first reboot after switching over from fadump to kdump still holds the interface name with "kdump-" prefix as we haven't restored the default initrd yet. This patch intents to cover that and also, to restore the original interface name for subsequent reboots..
Thanks Hari
On 09/07/16 at 06:10pm, Hari Bathini wrote:
When a remote dump target is specified, kdump dracut module prefixes 'kdump-' to network interface name (ifname) as kernel assigned names are not persistent. In fadump mode, kdump dracut module is added to the default initrd, which adds the 'kdump-' prefix to the ifname of the prodcution kernel itself. If fadump mode is disabled after this, kdump dracut module picks the ifname that is already prefixed with 'kdump-' in the production kernel and adds another 'kdump-' to it, making the ifname something like kdump-kdump-eth0 for kdump kernel. Eventually, kdump kernel fails with below traces:
dracut-initqueue[246]: RTNETLINK answers: Network is unreachable dracut-initqueue[246]: arping: Device kdump-kdump-eth0 not available.
The ip command shows the below:
kdump:/# ip addr show kdump-kdump-eth0 2: kdump-kdump-eth: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 \ qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 22:82:87:7b:98:02 brd ff:ff:ff:ff:ff:ff inet6 2002:903:15f:550:2082:87ff:fe7b:9802/64 scope global \ mngtmpaddr dynamic valid_lft 2591890sec preferred_lft 604690sec inet6 fe80::2082:87ff:fe7b:9802/64 scope link valid_lft forever preferred_lft forever kdump:/#
The trailing 0 from kdump-kdump-eth0 is missing in the ifname, probably truncated while setting.
This patch fixes this by avoiding addition of the prefix 'kdump-' when such prefix is already present in the ifname.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com
dracut-module-setup.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 68e0ff8..490501a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -161,7 +161,8 @@ kdump_get_perm_addr() { kdump_setup_ifname() { local _ifname
- if [[ $1 =~ eth* ]]; then
- # If ifname has 'kdump-' prefix, don't add it again
- if [[ $1 =~ eth* ]] && [[ ! $1 =~ ^kdump-* ]]; then _ifname="kdump-$1" else _ifname="$1"
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
On Monday 12 September 2016 10:08 PM, Hari Bathini wrote:
Hi Dave,
On Monday 12 September 2016 07:35 AM, Dave Young wrote:
Hi, Hari
Thanks for sending the patches.
The issue will not happen if we restore default initrd in patch 2/2, right? So patch 1/2 is not necessary?
Actually, the first reboot after switching over from fadump to kdump still holds the interface name with "kdump-" prefix as we haven't restored the default initrd yet. This patch intents to cover that and also, to restore the original interface name for subsequent reboots..
Ignore the 2nd use-case as patch 2/2 covers this anyway..
Alternatively, to cover the 1st use-case, we can relay on the GUI script by restoring initrd as and when fadump is disabled in GUI. I feel the below hunk is harmless though..
Thanks Hari
Thanks Hari
On 09/07/16 at 06:10pm, Hari Bathini wrote:
When a remote dump target is specified, kdump dracut module prefixes 'kdump-' to network interface name (ifname) as kernel assigned names are not persistent. In fadump mode, kdump dracut module is added to the default initrd, which adds the 'kdump-' prefix to the ifname of the prodcution kernel itself. If fadump mode is disabled after this, kdump dracut module picks the ifname that is already prefixed with 'kdump-' in the production kernel and adds another 'kdump-' to it, making the ifname something like kdump-kdump-eth0 for kdump kernel. Eventually, kdump kernel fails with below traces:
dracut-initqueue[246]: RTNETLINK answers: Network is unreachable dracut-initqueue[246]: arping: Device kdump-kdump-eth0 not available.
The ip command shows the below:
kdump:/# ip addr show kdump-kdump-eth0 2: kdump-kdump-eth: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 \ qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 22:82:87:7b:98:02 brd ff:ff:ff:ff:ff:ff inet6 2002:903:15f:550:2082:87ff:fe7b:9802/64 scope global \ mngtmpaddr dynamic valid_lft 2591890sec preferred_lft 604690sec inet6 fe80::2082:87ff:fe7b:9802/64 scope link valid_lft forever preferred_lft forever kdump:/#
The trailing 0 from kdump-kdump-eth0 is missing in the ifname, probably truncated while setting.
This patch fixes this by avoiding addition of the prefix 'kdump-' when such prefix is already present in the ifname.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com
dracut-module-setup.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 68e0ff8..490501a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -161,7 +161,8 @@ kdump_get_perm_addr() { kdump_setup_ifname() { local _ifname
- if [[ $1 =~ eth* ]]; then
- # If ifname has 'kdump-' prefix, don't add it again
- if [[ $1 =~ eth* ]] && [[ ! $1 =~ ^kdump-* ]]; then _ifname="kdump-$1" else _ifname="$1"
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
On Monday 12 September 2016 10:18 PM, Hari Bathini wrote:
On Monday 12 September 2016 10:08 PM, Hari Bathini wrote:
Hi Dave,
On Monday 12 September 2016 07:35 AM, Dave Young wrote:
Hi, Hari
Thanks for sending the patches.
The issue will not happen if we restore default initrd in patch 2/2, right? So patch 1/2 is not necessary?
Actually, the first reboot after switching over from fadump to kdump still holds the interface name with "kdump-" prefix as we haven't restored the default initrd yet. This patch intents to cover that and also, to restore the original interface name for subsequent reboots..
Hi Dave,
Another possible case is rebuild may not happen on switching from fadump to kdump, if config files are not changed. I could restore as part of start_dump() but that doesn't sound right to me. Posted v2 with this patch intact. Please review..
Thanks Hari
Ignore the 2nd use-case as patch 2/2 covers this anyway..
Alternatively, to cover the 1st use-case, we can relay on the GUI script by restoring initrd as and when fadump is disabled in GUI. I feel the below hunk is harmless though..
Thanks Hari
Thanks Hari
On 09/07/16 at 06:10pm, Hari Bathini wrote:
When a remote dump target is specified, kdump dracut module prefixes 'kdump-' to network interface name (ifname) as kernel assigned names are not persistent. In fadump mode, kdump dracut module is added to the default initrd, which adds the 'kdump-' prefix to the ifname of the prodcution kernel itself. If fadump mode is disabled after this, kdump dracut module picks the ifname that is already prefixed with 'kdump-' in the production kernel and adds another 'kdump-' to it, making the ifname something like kdump-kdump-eth0 for kdump kernel. Eventually, kdump kernel fails with below traces:
dracut-initqueue[246]: RTNETLINK answers: Network is unreachable dracut-initqueue[246]: arping: Device kdump-kdump-eth0 not available.
The ip command shows the below:
kdump:/# ip addr show kdump-kdump-eth0 2: kdump-kdump-eth: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 \ qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 22:82:87:7b:98:02 brd ff:ff:ff:ff:ff:ff inet6 2002:903:15f:550:2082:87ff:fe7b:9802/64 scope global \ mngtmpaddr dynamic valid_lft 2591890sec preferred_lft 604690sec inet6 fe80::2082:87ff:fe7b:9802/64 scope link valid_lft forever preferred_lft forever kdump:/#
The trailing 0 from kdump-kdump-eth0 is missing in the ifname, probably truncated while setting.
This patch fixes this by avoiding addition of the prefix 'kdump-' when such prefix is already present in the ifname.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com
dracut-module-setup.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 68e0ff8..490501a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -161,7 +161,8 @@ kdump_get_perm_addr() { kdump_setup_ifname() { local _ifname
- if [[ $1 =~ eth* ]]; then
- # If ifname has 'kdump-' prefix, don't add it again
- if [[ $1 =~ eth* ]] && [[ ! $1 =~ ^kdump-* ]]; then _ifname="kdump-$1" else _ifname="$1"
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Hi, Hari
On 09/14/16 at 12:57pm, Hari Bathini wrote:
On Monday 12 September 2016 10:18 PM, Hari Bathini wrote:
On Monday 12 September 2016 10:08 PM, Hari Bathini wrote:
Hi Dave,
On Monday 12 September 2016 07:35 AM, Dave Young wrote:
Hi, Hari
Thanks for sending the patches.
The issue will not happen if we restore default initrd in patch 2/2, right? So patch 1/2 is not necessary?
Actually, the first reboot after switching over from fadump to kdump still holds the interface name with "kdump-" prefix as we haven't restored the default initrd yet. This patch intents to cover that and also, to restore the original interface name for subsequent reboots..
Hi Dave,
Another possible case is rebuild may not happen on switching from fadump to kdump, if config files are not changed. I could restore as part of start_dump() but that doesn't sound right to me. Posted v2 with this patch intact. Please review..
I got the problem, do you have any method to know the fadump mode changing? Ideally we should check and rebuild when the mode changes.
Thanks Dave
Hi Dave,
On Wednesday 14 September 2016 01:22 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 12:57pm, Hari Bathini wrote:
On Monday 12 September 2016 10:18 PM, Hari Bathini wrote:
On Monday 12 September 2016 10:08 PM, Hari Bathini wrote:
Hi Dave,
On Monday 12 September 2016 07:35 AM, Dave Young wrote:
Hi, Hari
Thanks for sending the patches.
The issue will not happen if we restore default initrd in patch 2/2, right? So patch 1/2 is not necessary?
Actually, the first reboot after switching over from fadump to kdump still holds the interface name with "kdump-" prefix as we haven't restored the default initrd yet. This patch intents to cover that and also, to restore the original interface name for subsequent reboots..
Hi Dave,
Another possible case is rebuild may not happen on switching from fadump to kdump, if config files are not changed. I could restore as part of start_dump() but that doesn't sound right to me. Posted v2 with this patch intact. Please review..
I got the problem, do you have any method to know the fadump mode changing? Ideally we should check and rebuild when the mode changes.
If /sys/kernel/fadump_registered node is not available and default initrd is built with kdump module, it signifies that we switched from fadump to kdump. That is after a reboot though where we already have the ifname with "kdump-" prefix..
Thanks Hari
Thanks Dave
On 09/14/16 at 02:02pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 01:22 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 12:57pm, Hari Bathini wrote:
On Monday 12 September 2016 10:18 PM, Hari Bathini wrote:
On Monday 12 September 2016 10:08 PM, Hari Bathini wrote:
Hi Dave,
On Monday 12 September 2016 07:35 AM, Dave Young wrote:
Hi, Hari
Thanks for sending the patches.
The issue will not happen if we restore default initrd in patch 2/2, right? So patch 1/2 is not necessary?
Actually, the first reboot after switching over from fadump to kdump still holds the interface name with "kdump-" prefix as we haven't restored the default initrd yet. This patch intents to cover that and also, to restore the original interface name for subsequent reboots..
Hi Dave,
Another possible case is rebuild may not happen on switching from fadump to kdump, if config files are not changed. I could restore as part of start_dump() but that doesn't sound right to me. Posted v2 with this patch intact. Please review..
I got the problem, do you have any method to know the fadump mode changing? Ideally we should check and rebuild when the mode changes.
If /sys/kernel/fadump_registered node is not available and default initrd is built with kdump module, it signifies that we switched from fadump to kdump. That is after a reboot though where we already have the ifname with "kdump-" prefix..
Hari, if so how about fix it to let check_rebuild to detect the mode change so that we can use patch 2 to restore original initramfs?
I worry about avoiding multi kdump- prefix cause issues though in real life usually maybe nobody will name a nic as kdump-eth*
Thanks Hari
Thanks Dave
Thanks Dave
Hi Dave,
On Wednesday 14 September 2016 02:13 PM, Dave Young wrote:
On 09/14/16 at 02:02pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 01:22 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 12:57pm, Hari Bathini wrote:
On Monday 12 September 2016 10:18 PM, Hari Bathini wrote:
On Monday 12 September 2016 10:08 PM, Hari Bathini wrote:
Hi Dave,
On Monday 12 September 2016 07:35 AM, Dave Young wrote: > Hi, Hari > > Thanks for sending the patches. > > The issue will not happen if we restore default initrd in patch 2/2, > right? So patch 1/2 is not necessary? Actually, the first reboot after switching over from fadump to kdump still holds the interface name with "kdump-" prefix as we haven't restored the default initrd yet. This patch intents to cover that and also, to restore the original interface name for subsequent reboots..
Hi Dave,
Another possible case is rebuild may not happen on switching from fadump to kdump, if config files are not changed. I could restore as part of start_dump() but that doesn't sound right to me. Posted v2 with this patch intact. Please review..
I got the problem, do you have any method to know the fadump mode changing? Ideally we should check and rebuild when the mode changes.
If /sys/kernel/fadump_registered node is not available and default initrd is built with kdump module, it signifies that we switched from fadump to kdump. That is after a reboot though where we already have the ifname with "kdump-" prefix..
Hari, if so how about fix it to let check_rebuild to detect the mode change so that we can use patch 2 to restore original initramfs?
Just mentioned the same on a previous mail..
I worry about avoiding multi kdump- prefix cause issues though in real life usually maybe nobody will name a nic as kdump-eth*
The hunk in this patch adds kdump- prefix only if the interface name doesn't have it already. If it already has such prefix, we don't have to worry about the name as it is not default name.. So, I think it serves the purpose you are mentioning?
Thanks Hari
Thanks Hari
Thanks Dave
Thanks Dave
Hi, Hari
On 09/14/16 at 02:29pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 02:13 PM, Dave Young wrote:
On 09/14/16 at 02:02pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 01:22 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 12:57pm, Hari Bathini wrote:
On Monday 12 September 2016 10:18 PM, Hari Bathini wrote:
On Monday 12 September 2016 10:08 PM, Hari Bathini wrote: > Hi Dave, > > > On Monday 12 September 2016 07:35 AM, Dave Young wrote: > > Hi, Hari > > > > Thanks for sending the patches. > > > > The issue will not happen if we restore default initrd in patch 2/2, > > right? So patch 1/2 is not necessary? > Actually, the first reboot after switching over from fadump to kdump > still holds the interface name with "kdump-" prefix as we haven't > restored > the default initrd yet. This patch intents to cover that and also, > to restore > the original interface name for subsequent reboots.. >
Hi Dave,
Another possible case is rebuild may not happen on switching from fadump to kdump, if config files are not changed. I could restore as part of start_dump() but that doesn't sound right to me. Posted v2 with this patch intact. Please review..
I got the problem, do you have any method to know the fadump mode changing? Ideally we should check and rebuild when the mode changes.
If /sys/kernel/fadump_registered node is not available and default initrd is built with kdump module, it signifies that we switched from fadump to kdump. That is after a reboot though where we already have the ifname with "kdump-" prefix..
Hari, if so how about fix it to let check_rebuild to detect the mode change so that we can use patch 2 to restore original initramfs?
Just mentioned the same on a previous mail..
Sorry, I may not understand your points, you are thinking that rebuild sounds bad without kdump.conf changes? Actually we have added more logic to rebuild checking not limited to the config file only now.
I worry about avoiding multi kdump- prefix cause issues though in real life usually maybe nobody will name a nic as kdump-eth*
The hunk in this patch adds kdump- prefix only if the interface name doesn't have it already. If it already has such prefix, we don't have to worry about the name as it is not default name.. So, I think it serves the purpose you are mentioning?
I see it, but one can rename it to kdump-eth0 in udev, it is a valid name, no? I know it is not a usual case, but I still feel check_rebuild sounds better approach.
Thanks Hari
Thanks Hari
Thanks Dave
Thanks Dave
Thanks Dave
Hi Dave,
On Wednesday 14 September 2016 02:46 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 02:29pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 02:13 PM, Dave Young wrote:
On 09/14/16 at 02:02pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 01:22 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 12:57pm, Hari Bathini wrote:
On Monday 12 September 2016 10:18 PM, Hari Bathini wrote: > On Monday 12 September 2016 10:08 PM, Hari Bathini wrote: >> Hi Dave, >> >> >> On Monday 12 September 2016 07:35 AM, Dave Young wrote: >>> Hi, Hari >>> >>> Thanks for sending the patches. >>> >>> The issue will not happen if we restore default initrd in patch 2/2, >>> right? So patch 1/2 is not necessary? >> Actually, the first reboot after switching over from fadump to kdump >> still holds the interface name with "kdump-" prefix as we haven't >> restored >> the default initrd yet. This patch intents to cover that and also, >> to restore >> the original interface name for subsequent reboots.. >> Hi Dave,
Another possible case is rebuild may not happen on switching from fadump to kdump, if config files are not changed. I could restore as part of start_dump() but that doesn't sound right to me. Posted v2 with this patch intact. Please review..
I got the problem, do you have any method to know the fadump mode changing? Ideally we should check and rebuild when the mode changes.
If /sys/kernel/fadump_registered node is not available and default initrd is built with kdump module, it signifies that we switched from fadump to kdump. That is after a reboot though where we already have the ifname with "kdump-" prefix..
Hari, if so how about fix it to let check_rebuild to detect the mode change so that we can use patch 2 to restore original initramfs?
Just mentioned the same on a previous mail..
Sorry, I may not understand your points, you are thinking that rebuild sounds bad without kdump.conf changes? Actually we have added more logic to rebuild checking not limited to the config file only now.
I think restoring default initrd by checking if we have switched from fadump to kdump is the right thing to do. I suggested pseudo code for the same in a another mail. Let me paste it over here:
is_mode_switched() { initrd_fadump_capable=`lsinitrd -m $DEFAULT_INITRD | grep ^kdumpbase$ | wc -l` if [ !is_fadump_capable ] && [ initrd_fadump_capable ] return 1
return 0 }
check_rebuid() { ... is_mode_switched if [ $? -ne 0 ] rebuild_initrd ... } --
I will add the above code in patch 2/2 in the next version.. I think we are on the same page with this.
I worry about avoiding multi kdump- prefix cause issues though in real life usually maybe nobody will name a nic as kdump-eth*
The hunk in this patch adds kdump- prefix only if the interface name doesn't have it already. If it already has such prefix, we don't have to worry about the name as it is not default name.. So, I think it serves the purpose you are mentioning?
I see it, but one can rename it to kdump-eth0 in udev, it is a valid name, no?
True. But do we really need to change ifname to kdump-kdump-eth0 when we already have an ifname that is not kernel assigned and is persistent?
I know it is not a usual case, but I still feel check_rebuild sounds better approach.
Yes. It is better but it still doesn't fix the issue completely using kdumpctl script alone. Let me explain..
Switch from fadump to kdump means booting a kernel without "fadump=on" parameter. kdumpctl may detect this switch and restore default initrd but we still have the ifname with "kdump-" prefix coming from the old initrd we just booted. So, without patch 1/2, kdump will get an ifname of kdump-kdump-eth0 unless we reboot again with the restored initrd! I am trying to avoid another reboot with patch 1/2 and since it is safe to assume that an ifname with one "kdump-" prefix is not a kernel assigned name and is persistent, I think the patch doesn't break the current functionality..
Alternatively, assuming a user only switches from fadump to kdump with system-config-kdump, we can add backup/restore logic in system-config-kdump package on select/deselect of "firmware-assisted dump" option in GUI. This sounds limited though.
Thanks Hari
Hi, Hari
Sorry for late reply, I was busy on some blocker issues.
On 09/14/16 at 03:41pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 02:46 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 02:29pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 02:13 PM, Dave Young wrote:
On 09/14/16 at 02:02pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 01:22 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 12:57pm, Hari Bathini wrote: > On Monday 12 September 2016 10:18 PM, Hari Bathini wrote: > > On Monday 12 September 2016 10:08 PM, Hari Bathini wrote: > > > Hi Dave, > > > > > > > > > On Monday 12 September 2016 07:35 AM, Dave Young wrote: > > > > Hi, Hari > > > > > > > > Thanks for sending the patches. > > > > > > > > The issue will not happen if we restore default initrd in patch 2/2, > > > > right? So patch 1/2 is not necessary? > > > Actually, the first reboot after switching over from fadump to kdump > > > still holds the interface name with "kdump-" prefix as we haven't > > > restored > > > the default initrd yet. This patch intents to cover that and also, > > > to restore > > > the original interface name for subsequent reboots.. > > > > Hi Dave, > > Another possible case is rebuild may not happen on switching from fadump to > kdump, > if config files are not changed. I could restore as part of start_dump() but > that doesn't > sound right to me. Posted v2 with this patch intact. Please review.. I got the problem, do you have any method to know the fadump mode changing? Ideally we should check and rebuild when the mode changes.
If /sys/kernel/fadump_registered node is not available and default initrd is built with kdump module, it signifies that we switched from fadump to kdump. That is after a reboot though where we already have the ifname with "kdump-" prefix..
Hari, if so how about fix it to let check_rebuild to detect the mode change so that we can use patch 2 to restore original initramfs?
Just mentioned the same on a previous mail..
Sorry, I may not understand your points, you are thinking that rebuild sounds bad without kdump.conf changes? Actually we have added more logic to rebuild checking not limited to the config file only now.
I think restoring default initrd by checking if we have switched from fadump to kdump is the right thing to do. I suggested pseudo code for the same in a another mail. Let me paste it over here:
is_mode_switched() { initrd_fadump_capable=`lsinitrd -m $DEFAULT_INITRD | grep ^kdumpbase$ | wc -l` if [ !is_fadump_capable ] && [ initrd_fadump_capable ] return 1
return 0}
check_rebuid() { ... is_mode_switched if [ $? -ne 0 ] rebuild_initrd ... } --
Sounds good, just add a elif case in the if [ $image_time -eq 0 ] ... fi
I will add the above code in patch 2/2 in the next version.. I think we are on the same page with this.
Yes, we are :)
I worry about avoiding multi kdump- prefix cause issues though in real life usually maybe nobody will name a nic as kdump-eth*
The hunk in this patch adds kdump- prefix only if the interface name doesn't have it already. If it already has such prefix, we don't have to worry about the name as it is not default name.. So, I think it serves the purpose you are mentioning?
I see it, but one can rename it to kdump-eth0 in udev, it is a valid name, no?
True. But do we really need to change ifname to kdump-kdump-eth0 when we already have an ifname that is not kernel assigned and is persistent?
Hmm, you may be right..
I know it is not a usual case, but I still feel check_rebuild sounds better approach.
Yes. It is better but it still doesn't fix the issue completely using kdumpctl script alone. Let me explain..
Switch from fadump to kdump means booting a kernel without "fadump=on" parameter. kdumpctl may detect this switch and restore default initrd but we still have the ifname with "kdump-" prefix coming from the old initrd we just booted. So, without patch 1/2, kdump will get an ifname of kdump-kdump-eth0 unless we reboot again with the restored initrd! I am trying to avoid another reboot with patch 1/2 and since it is safe to assume that an ifname with one "kdump-" prefix is not a kernel assigned name and is persistent, I think the patch doesn't break the current functionality..
I got your case now, the root problem is we depend on kernel param. I think the patch 1/2 is reasonalbe now. But add a code comment will be better.
Alternatively, assuming a user only switches from fadump to kdump with system-config-kdump, we can add backup/restore logic in system-config-kdump package on select/deselect of "firmware-assisted dump" option in GUI. This sounds limited though.
Thanks Hari _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
Hi Dave,
Thanks for reviewing this. Planning to post the next version of the patches
by early next week..
- Hari
On Friday 30 September 2016 02:12 PM, Dave Young wrote:
Hi, Hari
Sorry for late reply, I was busy on some blocker issues.
On 09/14/16 at 03:41pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 02:46 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 02:29pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 02:13 PM, Dave Young wrote:
On 09/14/16 at 02:02pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 01:22 PM, Dave Young wrote: > Hi, Hari > > On 09/14/16 at 12:57pm, Hari Bathini wrote: >> On Monday 12 September 2016 10:18 PM, Hari Bathini wrote: >>> On Monday 12 September 2016 10:08 PM, Hari Bathini wrote: >>>> Hi Dave, >>>> >>>> >>>> On Monday 12 September 2016 07:35 AM, Dave Young wrote: >>>>> Hi, Hari >>>>> >>>>> Thanks for sending the patches. >>>>> >>>>> The issue will not happen if we restore default initrd in patch 2/2, >>>>> right? So patch 1/2 is not necessary? >>>> Actually, the first reboot after switching over from fadump to kdump >>>> still holds the interface name with "kdump-" prefix as we haven't >>>> restored >>>> the default initrd yet. This patch intents to cover that and also, >>>> to restore >>>> the original interface name for subsequent reboots.. >>>> >> Hi Dave, >> >> Another possible case is rebuild may not happen on switching from fadump to >> kdump, >> if config files are not changed. I could restore as part of start_dump() but >> that doesn't >> sound right to me. Posted v2 with this patch intact. Please review.. > I got the problem, do you have any method to know the fadump mode > changing? Ideally we should check and rebuild when the mode changes. If /sys/kernel/fadump_registered node is not available and default initrd is built with kdump module, it signifies that we switched from fadump to kdump. That is after a reboot though where we already have the ifname with "kdump-" prefix..
Hari, if so how about fix it to let check_rebuild to detect the mode change so that we can use patch 2 to restore original initramfs?
Just mentioned the same on a previous mail..
Sorry, I may not understand your points, you are thinking that rebuild sounds bad without kdump.conf changes? Actually we have added more logic to rebuild checking not limited to the config file only now.
I think restoring default initrd by checking if we have switched from fadump to kdump is the right thing to do. I suggested pseudo code for the same in a another mail. Let me paste it over here:
is_mode_switched() { initrd_fadump_capable=`lsinitrd -m $DEFAULT_INITRD | grep ^kdumpbase$ | wc -l` if [ !is_fadump_capable ] && [ initrd_fadump_capable ] return 1
return 0}
check_rebuid() { ... is_mode_switched if [ $? -ne 0 ] rebuild_initrd ... } --
Sounds good, just add a elif case in the if [ $image_time -eq 0 ] ... fi
I will add the above code in patch 2/2 in the next version.. I think we are on the same page with this.
Yes, we are :)
I worry about avoiding multi kdump- prefix cause issues though in real life usually maybe nobody will name a nic as kdump-eth*
The hunk in this patch adds kdump- prefix only if the interface name doesn't have it already. If it already has such prefix, we don't have to worry about the name as it is not default name.. So, I think it serves the purpose you are mentioning?
I see it, but one can rename it to kdump-eth0 in udev, it is a valid name, no?
True. But do we really need to change ifname to kdump-kdump-eth0 when we already have an ifname that is not kernel assigned and is persistent?
Hmm, you may be right..
I know it is not a usual case, but I still feel check_rebuild sounds better approach.
Yes. It is better but it still doesn't fix the issue completely using kdumpctl script alone. Let me explain..
Switch from fadump to kdump means booting a kernel without "fadump=on" parameter. kdumpctl may detect this switch and restore default initrd but we still have the ifname with "kdump-" prefix coming from the old initrd we just booted. So, without patch 1/2, kdump will get an ifname of kdump-kdump-eth0 unless we reboot again with the restored initrd! I am trying to avoid another reboot with patch 1/2 and since it is safe to assume that an ifname with one "kdump-" prefix is not a kernel assigned name and is persistent, I think the patch doesn't break the current functionality..
I got your case now, the root problem is we depend on kernel param. I think the patch 1/2 is reasonalbe now. But add a code comment will be better.
Alternatively, assuming a user only switches from fadump to kdump with system-config-kdump, we can add backup/restore logic in system-config-kdump package on select/deselect of "firmware-assisted dump" option in GUI. This sounds limited though.
Thanks Hari _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
On Wednesday 14 September 2016 02:02 PM, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 01:22 PM, Dave Young wrote:
Hi, Hari
On 09/14/16 at 12:57pm, Hari Bathini wrote:
On Monday 12 September 2016 10:18 PM, Hari Bathini wrote:
On Monday 12 September 2016 10:08 PM, Hari Bathini wrote:
Hi Dave,
On Monday 12 September 2016 07:35 AM, Dave Young wrote:
Hi, Hari
Thanks for sending the patches.
The issue will not happen if we restore default initrd in patch 2/2, right? So patch 1/2 is not necessary?
Actually, the first reboot after switching over from fadump to kdump still holds the interface name with "kdump-" prefix as we haven't restored the default initrd yet. This patch intents to cover that and also, to restore the original interface name for subsequent reboots..
Hi Dave,
Another possible case is rebuild may not happen on switching from fadump to kdump, if config files are not changed. I could restore as part of start_dump() but that doesn't sound right to me. Posted v2 with this patch intact. Please review..
I got the problem, do you have any method to know the fadump mode changing? Ideally we should check and rebuild when the mode changes.
If /sys/kernel/fadump_registered node is not available and default initrd is built with kdump module, it signifies that we switched from fadump to kdump. That is after a reboot though where we already have the ifname with "kdump-" prefix..
Thanks Hari
Hi Dave,
How about something like this..
is_mode_switched() { initrd_fadump_capable=`lsinitrd -m $DEFAULT_INITRD | grep ^kdumpbase$ | wc -l` if [ !is_fadump_capable ] && [ initrd_fadump_capable ] return 1
return 0 }
check_rebuid() { ... is_mode_switched if [ $? -ne 0 ] rebuild_initrd ... }
This hunk added to patch 2/2 should take care of restoring default initrd on switch. But I am worried about the ifname that kdump gets on first reboot. Let me know if you have any reservations with patch 1/2?
Thanks Hari
Thanks Dave
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
-
Dave Young -
Hari Bathini