LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Already broke my Slackware install :-/ (https://www.linuxquestions.org/questions/slackware-14/already-broke-my-slackware-install-4175674972/)

lionoceros 05-10-2020 06:08 PM

Already broke my Slackware install :-/
 
Just installed Slackware on an encrypted drive by combining LUKS and LVM as described in README_CRYPT on the install media. Made an initrd that worked. Everything went well until I upgraded Slackware packages (including the kernel) with slackpkg and rebooted (well, hibernated). Slackpkg ran lilo automatically. Now the system won’t boot. It hangs after I enter my encryption password. I suspect the problem is that the initrd made with the install kernel does not match the currently installed kernel. Didn’t catch which exact version of the kernel is now installed.

I tried to boot from the USB install media, chroot, and run mkinitrd again hopefully for the new kernel. That didn’t work because, as it says, modules are not installed for 4.4.14. I have never chrooted from install media before so I could have done something wrong there too.

Please help me fix this problem. I can’t figure out how to reinstall the original kernel or make a new initrd.

Thanks

hitest 05-10-2020 06:18 PM

Quote:

Originally Posted by lionoceros (Post 6121508)
Slackpkg ran lilo automatically.

If you upgrade your kernel with slackpkg it does not automatically run lilo. There is the suggestion that you should run lilo by running # /sbin/lilo, but, it does not do it for you. You need to run lilo at the terminal prompt before you reboot. So that may be why your system isn't booting up.

Gerard Lally 05-10-2020 06:24 PM

Quote:

Originally Posted by lionoceros (Post 6121508)
Just installed Slackware on an encrypted drive by combining LUKS and LVM as described in README_CRYPT on the install media. Made an initrd that worked. Everything went well until I upgraded Slackware packages (including the kernel) with slackpkg and rebooted (well, hibernated). Slackpkg ran lilo automatically. Now the system won’t boot. It hangs after I enter my encryption password. I suspect the problem is that the initrd made with the install kernel does not match the currently installed kernel. Didn’t catch which exact version of the kernel is now installed.

I tried to boot from the USB install media, chroot, and run mkinitrd again hopefully for the new kernel. That didn’t work because, as it says, modules are not installed for 4.4.14. I have never chrooted from install media before so I could have done something wrong there too.

Please help me fix this problem. I can’t figure out how to reinstall the original kernel or make a new initrd.

Thanks

Boot from install media.

I'm not familiar with LUKS but I assume you can unlock the disk if you've already successfully chrooted into the system, so I'll leave the decryption part to you.

Once the disk is decrypted, use vgchange -ay to bring logical volumes online.

Mount your volumes:

Code:

mount /dev/mapper/vgsystem-lvroot /mnt
Prepare the chrooted environment:

Code:

mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys

chroot into the system:

Code:

chroot /mnt
Use Eric's script to create an appropriate initrd for the kernel installed in the chroot:

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.4.217 > /etc/mkinitrd.conf

mkinitrd -F

I'm assuming you have upgraded to the latest kernel 4.4.217 for Slackware 14.2.

Make sure your initrd line is correct in lilo.conf

Run lilo

.

colorpurple21859 05-10-2020 06:25 PM

look at the /boot/README.initrd

lionoceros 05-10-2020 07:51 PM

Alright, here's an overview of what I did using your post as well as the instructions in the slackdocs article Chroot From Installation Media and README_CRYPT. I'm on slackware64 14.2.

Didn't seem to work as now the boot process is stopped by "No kernel modules found for 4.4.217." I'm prompted to enter the decryption key/password but then the system hangs.

In my setup /boot is an unencrypted /dev/sda5 and the encrypted volume encompassing root, /home, and swap is /dev/sda6. Also @hitest I apologize but when I wrote slackpkg ran lilo automatically, I meant slackpkg presented it as an option [Y/n] and I ran it. I did not create a new initrd at that time.





Code:

Boot from slackware USB.
# cryptsetup luksOpen /dev/sda6 slackluks
# vgscan --mknodes
# vgchange -ay
# mkdir /mnt/boot
# mkdir /mnt/home
# mount /dev/cryptvg/home /mnt/home
# mount /dev/cryptvg/root /mnt
# mount /dev/sda5 /mnt/boot
# mount -o bind /dev /mnt/dev
# mount -o bind /proc /mnt/proc
# mount -o bind /sys /mnt/sys
# chroot /mnt
# /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.4.217 > /etc/mkinitrd.conf
# mkinitrd -F
(At this point the mkinitrd seemed to work)
# vim /etc/lilo.conf (Looked alright)
# lilo
# reboot -f (reboot on its own does not seem to work)

Still no luck :-/

colorpurple21859 05-10-2020 07:56 PM

post your /etc/mkinitrd.conf

Gerard Lally 05-10-2020 08:13 PM

Yes, post your /etc/mkinitrd.conf.

What does the following report, inside the chroot:
Code:

find /var/log/{packages,removed_packages}/ -name "kernel*"
?

And ls -la /boot ?

lionoceros 05-10-2020 08:39 PM

mkinitrd.conf:

Code:

mkinitrd -c -k 4.4.217 -f ext4 -r /dev/cryptvg/root -m usb-storage:ehci-hcd:ehci-pci:xhci-pci:ohci-pci:xhci-hcd:uhci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -C /dev/sda6 -L -u -o /boot/initrd.gz -h /dev/cryptvg/swap
Output of # find /var/log/{packages,removed_packages}/ -name "kernel*"

Code:

/var/log/packages/kernel-huge-4.4.217-x86_64-1
/var/log/packages/kernel-firmware-20191108_f1100dd-noarch-1
/var/log/packages/kernel-headers-4.4.217-x86-1
/var/log/packages/kernel-generic-4.4.217-x86_64-1
/var/log/packages/kernel-source-4.4.217-noarch-1
/var/log/packages/kernel-modules-4.4.217-x86_64-1
/var/log/removed_packages/kernel-huge-4.4.14-x64_64-1-upgraded-2020-05-10,22:33:15
/var/log/removed_packages/kernel-modules-4.4.14-x64_64-1-upgraded-2020-05-10,22:33:17
/var/log/removed_packages/kernel-source-4.4.14-noarch-1-upgraded-2020-05-10,22:33:40
/var/log/removed_packages/kernel-generic--4.4.14-x64_64-1-upgraded-2020-05-10,22:33:12
/var/log/removed_packages/kernel-firmware-20160628git-noarch-1-upgraded-2020-05-10,22:32:36

ls -la /boot

Really sorry but this command put out too much to type - is there another way I could upload this? Can't exactly copy and paste from install media to a web browser.

sxy 05-10-2020 09:27 PM

My original post
Quote:

Quote:

Originally Posted by lionoceros (Post 6121555)
mkinitrd.conf:

Code:

mkinitrd -c -k 4.4.217 -f ext4 -r /dev/cryptvg/root -m usb-storage:ehci-hcd:ehci-pci:xhci-pci:ohci-pci:xhci-hcd:uhci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -C /dev/sda6 -L -u -o /boot/initrd.gz -h /dev/cryptvg/swap

It's not a valid mkinitrd.conf file. The mkinitrd_command_generator.sh script generates a *command, not a configuration file. Use 'man mkinitrd.conf' or 'less /etc/mkinitrd.conf.sample' to see how to write that file.

EDIT:
Often the command generated by mkinitrd_command_generator.sh is already good enough. It's not really necessary to use the -F option. You may try
Code:

# chmod +x /etc/mkinitrd.conf
# /etc/mkinitrd.conf

I'd suggest to save the output of mkinitrd_command_generator.sh to another file, though.
was wrong. I've tested that mkinitrd.conf with a single line of the mkinitrd command also works. My bad, sorry.

enorbet 05-10-2020 10:14 PM

Maybe I'm barking at the moon but if I see an error message "No kernel modules found for 4.4.217", the 1st thing I'm going to do is be certain there is a directory and file structure at "/lib/modules/4.4.217". If it doesn't exist get back into "/usr/src/linux" (assuming it links to /usr/src/linux-4.4.127) and run "make modules_install". Then I'm going to check /boot to see if my old working kernel is there (actually I'd not delete it or it's entry in /etc/lilo.conf...backups are smart) and if it is then I'd redo it's lilo.conf entry and rerun lilo. If vmlinuz-4.x-whatever-the-old-kernel-image-was isn't there but the source tree in /usr/src/linux-whatever is still there I'd redo the steps for copying config, System.map, and bzImage to vmlinuz-whatever in /boot and again fix lilo.

So far I haven't seen any evidence initrd is failing.

colorpurple21859 05-11-2020 05:13 AM

Chroot back into your system
Change this part of the /etc/mkinitrd.conf line
Code:

-k 4.4.217
to
Code:

-k "$(readlink /boot/vmlinuz | cut -d- -f3-)"
rerun
Code:

mkinitrd -F
That way it will match the kernel version that is in /boot
exit out of chroot and reboot.

lionoceros 05-11-2020 05:50 PM

It worked!!!

Here is a summary of the required steps:

Code:

Boot from slackware USB.
# cryptsetup luksOpen /dev/sda6 slackluks
# vgscan --mknodes
# vgchange -ay
# mkdir /mnt/boot
# mkdir /mnt/home
# mount /dev/cryptvg/root /mnt
# mount /dev/cryptvg/home /mnt/home
# mount /dev/sda5 /mnt/boot
# mount -o bind /dev /mnt/dev
# mount -o bind /proc /mnt/proc
# mount -o bind /sys /mnt/sys
# chroot /mnt
# /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.4.217 > /etc/mkinitrd.conf
(I don't remember where I got this line. Have been trying to find the website again)
Change this part of the /etc/mkinitrd.conf line "-k 4.4.217" to "-k "$(readlink /boot/vmlinuz | cut -d- -f3-)""
# mkinitrd -F
# vim /etc/lilo.conf (Looks alright)
# lilo
# exit
(Exit from chroot)
# reboot

I'm not sure why changing the -k part of mkinitrd.conf fixed it because running:

Code:

readlink /boot/vmlinuz | cut -d- -f3-
in the console while chrooted just produced the output:

Code:

4.4.217
In any case, the system booted. Thank you so much!

colorpurple21859 05-11-2020 07:24 PM

Whenever there is a kernel update, all you have to remember to run is
Code:

mkinitrd -F
and lilo if you use it. The "readlink /boot/vmlinuz | cut..."calls out the kernel version for the mkinitrd.

gsl 05-11-2020 07:29 PM

Quote:

Originally Posted by sxy (Post 6121567)
My original post was wrong. I've tested that mkinitrd.conf with a single line of the mkinitrd command also works. My bad, sorry.

I could be wrong (and probably am) but I presume it "works" because mkinitrd sources /etc/mkinitrd.conf which just runs the mkinitrd command created by mkinitrd_command_generator.sh.

I think the proper way to populate mkinitrd.conf is "/usr/share/mkinitrd/mkinitrd_command_generator.sh --conf > /etc/mkinitrd.conf".

colorpurple21859 05-11-2020 08:26 PM

Either way will populate the mkinitrd.conf and work, --conf makes the file easier to read IMHO. However, with a kernel update a "modules doesn't exist" error will occur because the kernel version in the mkinitrd.conf will still point to the old kernel version.


All times are GMT -5. The time now is 03:10 PM.