I had time to do some more tests.

• I verified I am on Slackware64 using Slackware64 DVD.
• All kernel packages are from DVD at version 5.15.19.
• Also kernel-firmware is taken from DVD.
• Following all your advices has changed nothing.

/var/log/messages last entry is on May 11, the last time a shutdown the laptop with a working Slackware.

I installed GRUB from DVD and the issue persists. I'm sure everything is all right, and I don't know if a full reinstall should change anything...
Any advice I can try maybe on GRUB prompt?

That's because we're just guessing here. Without evidence, it's all a bunch of assumptions and guesswork.

There's no evidence of this. Have you used a live CD and compared live CD messages with your internal messages?

How did you make this conclusion?

And then "something" changed, and you've neglected to mention what exactly has changed, so we can only assume..
Could be fstab, not enough modules in initrd, plugging/unplugging usb storage, filesystem corruption..
Hardware failure, drained CMOS battery, and windows bcd could be running in there for all we know..

Whatever it is, we're generally assuming human error first, because that is a major cause of system failures.
Unless of course there's evidence, like comparison of lsmod/lspci/lsusb/dmesg between a working and broken system.
And it's usually standard practice for users here to have backups, so they can easily revert "something" that changed.

@elcore

In the defense of OP, I would like to note that IF it's something like happened with booting LILO in some of my motherboards, there are no logs, nothing.

What I seen myself is LILO loading the kernel and initrd, then hard reboot of the box. I doubt that the kernel was even started. And this happened with perfectly fine and consistent Slackware(64) 15.0 installations.

So, I can confirm that really exists issues like this, the single difference in my case is that I do not intended to keep using LILO on those affected computers, so I have just switched to UEFI (which worked fine), not bothering about this beyond of taking note.

@OP

I suggest you to create an flasdrive with LiveSlak with persistence.

https://download.liveslak.org/
https://docs.slackware.com/slackware:liveslak

It's considerably easier to debug a broken system while using a fully fledged Slackware system running Plasma5 or XFCE. There LiveSlak would help much.

I for one, I use for cases like this an USB hard drive which contains a full installation of Slackware and even a mirror of the official tree - in fact I have 2 hard drives like this, one for latest stable and one for -current.

I suggest you to make one like this in the future - after all, is quite cheap to buy an USB enclosure and a second hand laptop hard drive you may have already in your locker.

The slackware64 dvd boots okay. Have you tried booting the system from the dvd?
Maybe an incomplete upgrade could be causing the problem? Boot partition wasn’t mounted?

My internal messages are stuck at my last successful boot, on May 11. I'm pretty sure that reboot happens before initrd, after GRUB/LILO so nothing is being written...
It's a laptop. I use no external devices, nothing is connected to any port, and it's always been like this. Both drives have the same UUID as before and are reachable by same /dev/sdx device, contains all the files and fsck reports nothing.
Nothing changed that last day. I booted to look into a webpage while a was working on another pc, and used to uptime to upgrade. The only packages where those of the kernel.
fstab is the same, modules are the same, no usb storage, no filesystem corruption, cmos has been dead for at least a year.
I do have backups of the old /boot partition. It's not working either. And all my files are safe, I have multiple copies and as I said all drives are fine, mountable and readable under chroot.

I'm really just trying to understand what could have gone wrong...

If you are able to boot the installation DVD with its kernel and chroot to your installed root partition it is a good way to start fixing things. The next step might be to boot the installation DVD huge kernel and pointing that kernel to your installed root partition. However, I must admit that I have no experience from doing that with an encrypted root partition.

Once you have a working kernel with access to your installed root partition the "only" thing left to fix is some boot loader capable of booting your working kernel with your root partition.

What bootloader did you use when you successfully booted the kernel from the installation DVD? Grub? Isolinux? If you have an EFI system you probably used grub, but if you have an old MBR bios you probably used isolinux.

regards Henrik

Delcaran, it is entirely possible that a change unrealized by you took place while doing something else as some software these days does write to BIOS/UEFI Firmware and some can change settings with little or no notice, especially if you also run Win10 or 11.

What where all the commands used to chroot into the system?

1 members found this post helpful.

I had the same problem as the original post. Using a Slackware installation USB drive to boot the root partition worked, so it seemed to be something related to the kernel or booting the kernel.

1 members found this post helpful.

Yeah we could argue forever whether or not CMOS is dead or pining for the fjords.
But it's a futile argument, since CMOS is the kind of thing that's always there, deciding the order of boot devices.
Even if the battery is dead, CMOS data is still there in its default state.

So far, it took 3 pages for you to even mention there is a boot partition (which is something that Slackware installer won't do by default).
And you didn't answer if there's another system installed, sdcard plugged in, cd/dvd inside, or any of that crucial information.

Additionally, after the initial kernel upgrade, have you tried a new mkinitrd script to make initrd or just used mkinitrd command directly?
Did you make new initrd on boot partition or elsewhere? Are there modification dates on kernel image and initrd image, and more specifically do they match?
Have you still got these kernel packages which you used to upgrade the machine, and if so, could you provide a md5/sha* checksums of these packages?

While I'm still bored enough to try and help you, I'm not patient enough to invest weeks/months into this.

I'd really like to know what sort of X86 machine will even POST let alone boot when CMOS is dead. I have to assume you don't mean the actual CMOS is dead but the battery that powers CMOS instead, but even that will prevent POST. Without power to BIOS/UEFI the machine will likely still get a Power Good signal allowing a few basic functions like powering LEDs and Fans but that's all in my experience.

The dvd boots okay, the internal drive lilo bootloader menu loads, my guess it would have something to do with the initrd. What happens if you boot without initrd, will the kernel load to the point it locks up?

Just checking: did you upgrade the kernel-modules package? I read through your messages and you didn't specifically say.
If you forgot, they would be still on 5.15.27, which would explain why neither the latest kernel nor the install kernel boot.

As @colorpurple21859 said, see what this command shows:

1 members found this post helpful.

I'm sorry, I thought I provided all the relevant information, but maybe it was only clear in my head since I always followed Slackware READMEs.

The laptop has only one SSD drive formatted like this:

• /dev/sda1 mounted as /boot with unencrypted ext4
• /dev/sda2 is a LUKS drive with LVM named cryptvg
• /dev/cryptvg/root is ext4 and mounted as /
• /dev/cryptvg/home is ext4 and mounted as /home
• /dev/cryptvg/swap is the swap partition

Slackware is the only system installed, there were nothing inserted anywhere, not even the mouse since I almost never need X11.


I tried the old script I've used since 14.2 came out, which was generated the first with Then when it wasn't working, inside chroot I ran the command directly and with the configuration file. After each command I ran lilo -v and rebooted without success.

In the /boot partition.

Yes, they match.

I do not, since I have rolled back to Slackware64 15.0's default of 5.15.19 taken from the DVD. The DVD was correctly downloaded (as torrent) and burned (checksum was correct). When I did the upgrade I did through slackpkg+, so checksum was checked as correct.

All kernel related packages are now at 5.15.19, I checked with /var/log/packages.

That I have not tried, I will as soon as I come back from a work trip on Monday.

I followed this guide. These are the commands I enter after logging in with root on the DVD:

• cryptsetup luksOpen /dev/sda2 cryptvg
• vgchange -ay
• mount /dev/cryptvg/root /mnt
• mount /dev/sda1 /mnt/boot
• mount /dev/cryptvg/home /mnt/home
• mount -o bind /dev /mnt/dev
• mount -o bind /sys /mnt/sys
• mount -o bind /proc /mnt/proc
• swapon /dev/cryptvg/swap
• chroot /mnt /bin/bash

Slackware was my only system, and on my last successful boot I was only in TTY1 and TTY2 inside runinit 3. In TTY1 I was running lynx, in TTY2 I first run slackpkg+, the mkinitrd and then lilo -v. Nothing else, not even X11. I really doubt something changed in the BIOS...

add to the mix, chroot into the system and run Maybe that will generate a working initrd