We tell dhclient to name 121 option "classless-routes",
but in dhclient-script we parse classless_static_routes.
So either have to change the configuration or the script.
And since dhclient uses by default classless_static_routes,
let's change the configuration
hardcoding the wwid of the drives in the initramfs causes problems
when the drives are cloned to a system with the same hardware, but
different disk wwid's
https://bugzilla.redhat.com/show_bug.cgi?id=1457311
Support booting from USB media with NTFS filesystem (optionally),
which removes the FAT32 related 4 GB file size limit for LiveOS/
squashfs.img (and any other file on the same USB media).
On s390 BOOT_IMAGE only denotes the number of the boot record that
was selected in the bootloader and not the path to the kernel image.
Also only bail out, if the kernel hmac checking relies on that path.
blkid is not available when this function is called, so block_uuid.map is put into
the initrd, mapping block devices from /etc/crypttab to UUIDs.
This fixes a bug where udev rules were created by mistake as crypttab_contains()
returned false for devices specified by path in /etc/crypttab which resulted in
error messages during boot.
Signed-off-by: Julian Wolf <juwolf@suse.de>
Previously our dhclient-script expected that $new_classless_static_routes
will have all values separated by a whitespace. But at least on F25
dhclient will put there the destination descriptor in the same format
as it is used by ISC dhcp-server.
For example:
new_classless_static_routes=32.10.198.122.47 192.168.78.4
while our current code expects
new_classless_static_routes=32 10 198 122 47 192 168 78 4
So let's just accept both of these formats by adding "." to IFS.
For details plesse see https://tools.ietf.org/html/rfc3442
"Classless Route Option Format"
When NPIV is enabled and the allow_lun_scan parameter is set to 'Y'
the HBA will initiate a LUN scan automatically, so there is no need
to specify the WWPN and LUN number manually.
References: bsc#964456
Signed-off-by: Hannes Reinecke <hare@suse.com>
module_setup.sh has a typo preventing it from saving the correct
dracut commandline.
References: bnc#887582
Signed-off-by: Hannes Reinecke <hare@suse.de>
For creating dynamic udev rules parse-dasd.sh look for the device
type in sysfs, which of course does not exist if cio_ignore is
active. So first enable the device before checking.
Signed-off-by: Hannes Reinecke <hare@suse.de>
'for_each_host_dev_and_slaves' would stop at the first found
device, so the cmdline() call would never list all required
devices. Use 'for_each_host_dev_and_slaves_all' instead and
filter out duplicates.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Setting and unsetting the IFS variable is tricky. To be on the
safe side we should always reset the IFS variable to its original
value after parsing.
Signed-off-by: Hannes Reinecke <hare@suse.de>
For creating dynamic udev rules parse-dasd.sh look for the device
type in sysfs, which of course does not exist if cio_ignore is
active. So first enable the device before checking.
Signed-off-by: Hannes Reinecke <hare@suse.de>
'for_each_host_dev_and_slaves' would stop at the first found
device, so the cmdline() call would never list all required
devices. Use 'for_each_host_dev_and_slaves_all' instead and
filter out duplicates.
Signed-off-by: Hannes Reinecke <hare@suse.de>
When a DASD is found to be required for the rootfs we should
be printing out a 'rd.dasd' commandline parameter. This not
only enables us to correctly enable the device with cio_ignore,
we can also inspect the resulting initrd to figure out which
devices are required to mount the rootfs.
Signed-off-by: Hannes Reinecke <hare@suse.de>
There were some errors when rd.dasd parsing, resulting in the
device never to be activated. And we should check for
cio_ignore even if a udev rules has been found.
Signed-off-by: Hannes Reinecke <hare@suse.de>
When converting 'rd.zfcp' and 'rd.dasd' into udev rules we
need to make sure the enable those device ids via cio_ignore,
otherwise the rules might never be called.
Signed-off-by: Hannes Reinecke <hare@suse.de>
With the new s390x configuration tool the naming of the udev
rules files have changed. So add these to the existing ones
to be compatible with existing and new installations.
References: bnc#856585
Signed-off-by: Hannes Reinecke <hare@suse.de>
When converting 'rd.zfcp' and 'rd.dasd' into udev rules we
need to make sure the enable those device ids via cio_ignore,
otherwise the rules might never be called.
Signed-off-by: Hannes Reinecke <hare@suse.de>
This used to work only when specified via the command line
or if systemd was not being used. However, the exisistence of
20_force_driver.conf also requires dracut-pre-udev.service
to be run.
Reference: bsc#986216
removed copy&paste artifact "modify_routes add"
there is no modify_routes() function, and we simply want the output
of the parse function.
(cherry picked from commit 33710dfbfc)
If a hisi_sas storage device is used as / during system install, the
resulting installation will not boot because the hisi_sas driver is not
included in the initramfs.
The Hisilicon storage driver needs to be added to the initramfs image for
aarch64 kernels.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: dzickus@redhat.com
Cc: dmarlin@redhat.com
Cc: wefu@redhat.com
Cc: harald@redhat.com
This patch uses wait_for_dev "/dev/disk/by-id/md-uuid-${uuid}" for the
specified uuids.
On timeout only md devices are force started which are specified by
uuid, or all, if rd.auto was specified.
Fixes https://github.com/dracutdevs/dracut/issues/227
At least on x86 on Bay and Cherry Trail devices the pmw-lpss modules must
be in the initrd too, otherwise the i915 driver will still load, but
it will report the following error:
[drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip
And not register /sys/class/backlight/intel_backlight and users will
not be able to control their backlight.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
curl in Fedora recently changed its default CA trust store. The
Fedora package no longer specifies an OpenSSL-format bundle file
during build, and curl itself has been patched to use an NSS
plugin called libnssckbi.so when no bundle file or directory is
specified. There are (at present) two possible providers of the
libnssckbi.so module: the original NSS implementation, which
uses a trust bundle built in at build time, and a compatible
implementation from the p11-kit project, which reads a trust
bundle at run time. So if we find a string in libcurl.so that
suggests libnssckbi might be in use, we must both install it and
make an effort to install any trust bundle files it may use.
The p11-kit libnssckbi implementation does include a string that
lists the top-level trust directories it will use, so we try to
find that string, though the best effort I can come up with will
also find many false positives too. To weed out the false
positives, we check whether the matches actually exist as dirs,
and if so, whether they contain some specific subdirectories we
know p11-kit trust dirs must have (thanks, @kaie). For the NSS
libnssckbi implementation, we will likely wind up not finding any
dirs that match the requirements, so we will simply install the
libnssckbi.so file itself, which is the correct action.
This fixes TLS transactions in the initramfs environment when
using a curl that's built this new way; it's significant for
use of kickstarts and update images with the Fedora / RHEL
installer, as these are retrieved in the initramfs environment,
and are frequently retrieved via HTTPS.
The newer mount utilities are more strict about directly shared
devices. For OverlayFS boots, which mount $BASE_LOOPDEV directly,
avoid a mount error by indirectly sharing the read-only base
filesystem through a second, over-attached $BASE_LOOPDEV for
the DM live-base target.
Harald Hoyer