By this point, there is still an unresolved vfs kernel issue that blocks
systemd from mounting the dump target properly from time to time. To
prevent systemd from failing by mounting the dump target, we can add
nofail option to the kdump mount point.
But adding nofail will wipe out default dependency of the mount point,
see commit 94a7b43, so systemd randomize the order of calling kdump.sh
and mounting the dump target and lead to unexpected behavior.
However we can use x-systemd.before to ensure the mount is done
in right order.
In dracut-kdump-capture.service, we have "After=initrd.target",
and look at dracut.bootup.7, systems start processing of fstab by
initrd-fs.target, so set "After=initrd.target" could ensure the mount
is ready before pre-pivot and kdump-capture service.
Now with both nofail and x-systemd.before=initrd.target, systemd
will try to mount the dump target before calling kdump, and even if the
mount failed, kdump.sh will still be called and try to mount again. See
dump_fs function, which will try to mount if the target is not mounted.
Kdump will only fail if both mount attemp fails.
Else if the kdump target mount failed or unstable, systemd will directly
jump to kdump failure action, and kdump fails.
This should improve the robustness in general with no other risk.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
This partially reverts commit 6dee286467.
There are reports that NFSv3 is failing after this commit, and after
more debug, I found NFSv4 may not work properly if
"nfs4_disable_idmapping" is set to 0.
The cause of the failure is that kdump.sh runs after dracut's pre-pivot
and clean up hook, many dracut module will install hooks to kill some
running services, so if the dump target requires a service to be running
but it's killed, mount will fail.
Dracut ensures the configured mount points are ready before pre-pivot.
After pre-pivot, any further mounting operation may not work as expected.
Although there is no report of other type of dump target failure except
NFSv3, it's better to revert this, to avoid other potential risk, and wait
for a proper fix for that systemd/kernel issue.
Else, this may bring more trouble for further development.
But still keep the change in kdump-lib-initramfs.sh for better
robustness.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
This commit remove almost all special workaround for atomic, and treat
all bind mounts in any environment equally.
Use a helper get_bind_mount_directory_from_path to get the bind mount
source path of given path.
is_atomic function now only used to determine the right /boot path
for atomic/silverblue environment.
And remove get_mntpoint_from_path(), it's the only function that never
ignore bind mount, and it have no caller after this clean up.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Lianbo Jiang <lijiang@redhat.com>
For user specified target, the config value is used as the dump target,
and SAVE_PATH (path in kdump.conf) value is used as the dump path within
the dump target, no need to do anything extra with the path value.
Current code logic is not only complicated, it also wrongly generate
an redundantly long path in atomic/silverblue environment.
The right way is only check two things, and do nothing else:
1. The path exists within the target;
2. The target is large enough to hold to contain the vmcore.
Currently checking the target still requires it to be mounted so it will
error out if it's not mounted. Will implement some auto mount as next
step.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Lianbo Jiang <lijiang@redhat.com>
get_save_path provides default value fail back and error check, no need
to repeat it again.
Also remove a redundant echo and grep in get_save_path
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Lianbo Jiang <lijiang@redhat.com>
When building kdump initramfs for a SSH dump target, mkdumprd would
check whether it has the write permission on the SSH Server's
$DUMP_TARGET.
However $DUMP_TARGET is missing in the actual error message when the
user doesn't not have the write permission. For example:
# kdumpctl restart
kexec: unloaded kdump kernel
Stopping kdump: [OK]
Could not create temporary directory on :/home/bhsharma/test. Make
sure user has write permission on destination
mkdumprd: failed to make kdump initrd
Starting kdump: [FAILED]
This patch using $1 value passed to mkdumprd, to print the
$DUMP_TARGET inside mkdir_save_path_ssh() function to
fix the issue.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
In order to check whether the specified makedumpfile parameters are
valid or not when generating initramfs, use the --check-params option,
which was recently added.
With the patch, kdumpctl can point out mistakes in core_collector
option and failed. For example, if there is an practical mistake
that dump_level is -1:
# cat /etc/kdump.conf
core_collector makedumpfile -l --message-level 1 -d -1
# kdumpctl start
Detected change(s) in the following file(s):
/etc/kdump.conf
Rebuilding /boot/initramfs-5.4.19-200.fc31.x86_64kdump.img
Dump_level(-1) is invalid.
makedumpfile parameter check failed.
mkdumprd: failed to make kdump initrd
Starting kdump: [FAILED]
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Acked-by: Kairui Song <kasong@redhat.com>
Previous commit f13eab6 ('mkdumprd: simplify dracut args parsing')
break dracut arguments parsing for some use case, this should fix it
well.
Passed nfs/local/iscsi/ssh dump test, and with extra dracut_argss.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Previously dracut_args is stored as an array in the shell code,
so we can just pass this array as argument to dracut.
But when trying to append new dracut argument, we have to manually
handle the quotes and spaces to ensure the appended argument is
splitted into array elements in the right way.
This is complex and hard to read or maintain. Instead, just store the
dracut_args as a plain string, and let xargs help parse it and call
dracut.
Simply passing $dracut_args or "$dracut_args" will either let dracut
consider the whole string as a single argument, or loss all the
quotes. xargs can handle it well and cover more corner cases.
Eg. one corner case before, if we have:
dracut_args --mount "/dev/sda1 /mnt/test xfs rw"
Kdump will fail, because the function add_dracut_arg() will wrongly
change the arguments into: (Notice the extra space.)
dracut_args --mount " /dev/sda1 /mnt/test xfs rw"
Instead of fixing it just use xargs instead. Tested with above config
and multiple other dracut_args values.
Resolves: bz1700136
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
check_size checks if the specified dump path on the ssh target have
enough space. And if the path doesn't exits, it will fail and exit.
mkdir_save_path_ssh should be called first to check if the path
exists, and create the path if it doesn't exits, so the size check
can always work properly.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
For fadump, this helps to reduce the risk of boot failure, and
may also help speed up the boot by a bit.
For normal kdump, this will delay the dump target mounting, and no
longer depend on systemd to do the mounting job.
And currently there is a failure that caused by some mount handling
bug with kernel and systemd that is failing the system booting:
[FAILED] Failed to mount /kdumproot/home.
See 'systemctl status kdumproot-home.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
[ OK ] Reached target Remote File Systems (Pre).
[ OK ] Reached target Remote File Systems.
Starting udev Coldplug all Devices...
Starting Create Volatile Files and Directories...
Starting Kdump Emergency...
This patch can bypass it. The fix of root cause is still WIP, but this
patch itself is a nice to have optimization so it's reasonable to do so.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
When reading kdump configs, a single parsing should be enough and this
saves a lot of duplicated striping call which speed up the total load
speed.
Speed up about 2 second when building and 0.1 second for reload in my
tests.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Seems some dead codes are left here for historical reason, just remove
them, read the config and strip comments only for once.
This improve the speed by a lot (2.6s -> 0.498s for reading a
simple config in my test case, on HDD) and make the code cleaner.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Currently we use "\b" (word boundary) as the delimiter for ro option,
which is not correct. For mount options like
"defaults,errors=remount-ro" the ro on the tail will also be replaced
and result in an invalid mount option.
So we use a more strict logic on detecting ro mount option. It should
either starts with "," or "^" (begin of line) and ends with "," or "$"
(end of line), and keep the delimiter untouched. This should ensure
only valid mount option got detected and replaced.
This passed following tests:
defaults,ro,noauto,errors=remount-ro,nobootwait,nofail => defaults,rw,errors=remount-ro,
defaults,errors=remount-ro => defaults,errors=remount-ro
defaults,ro,relatime => defaults,rw,relatime
defaults,ro => defaults,rw
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
earlykdump is not suppose to be loaded for a kdump initramfs, and user
may add it into dracut's config file so it will be included by default.
It will also make the image building always fail because earlykdump
actually detect if it's being used for kdump image and raise an error if
so.
In that case, we always force drop this module to avoid such problem.
Signed-off-by: Kairui Song <ryncsn@gmail.com>
Acked-by: Dave Young <dyoung@redhat.com>
Without this patch, when there are two or more spaces after 'path'
configuration phrase with ssh or nfs setting, SAVE_PATH is set to
'/var/crash' in mkdumprd, and in most cases kdump service fails to
start by checking the /var/crash directory regardless of the path
value.
ssh kdump(a)192.168.122.1
path /kdump
^^
This behavior would be too sensitive and different from the other
configurations. With this patch, mkdumprd allows such spaces.
Signed-off-by: Kazuhito Hagio <k-hagio(a)ab.jp.nec.com>
Acked-by: Kairui Song <kasong@redhat.com>
nfs service will append extra mount options to kernel mount options.
Those extra options represent current mounting details, but they may
not suitable for the second kernel. IP address may change, and we only
enable a single network stack (v4/v6), if nfs prefered another
network stack, inheriting the options will force nfs service to use
previous network stack and disable nfs's fallback mechanic and fail.
As nfs service have the capability to negotiate required protocols
and detect proper IP address, just drop those options and let nfs
automatically adapt the possible change in the second kernel.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
If nofail or nobootwait option is used, systemd's local-fs.target won't
wait for the mounting to complete, and kdump might start before the
required mount point is ready and then fail.
The host might use nofail for reasons like the device may get unpluged,
and if the device is not mounted and it is set as kdump target as the same
time then kdump service won't start, we will never enter the capture
kernel. By the time we have entered the capture kernel, the target device
must exist and ready to use, or else kdump would fail anyway. So force
remove nofail and nobootwait option.
Also drop rootflags=nofail option, as we don't depend on rootfs anymore
if the dump target don't required it. So the nofail option is no longer
needed.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This commit basically reverts commit c755499fad,
and make use of new introduced tri-state hostonly mode.
Following dracut commits merged multipath-hostonly into multipath
module, and introduced a tri-state hostonly mode.
commit 35e86ac117acbfd699f371f163cdda9db0ebc047
Author: Kairui Song <kasong@redhat.com>
Date: Thu Jul 5 16:20:04 2018 +0800
Merge 90-multipath-hostonly and 90-multipath
commit a695250ec7db21359689e50733c6581a8d211215
Author: Kairui Song <kasong@redhat.com>
Date: Wed Jul 4 17:21:37 2018 +0800
Introduce tri-state hostonly mode
multipath-hostonly module was introduced only for kdump, because kdump
need a more strict hostonly policy for multipath device to save memory.
Now multipath module will provide the behave we wanted by setting
hostonly mode to strict.
This reverts commit 8e3b6475c9.
After reading the background of bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1510922
It is not a problem actually, sorry for the noise.
Although root set different "PATH" can lead to wrong script, but it is
different with what the bug described "current working dir" and it is
not a problem worth an update
Since we call dracut directly on current working directory "." so it is
possible to trick root to call fake code.
Thus move to use absolute path instead.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Currently in Fedora/RedHat dracut installs its fedora.conf.example
as the default config file, in which sysloglvl is set 5. This leads
to maxloglvl=5 in dracut calls, making unnecessary lsinitrd calls
during initramfs builds by kdump.
This patch makes use of
https://github.com/dracutdevs/dracut/pull/272
and disables lsinitrd logging by giving "-q" option to dracut,
eliminating unnecessary lsinitrd calls in dracut.
1) Before this patch
$ kdumpctl stop; touch /etc/kdump.conf; time kdumpctl start
kexec: unloaded kdump kernel
Stopping kdump: [OK]
Detected change(s) in the following file(s):
/etc/kdump.conf
Rebuilding /boot/initramfs-4.13.0-0.rc1.git4.1.fc27.x86_64kdump.img
kexec: loaded kdump kernel
Starting kdump: [OK]
real 0m26.824s
user 0m9.958s
sys 0m15.106s
2) After this patch
$ kdumpctl stop; touch /etc/kdump.conf; time kdumpctl start
kexec: unloaded kdump kernel
Stopping kdump: [OK]
Detected change(s) in the following file(s):
/etc/kdump.conf
Rebuilding /boot/initramfs-4.13.0-0.rc1.git4.1.fc27.x86_64kdump.img
kexec: loaded kdump kernel
Starting kdump: [OK]
real 0m20.420s
user 0m8.385s
sys 0m10.468s
[dyoung]:
- rewrite patch subject
Signed-off-by: Ziyue Yang <ziyang@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
mkdumprd removes "noauto" mount option, but it also mistakenly removes
"noauto" within a string. For example ext4 has mount option noauto_da_alloc
mkdumprd will replace it with _da_alloc.
Use '\b' to match a whole word of "noauto" to fix it.
Also do same for s/ro/rw for same reason.
Signed-off-by: Dave Young <dyoung@redhat.com>
Reveiwed-by: Xunlei Pang <xlpang@redhat.com>
Dracut has "--hostonly-cmdline" which can generate cmdlines(if any)
regarding the dump target, it's an existing way for us to use to
simplify the code. E.g. We already removed generate_lvm_cmdlines(),
to use "--hostonly-cmdline".
But "--hostonly-cmdline" has other issues(e.g. BZ1451717), it adds
needless devices for kdump like root device.
Now dracut supports "--no-hostonly-default-device" which enables
us to only add the kdump target, which can avoid needless devices
being recognized under kdump. Thus "--hostonly-cmdline" side effects
can be avoided with the help of "--no-hostonly-default-device".
This patch applies dracut's "--hostonly-cmdline" together with
"--no-hostonly-default-device" to achieve above-mentioned purpose.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Currently, we kept "root=X" for the dump_to_rootfs case, this
patch consolidates to use "--mount" for all the kdump mounts.
One advantage of this way is that dracut can correctly mark root
(in case of dump_to_rootfs is specified) as the host device when
"--no-hostonly-default-device" is added in the following patch.
Changed the code style in passing, as shellcheck tool reported:
Use $(..) instead of deprecated `..`
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This reverts commit 54a5bcc4ee.
We are going to add "--no-hostonly-default-device" dracut argument
in the following patch.
With the help of "--no-hostonly-default-device", dracut only
adds the dump target as host devices, which naturally guarantees
only required dracut modules being selected.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This reverts commit 821d1af080.
We are going to add "--no-hostonly-default-device" dracut argument
in the following patch.
With the help of "--no-hostonly-default-device", dracut only
adds the dump target as host devices, which naturally guarantees
only required dracut modules being selected.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This reverts commit fb522e972c.
We are going to add "--no-hostonly-default-device" dracut argument
in the following patch.
With the help of "--no-hostonly-default-device", dracut only
adds the dump target as host devices, which naturally guarantees
only required dracut modules being selected.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
After the following systemd commit, "x-initrd.mount"
option became useless actually, we can safely remove
it now.
commit ce3f6d82b003f365f718f24e48f55b8a0372b924
Author: nmartensen <nis.martensen@web.de>
Date: Fri Jan 15 07:55:25 2016 +0100
fstab-generator: remove bogus condition
The sysroot mount is already taken care of by the
add_sysroot_mount function. With this condition
left in, we can we can get something like this:
initrd-root-fs.target.requires
`-- usr.mount -> /run/systemd/generator/usr.mount
in the main system (i.e., not in the initramfs). In
the initramfs, the previous condition already kicks in.
[snip]
"mount_in_initrd(me)" is true with "x-initrd.mount" option,
the behaviour of systemd fstab generator changed after the
above-mentioned patch, it always generates local mount units
required by local-fs.target regardless of "x-initrd.mount".
After failure, it enters dracut emergency, further triggers
kdump emergency service, thus there is no problem.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
In case of only network target, we can clearly and safely
remove more unnecessary modules to reduce initramfs size,
and to enhance stability.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
In case of on dm related target, we can clearly and safely
remove many unnecessary modules to reduce initramfs size,
and to enhance stability.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz1451717
https://bugzilla.redhat.com/1451717
When there is no crypt related kdump target, we can safely
omit "crypt" dracut module, this can avoid the pop asking
disk password during kdump boot in some cases.
This patch introduces omit_dracut_modules() before calling
dracut, we can omit more modules to reduce initrd size in
the future.
We don't want to omit any module for fadump, thus we move
is_fadump_capable() into kdump-lib.sh as a helper to use.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz1451717
https://bugzilla.redhat.com/1451717
Now that we have get_kdump_targets(), use it to simplify the code.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz1451717
https://bugzilla.redhat.com/1451717
We need to know all the kdump targets including the dump
target and root in case of "dump_to_rootfs".
This is useful for us to do some extra work related to the
type of different targets.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: bz1451717
https://bugzilla.redhat.com/1451717
This patch improves get_block_dump_target as follows:
-Consider block device in the special "--dracut-args --mount ..."
in get_user_configured_dump_disk().
-Consider save path instead of root fs in get_block_dump_target(),
and move it into kdump-lib.sh because we will have another user
in the following patch.
-For nfs/ssh dumping, there is no need to check the root device.
-Move get_save_path into kdump-lib.sh.
After this patch, get_block_dump_target() can always return the
correct block dump target specified.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Since the current dracut of Fedora already supports not always
mounting root device, we can remove "root=X" from the command
line directly, and always get the dump target specified in
"/etc/kdump.conf" and mount it. If the dump target is located
at root filesystem, we will add the root mount info explicitly
from kdump side instead of from dracut side.
For example, in case of nfs/ssh/usb/raw/etc(non-root) dumping,
kdump will not mount the unnecessary root fs after this change.
This patch removes "root=X" via the "KDUMP_COMMANDLINE_REMOVE"
(if "default dump_to_rootfs" is specified, don't remove "root=X"),
and mounts non-root target under "/kdumproot", the root target
still under "/sysroot"(to be align with systemd sysroot.mount).
After removing "root=X", we now add root fs mount information
explicitly from the kdump side.
Changed check_dump_fs_modified() a little to avoid rebuild when
dump target is root, since we add root fs mount explicitly now.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
Resolves: bz1411240
Use --hostonly-i18n to force dracut to install only needed
keyboard and font files according to host's configuration, which
reduced initramfs's size by 2M on F25 x86_64.
Signed-off-by: Tong Li <tonli@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
We maintained several kdump specific functions which are duplicate with the
similar versions in dracut, Dracut upstream splitted dracut init stuff from
dracut-functions.sh so that we can source it now.
Notes about kdump_get_presistent_dev:
Dracut now has a persistent_policy feature, for kdump when we dump to
raw disks we do not care the filesystem uuid and labels so we prefer to
search disk id instead. For raw disk set the persistent_policy before calling
get_persistent_dev ensure kdump logic still work.
Tested filesystem and raw dump in kvm guests.
[Xunlei: drop other functions other than get_persistent_dev.]
Signed-off-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
On a diskless client /etc/fstab does not exist. Therefore check
modification time of this file for rebuild only if it exists.
Also use --fstab option with findmnt only when /etc/fstab exists.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Kdump explicitly adds "nfs" dracut module in case of nfs dumping,
actually in case of nfs dump, nfs is a mount target, and will be
added into host_fs_types[], thus dracut will add it automatically,
according to 95nfs/module-setup.sh check().
So, we can safely remove all the add_dracut_module "nfs".
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
If dracut watchdog module is enabled then, it includes kernel watchdog
module of active watchdog device in initramfs.
kdump.conf has an option to modify dracut_args. So, if an user passes "-a
watchdog" in dracut_args then dracut will add kernel watchdog module of
active watchdog device in initramfs.
Since, kexec-tools always requires to add kernel watchdog module of active
watchdog device in initramfs, therefore even when an user does not pass any
watchdog option and there exists at least one active watchdog device then
also kexec-tools adds "-a watchdog" in dracut args.
Therefore, if an user does not want to add kernel watchdog module in
initramfs then the person must pass "-o watchdog" in dracut_args.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Resolves: BZ1348898
dracut-functions.sh defines a get_persistent_dev(). Earlier, we had another
local get_persistent_dev() in mkdumprd, however that was moved to
kdump-lib.sh, so that it can be reused in kdumpctl.
Since, dracut-module-setup.sh (which is dracut's
99kdumpbase/module-setup.sh) sources kdump-lib.sh. Therefore, once dracut
will execute 99kdumpbase module, it's own get_persistent_dev() function is
overwritten by kdump's version. If any other dracut module calls
get_persistent_dev() thereafter then, kdump's version is executed, which was
not expected.
Therefore rename kdump's get_persistent_dev() as kdump_get_persistent_dev()
to avoid any name contention.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
to_dev_name() and get_persistent_dev() can be used by function in kdumpctl.
Therefore moving them to kdump-lib.sh.
No functional changes.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Baoquan He <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
raw devices are not mounted and also does not need to contain any
filesystem. So they may have UUIDs(when formatted) and may not have UUIDs
when raw. Therefore, do not look for persistent names by-uuid for raw
devices.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Suggested-by: Dave Young <dyoung@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Baoquan He <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Ifcfg depends on network module, which is quite large and useless
when using a local dump target. Also we don't really need ifcfg to
setup network interfaces. So just remove it.
On fedora22, the uncompressed dumprd would decrease about 20MB when
using a local dump target. A regression testing is also conducted with
targets of nfs and ssh.
Signed-off-by: Dangyi Liu <dliu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Customer found when specify "noauto" option in fstab for nfs mount,
dump failed.
The reason is if "noauto" option is specified in fstab, the mount entry
in fstab related to dump target will passed to dracut and stored in
kdump initrd. Then during kdump kernel boots this entry containing
"noauto" will be ignored by mount service. This cause dump failing.
In fact with "noauto" not only nfs dump will fail, non-root disk dump
will fail too. root disk dump can dump successfully since root disk can
always be mounted by systemd.
So now "noauto" need be filtered out when the fstab entry corresponding
to dump target contains "noauto".
Changelog:
v4 -> v5
code comment is not clear enough. supplement it.
Signed-off-by: Qiao Zhao <qzhao@redhat.com>
Acked-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
kdump will raise the warning in Atomic, if the path is bind mounted
directory. The reason why causes this issue is kdump cannt parse the
bind mounted directory.
To correct dumping target, we can construct the real dumping path in
Atomic, which contains two part, one bind mounted path, the other
specified dump target.
Following is an example:
-bash-4.2# cat /etc/kdump.conf | grep ^path
path /var/crash
-bash-4.2# findmnt /var | tail -n 1 | awk '{print $2}'
/dev/mapper/atomicos-root[/ostree/deploy/rhel-atomic-host/var]
-bash-4.2# findmnt -v /var | tail -n 1 | awk '{print $2}'
/dev/mapper/atomicos-root
Then we can found it that the real path of dumping vmcore is
/ostree/deploy/rhel-atomic-host/var/crash.
To fix this issue, we can replace the target path as the real path which
is from above parsing.
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Any block device can be mounted multiply on the different mount point.
Once a mount point is mounted in bind mode, the general mount point can
be unmounted. Thus kdump would not find the general mount point[1] to
handle the path.
The mount point, which is as general mount point, will be got by
"fintmnt" previously. But the mntpoint may be incorrect, if the mntpoint
is bind mount.
In order to fix it to support bind mounted in atomic, we will add a
judgement to comfirm the mntpoint is bind mounted, or not.
For general mount, returning path is like following, if we use
"findmnt". The returning is same as "findmnt -v".
-bash-4.2# findmnt /var | tail -n 1 | awk '{print $2}'
/dev/mapper/atomicos-root
But for bind mount, returning path is like following, if we use
"fintmnt".
-bash-4.2# findmnt /var | tail -n 1 | awk '{print $2}'
/dev/mapper/atomicos-root[/ostree/deploy/rhel-atomic-host/var]
Use "findmnt -v" is like this:
-bash-4.2# findmnt -v /var | tail -n 1 | awk '{print $2}'
/dev/mapper/atomicos-root
So we can determine the bind mount, if the returning is different
between "findmnt" and "findmnt -v".
[1] general mount point is a directory without being in bind mounted
mode, just a normal directory.
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Now kdump cannt parse the path correctly, if the path contains
duplicated "/". Following is an example to explain it detail. (the
directory /mnt is a mount point which is mounted a block device)
path //mnt/var/crash
Then the warning will raise.
Force rebuild /boot/initramfs-3.19.1kdump.img
Rebuilding /boot/initramfs-3.19.1kdump.img
df: ‘/mnt///mnt/var/crash’: No such file or directory
/sbin/mkdumprd: line 239: [: -lt: unary operator expected
kexec: loaded kdump kernel
Starting kdump: [OK]
For above case, kdump fails to check the fs size, due to the incorrect
path.
In kdump code flow, we will cut out the mount point(/mnt) from the
path(//mnt/var/crash). But the mount point cannt match the path, because
of the duplicated "/".
To fix it, we will strip the duplicated "/" firstly.
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Jerry Hoemann reported a bug that a mount will fail when he installed
a system with separate "/" "/var" and "/var/crash". That means root
disk /dev/a mounted on /, and another disk /dev/b is mounted on /var,
then the 3rd disk /dev/c mounted on /var/crash. Then kdump will fail
since mount will fail.
This is because the mount information will be written into
/$mntimage/etc/fstab like below. And the dump target is /dev/c. However
/dev/b is not related in kdump, its mount info is not necessary and not
saved. So when go into kdump kernel, it will find there's not a crash
dir under /sysroot/var. And in current implementation, if not a root
disk dump, sysroot is a read-only mount, no dir can be created in this
situation.
/dev/disk/by-uuid/cdcf007a-b623-45ee-8d73-a8be0d372440 /sysroot/var/crash xfs rw,relatime,...,x-initrd.mount 0 2
So in this patch, change the mount behavior to fix this bug. If dump
target is a root disk, mount point is /sysroot. If dump target is not
root, just mount it to /kdumproot/$_target. Now it works.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Tested-by: Jerry Hoemann <jerry.hoemann@hp.com>
