A hostonly image will not include every possibly required kernel module,
so if any hardware or configuration changed, the image may fail to boot.
One way to know if there are any hardware change or configuration change
that will require an image rebuild or not is to check the loaded kernel
module list. If the loaded kernel module list differs from last build
time, then the image may require to be rebuilt.
This commit will let dracut record the loaded kernel module list when
the image is being built, so other tools or services can compare this
list with currently loaded kernel modules to decide if dracut should be
called to rebuild the image.
To retrieve the loaded kernel modules list when an image is built, use
lsinitrd command:
lsinitrd $image -f */lib/dracut/loaded-kernel-modules.txt
Check for a common binary in systemdutildir. This resolves an issue on
split-usr systems, where it is common to have both /lib/systemd[/system]
and /usr/lib/systemd[/user] present.
Check for systemd-udevd specifically, since some distros (Gentoo) allow
udev to be installed without the rest of the systemd stack.
Similar logic is applied to udevdir simply for consistency.
Add a new option --hostonly-mode which accept an <mode> parameter, so we have a tri-state hostonly mode:
* generic: by passing "--no-hostonly" or not passing anything.
"--hostonly-mode" has no effect in such case.
* sloppy: by passing "--hostonly --hostonly-mode sloppy". This
is also the default mode when only "--hostonly" is given.
* strict: by passing "--hostonly --hostonly-mode strict".
Sloppy mode is the original hostonly mode, the new introduced strict
mode will allow modules to ignore more drivers or do some extra job to
save memory and disk space, while making the image less portable.
Also introduced a helper function "optional_hostonly" to make it
easier for modules to leverage new hostonly mode.
To force install modules only in sloppy hostonly mode, use the form:
hostonly="$(optional_hostonly)" instmods <modules>
Signed-off-by: Kairui Song <kasong@redhat.com>
When dracut silently produces a broken initramfs, then the system will
likely not boot and this can be very problematic. Typical use case is
after the kernel has been updated.
It appears that dracut is not protected against the BASH_ENV variable,
causing various scripts called by dracut to possibly fail or provide
wrong output (e.g. "ldd" is one of these).
Having a broken output for "ldd" makes the generated initramfs be not
usable, typically because vital binaries will be missing (e.g.
"awk", "udevadm", ...).
Note: because the shebang line cannot contain more than one argument,
the '--norc' option had to be removed. IMHO, it was useless anyway.
Signed-off-by: Renaud Métrich <rmetrich@redhat.com>
It's possible for e.g. `kernel` to be installed as an RPM BuildRequires or equivalent,
and there's no reason to sync, and *definitely* no reason to fsfreeze.
Another case where this happens is rpm-ostree, which performs its own sync/fsfreeze
globally. See e.g. 8642ef5ab3
We initially enabled it for Haswell TSX bug (mga#16657)
Now there is also Meltdown and Spectre security issues,
and more microcode issues will most likely show up...
So the sane default for 'early_microcode' to have it enabled,
as theese changes must be done early in boot process to take
effect as intended.
Update documentation accordingly.
Reference: https://bugs.mageia.org/show_bug.cgi?id=16657
Signed-off-by: Thomas Backlund <tmb@mageia.org>
Signed-off-by: Neal Gompa <ngompa13@gmail.com>
When the system boots with EFI, then initrd image is stored
on EFI System Partition. Thus dracut always warn about the
failure to invoke fsfreeze on the partition.
This prevents to run fsfreeze on ESP and suppress the warning.
- dracut replaced every instance of "-i" in the cmdline,
even if it was part of a kernel image name, e.g. "vmlinuz-i"
- Fixes boo#908452
Signed-off-by: Fabian Vogt <fvogt@suse.com>
Adjusted to not support "dracut -ifoo bar", as this breaks expected
upstream behavior.
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 disables lsinitrd logging when --quiet option is given,
which is controlled by maxloglvl only before. This will speed up
dracut image building as the following if --quiet is used in kdump:
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
Signed-off-by: Ziyue Yang <ziyang@redhat.com>
In case of "--no-hostonly-default-device", we do not need
the root device, thus add this check.
Also fixed the stale "root_dev" export.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Kdump doesn't need default host devices like root, swap, fstab, etc,
we only care about the dump target which can be added via "--mount"
or "--add-device". We met several issues that kdump kernel failed
due to one of those host devices added by dracut, additionally, the
needless devices(e.g. LVM) consume some appreciable amount of memory
which is more likely to cause OOM under memory-limited kdump.
So this patch introduced "--no-hostonly-default-device" to avoid
adding those default devices as host_devs.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
If we trigger crash just after creating initramfs, sometimes it is
observed that initramfs is not written to disk causing the subsequent
boot to fail. A sync should resolve this.
Signed-off-by: Ankit Kumar <ankit@linux.vnet.ibm.com>
If we trigger crash just after creating initramfs, sometimes it is
observed that initramfs is not written to disk causing the subsequent
boot to fail. A sync should resolve this.
Signed-off-by: Ankit Kumar <ankit@linux.vnet.ibm.com>
This is intended for minimum host OSes where 36 MB used by binutils
are deemed too expensive. We only need "strip", which exists as eu-strip
in elfutils, which in turn is < 1 MB in size.
Note that the tests (TEST-04-FULL-SYSTEMD/test.sh) still depend on
strip from binutils. It could use sstrip in the future.
The default output filename for --uefi is
<EFI>/EFI/Linux/linux-$kernel$-<MACHINE_ID>-<BUILD_ID>.efi.
<EFI> might be /efi, /boot or /boot/efi depending on where the ESP partition
is mounted. The <BUILD_ID> is taken from BUILD_ID in /usr/lib/os-release or
if it exists /etc/os-release and is left out, if BUILD_ID is non-existant or
empty.
Also a new option --no-machineid was added, which affects the default output
filename of --uefi and will discard the <MACHINE_ID> part.
Dracut changes working directory before attempting to output files under
$DRACUT_TMPDIR , resulting in an IO failure if $DRACUT_TMPDIR is a path
relative to the working directory when dracut was started.
Fixes: https://github.com/dracutdevs/dracut/issues/156
Signed-off-by: David Disseldorp <ddiss@suse.de>
Handle module aliases correctly to not generate unbootable
initrds with different kernel versions when modules were renamed
or replaced.
Signed-off-by: Fabian Vogt <fvogt@suse.com>
Harald Hoyer