[SOLVED] Booting issue with initrd on 5.4.13

business_kid · 02-08-2020, 08:20 AM

I'm on Slackware64-Current.

I've been booting fine with my own kernels. I like to have 2, in case I hose my own recompiling it. My ones don't need an initrd. I retired my older one and went to kernel-generic-5.4.13, kernel-modules-5.4.13, and reinstalled kernel-firmware. Then I made an initrd with mkinitrd specifying -c, -f, -h, -k & -o options. It wouldn't boot the generic 5.4.13 kernel. The error was

Code:

Trying to resume from /dev/sda2
mount: Mounting /dev/sda6 failed: no such device (or not mounted). Trouble Ahead

I tried with just the -f and -k options. Same story.

It threw me to a primitive shell from the initrd where indeed /dev/sda6 wouldn't mount. There's nothing spectacular going on here. Here is grub.cfg & blkid

Code:

# Begin /boot/grub/grub.cfg
set default=0
set timeout=5
set root=(hd0,1)

menuentry "Slackware64-Current-5.4.14-dec2" {
	linux /vmlinuz-5.4.14-dec2 root=/dev/sda6 ro
} 
menuentry "Slackware64-generic-5.4.13" {
        linux /vmlinuz-generic-5.4.13 root=/dev/sda6 ro
	initrd /initrd-5.4.13
}
menuentry "Linux Mint-19.0 Tara" {
        linux   /vmlinuz-4.15.0-20-generic root=/dev/sda3 ro
        initrd  /initrd.img-4.15.0-20-generic
}
bash-5.0$blkid
/dev/sda1: LABEL="Boot" UUID="b813280e-533f-49dd-8759-1677795b2e17" TYPE="ext4" PARTUUID="e9db2110-01"
/dev/sda2: UUID="098bb17c-c5af-45c4-b5f6-83745b875774" TYPE="swap" PARTUUID="e9db2110-02"
/dev/sda3: UUID="74d16e12-be9b-41cd-aa8f-5ca2bb28c8cc" TYPE="ext4" PARTUUID="e9db2110-03"
/dev/sda5: UUID="a4736823-20b5-4f6c-9f1d-e758f465705f" TYPE="ext4" PARTUUID="e9db2110-05"
/dev/sda6: UUID="6589a5de-aa91-4dc5-9ddf-95398700792c" TYPE="ext4" PARTUUID="e9db2110-06"
/dev/sda7: UUID="b431a00f-2be2-47a2-a490-df25f1fe89eb" TYPE="ext4" PARTUUID="e9db2110-07"
/dev/sdb1: UUID="36bb5f76-addb-4711-ae13-4d9296d5b918" TYPE="ext4" PARTUUID="5f216f6c-01"
bash-5.0$

As Alien Bob is always scolding me for not doing full installs, I ran 'upgradepkg --install-new' on the 'a/' & 'l/' directories on the current iso, and remade the initrd, but it still made no difference. Same error.

This is no emergency as working kernels exist here, I would just like the generic one booting

Tonus · 02-08-2020, 08:46 AM

We need a full command for your mkinitrd. Or/and your mkinitrd.conf. And the output.

gegechris99 · 02-08-2020, 11:12 AM

in grub.cfg, I would use the following syntax for 5.4.13 menu entry:

Code:

menuentry "Slackware64-generic-5.4.13" {
        linux /boot/vmlinuz-generic-5.4.13 root=/dev/sda6 ro
	initrd /boot/initrd-5.4.13.gz

That's how linux and initrd lines are generated when I run the following command in one of my systems on which I use grub:

Code:

grub-config -o /boot/grub/grub.cfg

If the above manual correction to grub.cfg doesn't work, I would suggest you run:

Code:

grub-config -o /boot/grub/grub-temp.cfg

to see how menu entry for 5.4.13 is created in /boot/grub/grub-temp.cfg

business_kid · 02-08-2020, 12:55 PM

Thanks for the replies, guys.
@gegechris99: In your honour I renamed initrd-5.4.13 to 5.4.13.gz, re-ran grub, and got the same error. I thought I would, because it can'tmount /, but I'm dumped into a shell with a few utilities which must be in the initrd, so it's getting and reading the initrd, to my mind. Thanks for the idea, though. I don't have grub-config (a script?) installed, I use grub-install instead.

@Tonus: Good thoughts; the command (as root)

Code:

mkinitrd -c -f ext4 -h /dev/sda2 -k 5.4.13 -o /boot/initrd-5.4.13.gz

/etc/mkinitrd.conf was one of those

moments. I had overwritten all the config files

So I confidently cobbled up a config file from the sample, this one

Code:

bash-5.0$ cat /etc/mkinitrd.conf
# 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.gz"
#KERNEL_VERSION="$(uname -r)"
#KEYMAP="us"
MODULE_LIST="ext4"
#LUKSDEV="/dev/sda2"
#LUKSTRIM="/dev/sda2" # verify support with 'hdparm -I $dev | grep TRIM'
#LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"
ROOTDEV="/dev/sda6"
ROOTFS="ext4"
RESUMEDEV="/dev/sda2"
RAID="0"
LVM="0"
UDEV="1"
#MODCONF="0"
#MICROCODE_ARCH="/boot/intel-ucode.cpio"
#WAIT="1"
bash-5.0$

and very confidently made another initrd, only to get the very same error.

The system fails to mount /dev/sda6 on /mnt (in the initrd), and drops me to a shell in the initrd. I presume it checks the drive and then remounts it to / afterwards.

GazL · 02-08-2020, 01:47 PM

Try dropping the "root=/dev/sda6 ro" from the bootloader config file when using an initrd. You should only need that if you're booting without an initrd.

Didier Spaier · 02-08-2020, 02:18 PM

Quote:

Originally Posted by business_kid

mkinitrd -c -f ext4 -h /dev/sda2 -k 5.4/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.13 -o /boot/initrd-5.4.13.gz

It wouldn't hurt to tell what is the root device, using the -r option. Easier:

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.13|sh
 mv /boot/initrd.gz /boot/initrd-4.13.gz

To know more:

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh -h

gegechris99 · 02-08-2020, 02:25 PM

Quote:

Originally Posted by business_kid

I don't have grub-config (a script?) installed, I use grub-install instead.

My mistake: the command is grub-mkconfig

Code:

grub-mkconfig -o /boot/grub/grub-temp.cfg

mumahendras3 · 02-08-2020, 05:29 PM

Quote:

Originally Posted by business_kid

@Tonus: Good thoughts; the command (as root)

Code:

mkinitrd -c -f ext4 -h /dev/sda2 -k 5.4.13 -o /boot/initrd-5.4.13.gz

You probably forgot to add ext4 kernel module to the initrd, based on that command line. Add "-m ext4" option to your mkinitrd command or just run something like

Code:

mkinitrd -F -k 5.4.13

With "-F" option, mkinitrd will use your /etc/mkinitrd.conf (which I think is already correct). Then, with "-k 5.4.13", mkinitrd will build initrd for kernel version 5.4.13 instead of the kernel version specified inside mkinitrd.conf (or instead of currently running kernel if KERNEL_VERSION is not set or commented out in mkinitrd.conf).

business_kid · 02-09-2020, 06:51 AM

Thanks for all the replies.

To the several posts advising me on grub.cfg:
My grub.cfg is there in post #1. I took the entry for kernel-5.4.14-dec2 booting (running now) on the same drive ( which is tested, good, and working) and edited the Label and the kernel name. I also added the initrd line. The initrd is loading, because I land in some busybox-type shell. Grub-mkconfig apparently writes a new grub.cfg (which I already have). My grub.cfg is 416 bytes, like a lilo.conf and I like it that way. Grub-command-generator.sh I don't have, and don't want to know about. My Mint distro has that stuff probably, but the grub.cfg there is 10k. Strewth!

@mumahendras3: I think you're closer concentrating on the mkinitrd, but I'm not there yet.

I went looking for modules in the initrd, and /lib/modules/5.4.13 had only modules.builtin, and modules.order, but no kernel/ directory in the initrd-tree. I have to use the -k option with mkinitrd, because Slackware64-current made the slightly unusual move of distributing 5.4.13 precompiled kernels, and 5.4.14 sources. I booted up again and remade the initrd as follows:

Code:

mkinitrd -c -f ext4 -h /dev/sda2 -k 5.4.13 -m ext4 -o /boot/initrd-5.4.13.gz

It produced no error, but when I got dropped to the shell, and I had no modules
but 6 files of the nature of modules.something.

Now, as a rule, I think I'm smart. So I inevitably get problems smarter than I am. Evil thoughts uncurled themselves in my head. I made another initrd using -F (no use) and then examined the /boot/initrd-tree. No modules there! So I installed ext4.ko in the appropriate directory half a dozen subdirs down, remade the initrd, and thought I was out of the woods. It puked, of course, with the same error. It had no modules in /lib/modules/5.4.13.

The modules had been deleted out of /boot/initrd-tree

colorpurple21859 · 02-09-2020, 07:37 AM

check /lib/modules/5.4.13/kernel/fs/ to see if ext4 exist there. I did a test to see if mkinitrd will throw error if a module doesn't exist by using ext5, no error was thrown and no ext in initrd tree.

Alien Bob · 02-09-2020, 08:17 AM

Quote:

Originally Posted by business_kid

Grub-command-generator.sh I don't have, and don't want to know about.

This was not mentioned. You were advised to run mkinitrd_command_generator.sh which is part of Slackware's mkinitrd package. The script will examine your system and show you a mkinitrd commandline which will get you an initrd image that is able to boot your computer.

Quote:

Slackware64-current made the slightly unusual move of distributing 5.4.13 precompiled kernels, and 5.4.14 sources.

Of course Slackware does not do such a thing.

First, the kernel in -current is 5.4.18. Why are you installing an old 5.4.13 kernel? That one is from 18 January and was replaced with 5.4.14 on 24 January.

Second, you probably have an incomplete copy of the Slackware-current mirror because you should have received the 5.4.14 kernels along with all the rest. This is a timing problem: if you sync your local copy while Pat is still uploading his new batch you can end up with an inconsistent set. The remedy to that, is to do another re-sync an hour later. Your issues with booting will be gone once your local package mirror is consistent again.

business_kid · 02-09-2020, 11:58 AM

Quote:

Slackware64-current made the slightly unusual move of distributing 5.4.13 precompiled kernels, and 5.4.14 sources.
Of course Slackware does not do such a thing.

There's probably sense to me downloading during upgrades to the server.

And there's something funny with your Irish mirror. There's certainly variations between the package versions on the Current directory slackpkg uses and the Current isos. I usually grab an iso to have a snapshot of the ~Current I update to. The kernel packages are dated 2020-02-06. But the iso downloaded on the 9th (today) has 5.4.17 kernel stuff.

Also 'slackpkg upgrade-all' gave me a huge kernel which I didn't have installed but left my 5.4.13 generic kernel in place.

Meanwhile, while I was chasing versions and double-checking, my own recipe 5.4.18 kernel compiled. So I can kind of call an end to this. I can confirm that mkinitrd_command_generator.sh exists as /usr/share/mkinitrd_command_generator.sh. I had checked for it with 'which', and that threw up nothing in the path.

So my 2 kernels are going to be 5.4.14 (tested) & 5.4.18 (tested), neither needing an initrd. The initrd can vanish, along with the 5.4.13 kernel. I'm not tempted to chase any unlikely bugs. The missing modules in /boot/initrd-tree is bizarre. Initrds are normally simple in Slackware.

As a matter of interest I ran the mkinitrd_command_generator.sh. It seemed businesslike, but supplied every module I ever need in the initrd. I only need ext4 in the initrd, because once / mounts, all the rest are there anyhow.