Because omit_drivers list use underline always, so when maching with it
the _mod need to be converted as well or sometimes omit-drivers will fail
silently.
Fix this by replace '-' with '_' in instmods function.
Signed-off-by: Dave Young <dyoung@redhat.com>
On Wed, Jul 10, 2013 at 10:58:15AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 10, 2013 at 09:37:11AM +0200, Harald Hoyer wrote:
> > On 07/10/2013 02:29 AM, Yu, Fenghua wrote:
> > >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > >> Sent: Tuesday, July 09, 2013 12:24 PM
> > >> Implement it per Linux kernel Documentation/x86/early-microcode.txt
> > >> (from v3.11-rc0):
> > [...]
> > > This patch works fine with one microcode blob in binary format. There are situations that the microcode is not delivered in one blob in binary format:
> > >
> > > First, each microcode patch is one file instead all microcode patches are in one big blob. Secondly, old delivered microcode file is in ascii format.
> > >
> > > To handle those formats, additional code needs to convert the formats into one big binary microcode blob. I'm not sure if we should consider the code and if we should put the code in dracut.
> > >
> > > Thanks.
> > >
> > > -Fenghua
> > >
> >
> >
> > $ ls /lib/firmware/amd-ucode
> > microcode_amd.bin microcode_amd_fam15h.bin microcode_amd_solaris.bin
>
> Right, so all of those blobs (for AMD) get stuck in AuthenticAMD.bin.
>
> > $ ls /lib/firmware/intel-ucode
> > 06-03-02 06-06-00 06-07-02 06-08-0a 06-0b-04 06-0f-06 06-16-01 06-1c-02
> > 06-25-02 06-2d-07 0f-01-02 0f-02-09 0f-04-03 0f-04-0a
> > 06-05-00 06-06-05 06-07-03 06-09-05 06-0d-06 06-0f-07 06-17-06 06-1c-0a
> > 06-25-05 06-2f-02 0f-02-04 0f-03-02 0f-04-04 0f-06-02
> > 06-05-01 06-06-0a 06-08-01 06-0a-00 06-0e-08 06-0f-0a 06-17-07 06-1d-01
> > 06-26-01 06-3a-09 0f-02-05 0f-03-03 0f-04-07 0f-06-04
> > 06-05-02 06-06-0d 06-08-03 06-0a-01 06-0e-0c 06-0f-0b 06-17-0a 06-1e-04
> > 06-2a-07 0f-00-07 0f-02-06 0f-03-04 0f-04-08 0f-06-05
> > 06-05-03 06-07-01 06-08-06 06-0b-01 06-0f-02 06-0f-0d 06-1a-04 06-1e-05
> > 06-2d-06 0f-00-0a 0f-02-07 0f-04-01 0f-04-09 0f-06-08
>
> And all of those get catted in GenuineIntel.bin.
>
> >
> > Also, for [[ $hostonly ]], we only want to add the current running CPU microcode.
>
> <nods> Will do that. Are you OK with me adding some of this CPU detection logic
> in dracut-functions.sh?
This is still RFC, as I had not done the --no-compress logic (or tested it).
Please see if this is OK:
>From 5f853d2ececd4cadff648e22cb9c9287a01a9783 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 9 Jul 2013 13:57:01 -0400
Subject: [PATCH] dracut.sh: Support early microcode loading.
Implement it per Linux kernel Documentation/x86/early-microcode.txt
(from v3.11-rc0):
<start>
Early load microcode
====================
By Fenghua Yu <fenghua.yu@intel.com>
Kernel can update microcode in early phase of boot time. Loading microcode early
can fix CPU issues before they are observed during kernel boot time.
Microcode is stored in an initrd file. The microcode is read from the initrd
file and loaded to CPUs during boot time.
The format of the combined initrd image is microcode in cpio format followed by
the initrd image (maybe compressed). Kernel parses the combined initrd image
during boot time. The microcode file in cpio name space is:
on Intel: kernel/x86/microcode/GenuineIntel.bin
on AMD : kernel/x86/microcode/AuthenticAMD.bin
During BSP boot (before SMP starts), if the kernel finds the microcode file in
the initrd file, it parses the microcode and saves matching microcode in memory.
If matching microcode is found, it will be uploaded in BSP and later on in all
APs.
The cached microcode patch is applied when CPUs resume from a sleep state.
There are two legacy user space interfaces to load microcode, either through
/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file
in sysfs.
In addition to these two legacy methods, the early loading method described
here is the third method with which microcode can be uploaded to a system's
CPUs.
The following example script shows how to generate a new combined initrd file in
/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and
original initrd image /boot/initrd-3.5.0.img.
mkdir initrd
cd initrd
mkdir -p kernel/x86/microcode
cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin)
find . | cpio -o -H newc >../ucode.cpio
cd ..
cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img
<end>
That is what we do in the patch. Furthermoere there is also
an off-switch: "no-early-microcode" to disable it.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Support --host-only parameter]
The find_kernel_modules_by_path function shouldn't filter out modules not
located underneath the /lib/modules/ver/kernel directory as out-of-tree
drivers may reside in /lib/modules/ver/extra and updated drivers in
/lib/modules/ver/updates.
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
dracut_install should return the real return value, so module install function
can detect the install failure.
Such as below in 99base:
dracut_install switch_root || dfatal "Failed to install switch_root"
Signed-off-by: Dave Young <dyoung@redhat.com>
Credits go to Alexander Tsoy <bugs+gentoo@puleglot.ru> who provided the
patch with following explanation:
I get messages "Skipping program $env{DM_SBIN_PATH}/..." when
generating initramfs. This happens because some udev rules contains
variables in path to command:
$ egrep -r 'IMPORT\{program\}=\"\$' /lib64/udev/rules.d/
/lib64/udev/rules.d/10-dm.rules:ENV{DM_COOKIE}=="?*", IMPORT{program}="$env{DM_SBIN_PATH}/dmsetup udevflags $env{DM_COOKIE}"
[...]
$ sudo dracut -f "" 3.5.4-hardened-r1
I: *** Including module: dm ***
I: Skipping program $env{DM_SBIN_PATH}/dmsetup using in udev rule 10-dm.rules as it cannot be found
If new modules are introduced, or modules get renamed, or modules change
from builtin to real modules, we want to include them in the host-only
image, just to be safe.
An exception is multipath devices, child and top layer device may have
same uuid. As dm devices maintain /dev/mapper/* as persistent names,
just do not doing converting for them.
For devices with filesystem, udev /dev/disk/by-uuid/* links are always
reliable. So improve the get_persistent_dev() by using by-uuid/* firstly,
and fallback to use by-id/*
Signed-off-by: Dave Young <dyoung@redhat.com>
kdump module also need to convert dev name to udev symlinks.
So better to move function get_persistent_dev() to dracut-functions.sh
Also in this patch improvement and fix the original function:
a) use udevadm info --query=name to get the kernel name.
This will fix the issue caused by passing symbolic link of a device.
b) fix a bug to compare $_tmp instead of $i with $_dev. Really sorry,
should have tested more carefully.
Signed-off-by: Dave Young <dyoung@redhat.com>
for_each_host_dev_and_slaves currently is used in some module check()
functions and it's not necessary iterate all slaves. So use
check_block_and_slaves instead of check_block_and_slaves_all is fine.
Signed-off-by: Dave Young <dyoung@redhat.com>
For lvm, multipath, iscsi modules they do not care about the filesystem,
Also there could be devcie in host_devs but it does not get formated.
For these kind of modules, use for_each_host_dev_and_slaves will be better than use
for_each_host_dev_fs, here add a new function to iterate the host_devs and
their slave devices.
In original for_each_host_dev_fs, it will call check_block_and_slaves which
will return once helper function return 0, but this is not enough for kdump
iscsi setup. For kdump iscsi case, it need setup each slave devices so that
the iscsi target can be properly setuped in initramfs.
Thus, this patch also add new functions check_block_and_slaves_all and
for_each_host_dev_and_slaves_all.
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: WANG Chao <chaowang@redhat.com>
This reverts commit b2d225a669.
When there's no /sys/dev/block/$2/slaves/*/dev/ exists, $_x will
be assigned with '/sys/dev/block/$2/slaves/*/dev/', this is invalid.
That commit will lead to some warn msg like:
cat: /sys/dev/block/8:16/slaves/*/dev: No such file or directory
cat: /sys/dev/block/8:32/slaves/*/dev: No such file or directory
Harald Hoyer