I'd like to rework CoreOS Ignition (which runs in the initramfs)
to include some values from the *real* `/etc/os-release` in
HTTP headers.
Looking at this, it turns out dracut eats almost all of the useful
information from it. I don't think `dracut` should be the `ID`
here...dracut's not an OS itself, it's a way to *build* little
operating systems. It'd be kind of like if Fedora's Koji
injected itself into `/etc/os-release`.
This code dates back a long time; not sure of all the rationale
behind it.
I changed it so that we keep extending the VERSION/PRETTY_NAME
with the dracut version, but otherwise "pass through" the
rest of the real `/etc/os-release` we were built from unchanged.
This change still supports Python 2.6 and 2.7 but loses support
for Python 2.5.
The reason for this change was that Fedora 30 does not ship
python-imgcreate but ships python3-imgcreate.
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
The `README.md` was nearly empty. Move the travis bits into
`README`, then rename `README` to `README.md`.
This matches the Github standard. A major compelling feature
of Github is how prominently it displays a project's `README.md`,
so let's ensure ours has content.
Starting with the 0.7.7 release of the multipath tools, the multipath
udev rules always set a value in ENV{DM_MULTIPATH_DEVICE_PATH} for any
device that multipath scans. A value of 0 means that the device is not
claimed by multipath, and a value of 1 means that it is. Because of
this, udev rules that check ENV{DM_MULTIPATH_DEVICE_PATH}=="?*" will
always return True, and act as if every scanned device is claimed by
multipath. Checking ENV{DM_MULTIPATH_DEVICE_PATH}=="1" will work
correctly for both the old and new versions of the multipath tools.
For LUKS2 partitions cryptsetup needs a locking directory. If it does
not exist, cryptsetup will create it, but produce a warning
WARNING: Locking directory /run/cryptsetup is missing!
in the process that we do not want to see in the dracut output.
Since Bash 4.4, command substitutions containing null bytes produce a
warning of the form
/usr/sbin/dracut: line 1958: warning: command substitution: ignored null byte in input
Remove the trailing null byte from the UEFI kernel command line file
before printing it to suppress this warning.
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.
Colin Walters