The info message written by require_binaries() was a bit frighten to
users. So just be a little bit more verbose.
If you have ideas on how to improve the message for these "soft"
dependency modules, please submit patches.
(cherry picked from commit 0fa5dbedc5)
Add new functions require_binaries() and require_any_binary() to be used
in the check() section of module-setup.sh.
These functions print a warning line telling the user, which binary is
missing for the specific dracut module.
This unifies the way of checking for binaries and makes the life of an
initramfs creator easier, if he wants to find out why a specific dracut
module is not included in the initramfs.
(cherry picked from commit 30e6e809ed)
for a variable with spaces, e.g.:
EXT_KEYMAPS='backspace keypad euro2'
The following would occur:
print_vars: eval printf -v _value %s '$EXT_KEYMAPS'
print_vars: printf -v _value %s backspace keypad euro2
print_vars: [[ -n backspacekeypadeuro2 ]]
print_vars: printf '%s=\"%s\"\n' EXT_KEYMAPS backspacekeypadeuro2
Thanks to Sebastian Köln for the fix!
(cherry picked from commit 7a94a4326f)
Due to the 'inst_libdir_file "libnss_files*"' in the udev-rules module
this caues the /usr/lib/libnss_files-2.18.so* to be included. This is a
32-bit library and pulls in a 32-bit version of glibc also even on a
64-bit system.
This is due to the fact that ldconfig -pN will print [/usr]/lib paths
from the cache as well as [/usr]/lib64. As we handle these paths
specifically we should ignore these results from the cache.
Also there was a missing space when appending the ldconfig paths
onto our list meaning the last builtin and first ldconfig path
were unusable.
If new kernels have modules split out, handle the case, where modules
have to modalias and just install them.
Also add the crypto drivers and names to host_modalias.
--persistent-policy <policy>:
Use <policy> to address disks and partitions.
<policy> can be any directory name found in /dev/disk.
E.g. "by-uuid", "by-label"
This prints the kernel command line parameters for the current disk
layout.
$ dracut --print-cmdline
rd.luks.uuid=luks-e68c8906-6542-4a26-83c4-91b4dd9f0471
rd.lvm.lv=debian/root rd.lvm.lv=debian/usr root=/dev/mapper/debian-root
rootflags=rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered
rootfstype=ext4
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]
Harald Hoyer