The RPM build failed on due to missing and unpackaged files on my Fedora
machine that happened to have %fedora set to %nil for reasons long
forgotten.
This is probably not a likely scenario, but some of the conditions in the
SPEC file are still wrong and perhaps worth fixing.
Default value of EVMKEYDESC (in evm-enable.sh) is "evm-key" and it's
also specified previously in this README file.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
When booting with Fedora-Server-dvd-x86_64-30-20190411.n.0.iso,
/proc/cmdline is empty (libvirt, qemu host with bios, not sure if that
matters), after installation to disk, anaconda would "crash" in kernel-core
%posttrans, after calling kernel-install, because dracut would fail
with
> Could not determine the kernel command line parameters.
> Please specify the kernel command line in /etc/kernel/cmdline!
I guess it's legitimate, even if unusual, to have no cmdline parameters.
Two changes are done in this patch:
1. do not fail if the cmdline is empty.
2. if /usr/lib/kernel/cmdline or /etc/kernel/cmdline are present, but
empty, ignore /proc/cmdline. If there's explicit configuration to
have empty cmdline, don't ignore it.
Kill the no longer used function, so that anyone won't be confused and
try to modify this function in future.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1146769
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The compressed firmware support was supposed to be already
implemented, but it didn't work as expected in the end, because dracut
moved to use dracut-install binary. This patch adds the support of
XZ-compressed firmware installation to dracut-install for fixing the
missing piece.
At best the firmware files should be uncompressed in initrd, but this
patch simply copies the compressed file as-is, as a quick workaround.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1146769
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a SHA-1 hash of a specific commit is used as a tag, the regex
shenanigans later in the script can (and will) corrupt it in certain
cases.
e.g.:
$ perl -e '
$tag="6e8cd92261577230daa1098f7e05ec198c3c4281";
$tag=~s/[^0-9]+?([0-9]+)/$1/;
print("$tag\n");
'
68cd92261577230daa1098f7e05ec198c3c4281
(Notice the missing 'e')
Let's fix this by limiting the regex's scope to a non-SHA-1 tags only.
Previously with squash module, some binaries will be reinstalled, but
stripping happens before that so new installed binaries is not stripped.
So adjust the squash and strip order, ensure new installed binaries are
stripped just the same way with the old binaries.
Also split squash into two stage to make the split easier, move the
squash temp dir into initdir so stripping will cover that too,
and print more usefule message.
Signed-off-by: Kairui Song <kasong@redhat.com>
When you install a third-party driver, you will probably end in a
situation, where the module will be in a different directory and
in $depmod_module_dir you will only have symlink. If we resolve the
symlink before we pass the module path to instmod, the dracut-install
will only include the module with its original path, but not the
symlink. Hence the module can't be automatically loaded.
Dracut-install is clever enough to handle symlinks and will include both
the symlink and the module to the initrd.
In e54ab383 we moved the fips script to a later pahse of boot, since
the /boot might not be available early on.
The problem is that systemd-cryptsetup* services could be run now
started before the do_fips is executed and need the crypto modules
to decrypted the devices.
So let's split the do_fips and load the module before udev does the
trigger.
When DRACUT_SYSTEMD is set and DRACUT_QUIET=yes, vinfo returns 1. This
is a problem for hooks which end with vinfo, as then the hook returns 1.
Especially problematic if this is a shutdown hook, as it will be
restarted again and again.
This commit fixes that.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
on line 1086 it's used to check for the uefi_stub:
"${systemdutildir}/boot/efi/linux${EFI_MACHINE_TYPE_NAME}.efi.stub"
so it needs to be defined before that
The EFI executables produced by dracut --uefi must be placed in the
subdirectory /EFI/Linux of the EFI system partition (ESP) according to
the Boot Loader Specification, see
https://systemd.io/BOOT_LOADER_SPECIFICATION#logic
This is done correctly for the mount points /boot and /boot/efi, but for
the mount point /efi, the files are placed in /efi/Linux instead of the
correct /efi/EFI/Linux. This commit fixes the directory so that the EFI
executables are picked up correctly by conforming boot loaders.
Apart from complying to the specification, the change is also in line
with the commit message of 5c57209ba5
("dracut.sh: add default path for --uefi") which introduced this feature
as well as the documentation in dracut.8.asc.
If the network-manager plugin is used instead, it wouldn't write out
ifcfg files and we wouldn't have anything to check.
While at that, also enable the test.
The IFCFG test will make sure the network-legacy plugin keeps writing
out correct ifcfg files.
This is a separate commit so that actual changes are visible in the
following one.
If the root is on network, let nm-initrd-generator create configuration
even if none was explicitly specified on the command line.
Also do the same if /tmp/net.ifaces exists, because the anaconda plugin
creates an empty file in that location in hopes that will make us
configure the network.
On Fedora 30 the paritition sizes turn out to be too small again:
+ mkdir -p /sysroot
+ mount /dev/dracut/root /sysroot
+ cp -a -t /sysroot /source/bin /source/dev /source/etc /source/lib /source/lib64 /source/proc /source/root /source/sbin /source/sys /source/tmp /source/usr /source/var
cp: error writing '/sysroot/usr/lib64/libkrb5.so.3.3': No space left on device
cp: error writing '/sysroot/usr/lib64/libkrb5support.so.0.1': No space left on device
It turns out that there has been quite some size increase in some libraries,
notably glibc, though not all -- some even shrunk, ruling out a toolchain
problem. Here's are files over 1M we install on Fedora 30:
f29 f30
2.7M => 6.4M /usr/lib64/{libc-2.28.so => libc-2.29.so}
3.1M => 6.0M /usr/lib64/libcrypto.so.1.1.1c
2.0M => 3.5M /usr/lib64/{libm-2.28.so => libm-2.29.so}
2.9M => 2.8M /usr/lib/systemd/{libsystemd-shared-239.so => libsystemd-shared-241.so}
1.7M => 2.5M /usr/lib64/libunistring.so.2.1.0
2.3M => 2.4M /usr/lib64/bind9-export/libdns-export.so.1105.0.0
1.2M => 2.1M /usr/bin/bash
1.1M => 1.4M /usr/lib64/libkrb5.so.3.3
1.2M => 1.4M /usr/lib64/libgcrypt.so.20.2.4
612K => 1.1M /usr/lib64/libssl.so.1.1.1c
This increases the image sizes to accomodate for this. There's probably
little else we can do.
The kernel may only enable 'libfcoe' module. Some modules like bnx2fc
provides FCoE but only depend on 'libfcoe'. Loading 'fcoe' module may
fail but the kernel do support FCoE.
'libfcoe' will be installed as a dependency when installing block device
drivers if it's required. So no need to install it in installkernel.
Signed-off-by: Kairui Song <kasong@redhat.com>
When a module is compressed, uncompress it before packing into initrd.
Since initrd is already compressed, it makes no sense to put the
compressed module files.
The patch contains a slight refactoring and adds a helper function to
get the command for uncompressing a file per extension.
Bash 5 apparently longer propagates variable assignments to local variables
in front of function calls when in POSIX mode:
[lkundrak@demiurge ~]$ cat feh.sh
print_VAR () {
echo "$VAR";
}
testfunc () {
local VAR="OLD"
VAR=NEW print_VAR
}
testfunc
[lkundrak@demiurge ~]$ bash4 --posix feh.sh
NEW
[lkundrak@demiurge ~]$ bash5 --posix feh.sh
OLD
[lkundrak@demiurge ~]$ bash5 feh.sh
NEW
[lkundrak@demiurge ~]$
It works the way it did in Bash 4 in non-POSIX mode, for external programs,
or for non-local variables. Don't ask me why -- it's probably some
compatibility thing for some sad old people.
However, this precisely happens when fsck_single() is calling into the
fsck_drv_com(), assigned to _drv by fsck_able(). That ruins the
TEST-70-BONDBRIDGETEAMVLAN test's server and probably more.
Let's pass the fsck driver binary via the function argument instead. It's
less messy anyway.
- The network script and config could be in
"/etc/sysconfig/network-scripts", so try look for network config in
all possible path.
- The regex used for sed is not working, so fix it too.
- Make bootproto a local variable
Signed-off-by: Kairui Song <kasong@redhat.com>
The dracut-root-block-created line should not be created if we fail to copy
in the required files to sysroot. Let's turn on -e to trap failures and
poweroff on them, like some other tests do.
Also remove the &&. Not only it is unnecessary with -e, but defeats it.
From bash(1):
The shell does not exit if the command that fails is [...] part of any
command executed in a && or || list except the command following the
final && or || [...]
when system's default entropy sources are poor (e.g. use of SSD disks or
UEFI RNG not available)
On systems with low entropy at boot, the boot can take up to several
hours, specially when NBDE is used (e.g. clevis) which makes use of
the random number generator.
Enabling rngd service at boot early, because dracut-initqueue runs,
enables to initialize the random number generator in a couple of seconds
instead of minutes or hours.
Signed-off-by: Renaud Métrich <rmetrich@redhat.com>
The commit 9f3c31cd8d ("99base: enable initqueue if extra devices are added")
only covers 'dracut --add-device' case, but it did not cover 'dracut --mount'
case, which causes the kdump failure in the Amazon virtual machine.
Lets make sure that the initqueue is enabled in both cases in order to wake up
the device in time.
Reported-by: Xiao Liang <xiliang@redhat.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Lubomir Rintel