Resolves: bz2164929
Upstream: Fedora
Conflict: Missing upstream commit
94a7b4("Always drop nofail or nobootwait options")
commit 0843c70672
Author: Kairui Song <kasong@redhat.com>
Date: Wed Jan 13 17:12:18 2021 +0800
Revert "Append both nofail and x-systemd.before to kdump mount target"
That commit is trying to workaround a kernel VFS bug. Now,
the VFS issue should have been fixed in all recent releases, so
remove this workaround.
This reverts commit 539bff4083.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1964822
Upstream: RHEL-only
Currently, vmcore dumping to remote fs gives a warning "eth0: Failed to
rename network interface 3 from 'eth0' to 'kdump-eth0': File exists" on
Azure Hyper-V VM with accelerated networking because it uses a physical
NIC for accelerated networking [1] and the backing physical NIC has the
same MAC address as the virtual NIC. In the kdump initrd, an udev rule
will try renaming NICs with the given MAC address and fails as expected
since there are two NICs having the same MAC address. This udev rule is
created automatically when specifying the dracut cmdline
"ifname=<interface>:<MAC>". For the case of Azure Hyper-V VM with
accelerated networking, only the virtual network interface need to be
renamed. So create an udev rule manually.
[1] https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-overview
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1964822
Upstream: RHEL-only
Currently, vmcore dumping to remote fs gives a warning "eth0: Failed to
rename network interface 3 from 'eth0' to 'kdump-eth0': File exists" on
Azure Hyper-V VM with accelerated networking because it uses a physical
NIC for accelerated networking [1] and the backing physical NIC has the
same MAC as the virtual NIC. There is no need to rename a Hypver-V
interface in this case which also leads the aforementioned warning.
[1] https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-overview
Signed-off-by: Coiby Xu <coxu@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184284
Resolves: rhbz#2184284
Upstream: makedumpfile
commit 58553ad03187f0cf208d6c4a0dc026c6338e5edd
Author: Daisuke Hatayama (Fujitsu) <d.hatayama@fujitsu.com>
Date: Wed Mar 29 12:44:10 2023 +0000
[PATCH] sadump: fix failure of reading memory when 5-level paging is enabled
makedumpfile fails as follows for memory dumps collected by sadump
when 5-level paging is enabled on the corresponding systems:
# makedumpfile -l -d 31 -x ./vmlinux ./dump.sadump dump.sadump-ld31
__vtop4_x86_64: Can't get a valid pgd.
...snip...
__vtop4_x86_64: Can't get a valid pgd.
calc_kaslr_offset: failed to calculate kaslr_offset and phys_base; default to 0
__vtop4_x86_64: Can't get a valid pgd.
readmem: Can't convert a virtual address(ffffffff82fce960) to physical address.
readmem: type_addr: 0, addr:ffffffff82fce960, size:1024
cpu_online_mask_init: Can't read cpu_online_mask memory.
makedumpfile Failed.
This is because 5-level paging support has not been done yet for
sadump; the work of the 5-level paging support was done by the commit
30a3214a7193e94c551c0cebda5918a72a35c589 (PATCH 4/4 arch/x86_64: Add
5-level paging support) but that was focused on the core part only.
Having said that, most of things has already been finished in the
commit. What needs to be newly added for sadump is just how to check
if 5-level paging is enabled for a given memory dump.
For that purpose, let's refer to CR4.LA57, bit 12 of CR4, representing
whether 5-level paging is enabled or not. We can do this because
memory dumps collected by sadump have SMRAM as note information and
they include CR4 together with the other control registers.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: bz2149846
Upstream: Fedora
Conflict: Move to kdump.sysconfig.s390 due to missing
677da8a ("sysconfig: use a simple generator script to maintain")
Author: Philipp Rudo <prudo@redhat.com>
Date: Tue Mar 7 14:45:35 2023 +0100
sysconfig: add zfcp.allow_lun_scan to KDUMP_COMMANDLINE_REMOVE on s390
Probing unnecessary I/O devices wastes memory and in extreme cases can
cause the crashkernel to run OOM. That's why the s390-tools maintain
their own module, 95zdev-kdump [1], that disables auto LUN scanning and
only configures zfcp devices that can be used as dump target. So remove
zfcp.allow_lun_scan from the kernel command line to prevent that we
accidentally overwrite the default set by the module.
[1] https://github.com/ibm-s390-linux/s390-tools/blob/master/zdev/dracut/95zdev-kdump/module-setup.sh
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
