8f5c5 broke the case where BOOT_IMAGE is not set at all.
This code should handle following:
1) BOOT_IMAGE not set
2) BOOT_IMAGE set to something unrelated (s390)
3) BOOT_IMAGE=vmlinuz-4.14.7-300.fc27.x86_64
4) BOOT_IMAGE=/vmlinuz-4.14.7-300.fc27.x86_64
5) BOOT_IMAGE=/boot/vmlinuz-4.14.7-300.fc27.x86_64
6) BOOT_IMAGE=subdir/vmlinuz-4.14.7-300.fc27.x86_64
7) BOOT_IMAGE=/subdir/vmlinuz-4.14.7-300.fc27.x86_64
8) BOOT_IMAGE=/boot/subdir/vmlinuz-4.14.7-300.fc27.x86_64
https://bugzilla.redhat.com/show_bug.cgi?id=1415032
Using the module option 'scsi_mod.scan=manual'
this implements LUN masking by selectively enable only those
devices required for booting.
References: bsc#954600,FATE#319786
Signed-off-by: Hannes Reinecke <hare@suse.de>
Now that we are using persistent network names we can switch
to using the interface names when specifying the fcoe configuration.
With that we can print the fcoe configuration only once.
Signed-off-by: Hannes Reinecke <hare@suse.com>
Occasionally the FCoE connection might be reset after fipvlan was
called, causing the FCoE connection to be dropped and boot to fail.
For these cases we should be adding a timeout entry for the
initqueue to have a failsave mechanism to re-run fipvlan in
these cases.
References: bsc#1052840
Signed-off-by: Hannes Reinecke <hare@suse.com>
bnx2fc doesn't _actually_ need fcoemon, so fipvlan is sufficient
to start the FCoE connection.
And, in fact, fcoemon is started for every interface, causing
subsequent invocations to fail with
fcoemon[1157]: error 98 address already in use
and fcoemon tearing down the connection.
References: bsc#1052840
Signed-off-by: Hannes Reinecke <hare@suse.com>
The 'mode' argument was never referenced in the printf format, causing
invalid rules to be written.
References: bsc#1036323
Signed-off-by: Hannes Reinecke <hare@suse.com>
We should be disabling the FCoE connection (which triggers sending
a LOGO internally) to logout from the target; this resets the target
and will avoid hitting a busy condition during reboots.
References: bsc#994860
Signed-off-by: Hannes Reinecke <hare@suse.com>
fcoemon is well capable of figuring out whether a vlan should
be used, so there's no need to disable the AUTO_VLAN feature.
References: bsc#995019
Signed-off-by: Hannes Reinecke <hare@suse.com>
Old code did not work for two most common use-cases.
On most machines BOOT_IMAGE is set to something like
/vmlinuz-4.11.3-202.fc25.x86_64. So if we just add prefix "/boot/."
it won't work. Also on machines without /boot on separate partition
BOOT_IMAGE already has the /boot/ prefix (/boot/vmlinuz-3.10.0-799.el7.x86_64).
So let's strip it in such case.
https://bugzilla.redhat.com/show_bug.cgi?id=1415032
The needle argument in this specific case is a pattern, which cannot be
matched by the "literal" string matcher strstr.
This can result in fsck calls like:
e2fsck -a -y /dev/sda1
Which will then exit with an error like:
e2fsck: Only one of the options -p/-a, -n or -y may be specified.
Hence, it is necessary to use the strglobin function to correctly match
the pattern.
The "host" command may also print something else than
"asdf.local.lan has address 1.2.3.4", like:
"rootserver.local.net is an alias for rainbow.local.net.".
So "head -n1" is not enough.
Fixes boo#955592
References: boo#965477
fcoe-uefi gets included by default on EFI systems,
as it does not do the same check that fcoe does,
therefore needlessly pulling in network modules.
This patch copies the check from fcoe to fcoe-uefi.
We're now parsing the 'rd.dasd' parameter from 95dasd_rules, so
setting the 'dasd_mod' module parameter should be dropped here.
Signed-off-by: Hannes Reinecke <hare@suse.de>
There is no point trying to delete partitions; dmraid works
happily even with them. On the contrary trying to delete partitions
can even be harmful when eg dmraid should _not_ be started.
References: bsc#998860
Signed-off-by: Hannes Reinecke <hare@suse.com>
DM devices might be located on top of MD devices, so we need to
call the DM shutdown script before MD shutdown. The exception
here are multipath devices, which are below MD devices.
So skip removing multipath devices here to avoid spurious errors.
References: bsc#994860
Signed-off-by: Hannes Reinecke <hare@suse.com>
When calling the shutdown script we need to take care of traversing
the device-mapper tables, otherwise we might end up trying to remove
a device-mapper device which still has another one stacked on top
and the removal will fail.
References: bsc#994860
Signed-off-by: Hannes Reinecke <hare@suse.com>
local-fs-pre.target serves as a separator between the code for
detecting block devices and systemd's fsck/mount logic. This
patch ensures that multipathd is started before local-fs-pre.target
in the initrd. By adding a "Wants=" line for local-fs-pre.target,
it makes sure that this target is started at all.
References: bsc#1006118
Signed-off-by: Martin Wilck <mwilck@suse.de>
===================================================================
SLES11 provided a kernel commandline option 'multipath=off',
so dracut should be parsing the option, too.
References: bsc#1001691
Signed-off-by: Hannes Reinecke <hare@suse.com>
As the device-mapper module is removing all device-mapper tables
during shutdown we need to make sure to disable queuing on the
multipath devices; otherwise there might still be I/O pending
and the removal will fail.
References: bsc#994860
Signed-off-by: Hannes Reinecke <hare@suse.com>
We need to wait until udev has processed all events, otherwise we'll
risk of misdetecting devices. This might cause a temporary interruption
during which multipath removes a device-mapper device, which then
causes a booting failure.
References: bsc#986734
Signed-off-by: Hannes Reinecke <hare@suse.com>
Harald Hoyer