From Newsgroup: alt.os.linux.slackware

Hello!

I installed 15 in EFI mode and ran slackpkg upgrade-all, which removed
the old kernel.

I ran eliloconfig, LILO works, the kernel 5.15.209 loads, but says no
kernel modules found.
mount failes with no such device, the device is there, but I cannot
mount it manually. lsmod shows nothing.
Is maybe the part for ext4 missing?

How can I fix this?
--
Gru|f
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Marco Moock <mm@dorfdsl.de> wrote:

Hello!

I installed 15 in EFI mode and ran slackpkg upgrade-all, which removed
the old kernel.

I ran eliloconfig, LILO works, the kernel 5.15.209 loads, but says no
kernel modules found.
mount failes with no such device, the device is there, but I cannot
mount it manually. lsmod shows nothing.
Is maybe the part for ext4 missing?

How can I fix this?

Did you remember to recreate the initrd if you are booting a kernel
that uses an initrd (lack of modules implies you are using a kernel
that needs the correct initrd).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Am 04.07.26 um 21:12 schrieb Rich:

Did you remember to recreate the initrd if you are booting a kernel
that uses an initrd (lack of modules implies you are using a kernel
that needs the correct initrd).

No, I didn't. I had a BIOS machine (dunno if that used the huge kernel)
that didn't need that.

How can I do that now?
Boot the install image, switch to the virtual console and chroot into
the installed OS?
--
Gru|f
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Marco Moock <mm@dorfdsl.de> wrote:

Am 04.07.26 um 21:12 schrieb Rich:

Did you remember to recreate the initrd if you are booting a kernel
that uses an initrd (lack of modules implies you are using a kernel
that needs the correct initrd).

No, I didn't. I had a BIOS machine (dunno if that used the huge kernel)
that didn't need that.

How can I do that now?
Boot the install image, switch to the virtual console and chroot into
the installed OS?

That might work. Did you create an "emergency USB" during install? If
yes, boot that. If not, you may have no choice but to try booting the
install image and mounting the root drive in the same way as when the installer is installing.

From the kernel upgrade emails on the Slackware Security mailing list
these are the instructions to rebuild the initrd:

If you are using an initrd, you'll need to rebuild it.

For a 32-bit SMP machine, use this command (substitute the appropriate
kernel version if you are not running Slackware 15.0):
# /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.15.209-smp | bash

For a 64-bit machine, or a 32-bit uniprocessor machine, use this command
(substitute the appropriate kernel version if you are not running
Slackware 15.0):
# /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.15.209 | bash

Please note that "uniprocessor" has to do with the kernel you are running,
not with the CPU. Most systems should run the SMP kernel (if they can)
regardless of the number of cores the CPU has. If you aren't sure which
kernel you are running, run "uname -a". If you see SMP there, you are
running the SMP kernel and should use the 5.15.209-smp version when running
mkinitrd_command_generator. Note that this is only for 32-bit -- 64-bit
systems should always use 5.15.209 as the version.

Also, after rebuilding the initrd you'll need to rerun the lilo update
to make sure the boot code knows where to find the newly created
initrd.

This is also a good reason why, instead of replacing the existing
bootable kernel, the upgrade process should add a second (or third,
etc.) along side and an additional boot line in elilo. Then if the new
kernel fails, you can always reboot into the old, working one.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Am 04.07.26 um 22:54 schrieb Rich:

Also, after rebuilding the initrd you'll need to rerun the lilo update
to make sure the boot code knows where to find the newly created
initrd.

Thanks, that worked.
Does that need to run every time I update a kernel?

How did that work on another BIOS machine?
I did not generate initrd manually and it worked. Was that maybe the
huge kernel?

I've the huge kernel and the generic kernel installed.
elilo seems to have booted the generic kernel in the first attempt.

The elilo config now lists vmlinuz, which is a link to the huge kernel
in /boot.
In /boot/efi/EFI/Slackware there is vmlinuz file (not a link).

How can I find out which kernel I really booted?

This is also a good reason why, instead of replacing the existing
bootable kernel, the upgrade process should add a second (or third,
etc.) along side and an additional boot line in elilo. Then if the new kernel fails, you can always reboot into the old, working one.

Why isn't that triggered when installing the kernel modules package?
--
Gru|f
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Marco Moock <mm@dorfdsl.de> wrote:

Am 04.07.26 um 22:54 schrieb Rich:

Also, after rebuilding the initrd you'll need to rerun the lilo update
to make sure the boot code knows where to find the newly created
initrd.

Thanks, that worked.
Does that need to run every time I update a kernel?

If running the kernel that uses the initrd, yes. You have to update
the initrd every time you update the kernel and after rebuilding it,
then run the appropriate "bootloader" update (which depends upon which bootloader one is using).

How did that work on another BIOS machine?
I did not generate initrd manually and it worked. Was that maybe the
huge kernel?

If you didn't need to update an initrd, then most likely that other
machine was running the huge kernel.

I've the huge kernel and the generic kernel installed.
elilo seems to have booted the generic kernel in the first attempt.

Generic is the one that needs the initrd, because it has most of the
required drivers compiled as modules. The initrd is to provide a "root filesystem" loaded with just enough module files sufficient to allow
modpribe and insmod to load the necessary drivers to be able to
continue to boot up the kernel.

The elilo config now lists vmlinuz, which is a link to the huge kernel
in /boot.
In /boot/efi/EFI/Slackware there is vmlinuz file (not a link).

How can I find out which kernel I really booted?

If booting with UEFI, you likely booted using the /boot/efi/EFI/Slackware/vmlinuz file. So run off an md5sum or
sha256sum of that file, then compare to the same hashes of a known huge
and known generic kernel file. Whichever one matches is what's in the
EFI partition (which is what UEFI loads).

This is also a good reason why, instead of replacing the existing
bootable kernel, the upgrade process should add a second (or third,
etc.) along side and an additional boot line in elilo. Then if the new
kernel fails, you can always reboot into the old, working one.

Why isn't that triggered when installing the kernel modules package?

You'll have to ask Patrick that question.

But back in the days when I used to compile custom kernels for myself,
I often ended up with two or three or more lilo menu entries. One was
always the original slackware kernel, the others would be each custom
compiled one. Then if a custom compile failed to boot for some reason,
I could reboot and use one of the other working ones, or the original Slackware one to get going again, adjust whatever I'd omitted in the
new kernel's config, recompile, and try again.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Marco Moock <mm@dorfdsl.de> writes:

How can I find out which kernel I really booted?

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.18.32 root=/dev/sda2 ro amd_iommu=on iommu=pt rcu_nocbs=0-7
file /boot/vmlinuz-6.18.32

This is also a good reason why, instead of replacing the existing
bootable kernel, the upgrade process should add a second (or third,
etc.) along side and an additional boot line in elilo. Then if the new
kernel fails, you can always reboot into the old, working one.

"Working" and "Last Known Good" are always a smart and safe
option. Sooner or later, the new kernel won't work for some reason.

Why isn't that triggered when installing the kernel modules package?

There may have been a discussion about this on LQ wrt to Current but I
glossed over it because I use kernel.org kernels. Some people want it automatic, some didn't.
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Mon, 06 Jul 2026 14:39:25 -0400, jayjwa wrote:

cat /proc/cmdline

That will not always help, example, I'll grab a couple random machines


mx-in-07:~# cat /proc/cmdline
auto BOOT_IMAGE=Linux ro root=/dev/sda1



news:~# cat /proc/cmdline
auto BOOT_IMAGE=Linux ro root=801 nomodeset
^^^^^^^^^^^^ is a 32bit machine, but more than suffices for dnews



my desktop I'm using now
~$ cat /proc/cmdline
auto BOOT_IMAGE=Linux ro root=801 lockd.udpport=747 lockd.tcpport=747 raid=noautodetect ipv6.disable=1


for shits 'n giggles i have a rpi here used as streaming server
~# cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait


--- Synchronet 3.22a-Linux NewsLink 1.2