LinuxQuestions.org - [SOLVED] Change in advice for creating initrd

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Change in advice for creating initrd (https://www.linuxquestions.org/questions/slackware-14/change-in-advice-for-creating-initrd-4175712142/)

Change in advice for creating initrd

I have always created initrd according the instructions in /boot/README.initrd

Quote:

mkinitrd -c -k 5.15.16 -m ext3 -f ext3 -r /dev/sdb3

Now on updating the kernel in accordance with the the recent slackware-security email I read

Quote:

# /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.15.38 | bash

This seems to be packing a few more modules into the initrd. What is happening here? Is this just a more foolproof method?

Alan

Change in advice for creating initrd

I do it the old way. No issues so far.

In addition to root filesystem support, I also add vfat, iso9660, loop and network card modules. Probably not needed, but will allow me to fix stuff if I break it.

On VMware VMs I also add the vmware pvscsi module... otherwise they can't boot.

What extra stuff does the generator add?

This is the output for the new way

Quote:

OK: /lib/modules/5.15.38/kernel/drivers/usb/host/xhci-hcd.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/xhci-pci-renesas.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/xhci-pci.ko added.
WARNING: Could not find firmware "/lib/firmware/renesas_usb_fw.mem"
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/ehci-hcd.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/ohci-hcd.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/ohci-pci.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/ehci-hcd.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/ehci-pci.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/xhci-hcd.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/uhci-hcd.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/usb/host/ehci-hcd.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/usbhid/usbhid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/i2c/i2c-core.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/i2c-hid/i2c-hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid-generic.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/acpi/video.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/platform/x86/wmi.ko added.
OK: /lib/modules/5.15.38/kernel/net/rfkill/rfkill.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/input/sparse-keymap.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/acpi/battery.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/acpi/platform_profile.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/platform/x86/asus-wmi.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/usbhid/usbhid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid-asus.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid-cherry.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/usbhid/usbhid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid-logitech.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/usbhid/usbhid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid-logitech-dj.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid-logitech-hidpp.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid-lenovo.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid-microsoft.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/5.15.38/kernel/drivers/hid/hid-multitouch.ko added.
OK: /lib/modules/5.15.38/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/5.15.38/kernel/fs/mbcache.ko added.
OK: /lib/modules/5.15.38/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/5.15.38/kernel/fs/mbcache.ko added.
OK: /lib/modules/5.15.38/kernel/fs/ext4/ext4.ko added.
63108 blocks

vs the old way

Quote:

OK: /lib/modules/5.15.38/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/5.15.38/kernel/fs/mbcache.ko added.
OK: /lib/modules/5.15.38/kernel/fs/ext4/ext4.ko added.

58895 blocks

The /sbin/mkintrd script is liberally commented to help understand how it works. Here's the comments from the last half of the script:

Code:

root@desktop:/sbin# grep '^#' mkinitrd 

...



# Note:

# ----

# This must be done after all options have been handled and

# not when handling case '-o' because -k can be passed after

# -o in which case, the tag %KVER% would be replaced with the 

# current kernel version instead of version passed with -k.

#

# If kernel modules are needed but the kernel version is absent, exit now:

# If clearing source tree was requested, do that first

# If there's no $SOURCE_TREE, make one now:

# If $ROOTDEV and $ROOTFS are not set, assume we want the

# values for the currently mounted /

# (unless we find that values are already set in the initrd-tree):

# If needed, write them in the initrd-tree:

# Put a copy of the command line used to create this initrd in

# initrd-tree/command_line:

# If /etc/mkinitrd.conf exists, put a copy of that in there as well.

# (May or may not have been used according to the -F option, but we'll

# save a copy anyway just in case):

# If $WAIT is not set, assume we need only one second

# to have all devices done

# (unless we find that value is already set in the initrd-tree):

# If no OUTPUT_IMAGE was specified, read it from the SOURCE_TREE if possible:

# If we still have no value, apply the default:

# Finally, write the image name into the SOURCE_TREE:

# Fill /resumedev with the swap partition holding the hibernation image

# Add custom keymap support if one was given

# If LUKSDEV was set in the config file, then we need to set CRYPT=1

# Check for LUKSTRIM

# If LUKSKEY was set in the config file, then give it a warm welcome:

# Include RAID support in initrd

# Include Btrfs support in initrd

# Include udev in initrd

#!/bin/ash

# This space is intentionally left blank

# Include LVM support in initrd

# Include cryptsetup (LUKS) support in initrd

#!/bin/sh

# Include device mapper in initrd (needed for LUKS and LVM)

# If there is additional filesystems to be mounted, copy their configuration

# from system's /etc/fstab:

# Make module directories:

# Copy kmod/modprobe stuff to initrd:

# Make sure modules.builtin and modules.order are there (for kmod):

# If an executable $SOURCE_TREE/load_kernel_modules already exists, then

# we assume you will want to load the kernel modules mentioned in there.

# This means, you do not have to explicitly add those on the commandline:

# If the module list is not empty, copy the modules into place:

# Copy needed libraries

# Make sure all libraries have symlinks:

# And finally, build the initrd:

root@desktop:/sbin#

The script makes a lot of assumptions if you don't tell it explicitly what to do.

The /usr/share/mkinitrd/mkinitrd_command_generator.sh helps to get the module list you may need in your initrd to use your hardware. I will also detect if you're LUKS encrypted.

I prefer to use the /etc/mkinitrd.conf file (provided as sample). I just change or override a few things at each run :

Code:

mkinitrd -F

Code:

# mkinitrd.conf.sample

# See "man mkinitrd.conf" for details on the syntax of this file

#

SOURCE_TREE="/boot/initrd-tree"

CLEAR_TREE="1"

OUTPUT_IMAGE="/boot/initrd-5.15.38.gz"  <----- I change/override this

#KERNEL_VERSION="$(uname -r)"

KERNEL_VERSION="5.15.38"  <----- and this

KEYMAP="fr"

#MODULE_LIST="ext4"

This is to adapt to your needs, if you have usb input devices or disks you want to have avaible early. For instance, I want to use a fex when docked to type my LUKS passphrase

MODULE_LIST="xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:crc32c_intel:crc32c_generic:ext4"

LUKSDEV="/dev/sdb3"

# verify support with 'hdparm -I $dev | grep TRIM'

LUKSTRIM="/dev/sdb3:/devsda2"

#LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"

ROOTDEV="/dev/cryptvg15/root"

ROOTFS="ext4"

RESUMEDEV="/dev/cryptvg15/swap"

#RAID="0"

LVM="0"

UDEV="1"

MODCONF="0"

MICROCODE_ARCH="/boot/intel-ucode.cpio"

#WAIT="1"

I use mkinitrd_command_generator.sh all the time. I don't however run the recomended command right away. As the mkinitrd_command_generator.sh comments say, it sure adds all the modules it can.

Using 'mkinitrd' as above works fine, just loads the modules for getting the root volume set up. Everything will be OK, until one day there is a problem with the root volume; initrd gives you a shell, but your keyboard does not work, because the USB and HID modules are not in the initrd. Then you will reconsider the advice from slackware-security, as you search around for that bootable USB flash drive or DVD. Been there.

Quote:

Originally Posted by ljb643 (Post 6353616)

Been there.

Isn't that what the huge kernel is for?

That's what I use the huge kernel for... Boot with Lilo, default to generic with an appropriate initrd, but always have the choice of switching to huge during boot if something goes wonky.

Quote:

Originally Posted by arubin (Post 6353702)

Isn't that what the huge kernel is for?

Been a while since I tried this, maybe Slackware-14.2 and around 2018, but I found to my dismay that the huge kernel didn't help because it also did not have USB drivers built in. If it can't get to its modules, no USB, no keyboard, no fun.

Quote:

Originally Posted by ljb643 (Post 6353947)

And the reason why it wouldn't be able to load modules?
You only mentioned a problem with the root volume.

It's certainly possible, but it would mean either the bios or bootloader's misconfigured, or it's missing the driver for rootfs.
So it's not very clear to me what exactly is the problem with huge kernel, and how it can be fixed.

Personally, I've used a partition where another system can always be booted if something happens to the first one.
So I can probably fix it either from another internal drive, or from another partition.

It's just very inconsistent that it's apparently failing to find modules on rootfs for unknown reason, TBH.

Here's my preferred change - Don't use an initrd unless you encrypt your root filesystem. Just build a kernel that has your early needs hard-wired and never have to deal with it again until you need to upgrade (not just patch) your kernel (not often on the same hardware).

Quote:

Originally Posted by ljb643 (Post 6353947)

Don't really understand this. One can navigate BIOS using a USB keyboard or the menus of a boot manager before the kernel is loaded.

Quote:

Originally Posted by arubin (Post 6354899)

Don't really understand this. One can navigate BIOS using a USB keyboard or the menus of a boot manager before the kernel is loaded.

BIOS setup menu, and boot loaders before loading the kernel, all use BIOS routines for USB and disk. Once the kernel boots it no longer uses those. If the kernel doesn't have USB drivers built in, and can't load them as modules for some reason, a USB keyboard will not work.

I no longer install 'huge' kernel as a recovery tool. Instead, I now keep 2 versions of 'generic', along with their separate modules. Also 2 separate initrd's. When there is a kernel update, I remove the older one and install the newer one, still keeping 2 versions. I think this provides good recovery ability.

Quote:

Originally Posted by enorbet (Post 6354548)

Nah. Life's too short. It's much easier to use an initrd... even with every single module listed above in post #3, it takes less than 10 seconds to make one.