[SOLVED] Startx failed after system upgrade - Elilo hits the wrong kernel

henca · 04-27-2023, 01:15 PM

Quote:

Originally Posted by LuckyCyborg

Let's see the bright side: you are lucky that you do NOT used a HUGE kernel, because in this case you will have got a glorious kernel panic and you will have been fully locked away from your computer.

Why do you think that would happen? My guess is that if he would have used a huge kernel instead it would boot as good as the generic kernel but with the difference that some more functionality would have been compiled into the kernel and not depending on non-existent modules.

One of those things compiled into the huge kernel is support for vfat file systems, so it would have been slightly easier to fix the bootloader.

Even if the huge kernel for some reason would give a kernel panic the easiest solution would be no different from the current situation. Boot from installation media or some rescue media, mount partitions, run bootloader.

regards Henrik

Loomx · 04-27-2023, 02:00 PM

To go all the way back to the initial problem...

Quote:

Originally Posted by jazzi

...

So I run `mount /boot/efi`
...
And the whole /boot/efi/EFI directory is missing.

I have been caught with this too when I upgraded with the EFI partition unmounted.

My suggestion would be that the vfat module be compiled into the generic kernel. The vfat module is very mature and stable, and we pretty much know that every UEFI system is going to have a FAT partition so it makes sense to have it as part of the baseline kernel config.

Petri Kaukasoina · 04-27-2023, 03:27 PM

Quote:

Originally Posted by Loomx

I have been caught with this too when I upgraded with the EFI partition unmounted.

Why did you have it unmounted? Wasn't it in /etc/fstab after installation?

Quote:

My suggestion would be that the vfat module be compiled into the generic kernel.

Just add it in initrd, like the root file system.

marav · 04-27-2023, 03:43 PM

Quote:

Originally Posted by Petri Kaukasoina

Why did you have it unmounted? Wasn't it in /etc/fstab after installation?

because it doesn't need to

and sometimes it causes troubles to have it permanently mounted

https://www.linuxquestions.org/quest...2/#post6285738

https://www.linuxquestions.org/quest...3/#post6276444

colorpurple21859 · 04-27-2023, 03:46 PM

I think the unmounted efi partition was a result of booting with the old generic kernel.

_peter · 04-27-2023, 04:05 PM

jazzi, on every kernel upgrade using slackpkg upgrade-all I often make the mistake of not running the mkinitrd properly in addition to mounting the efi vfat partition and that eliloconfig which is itself a copy for dummies as others have said, fairly.

before you can do eliloconfig, steps to chroot, from the slackware64-15.0 install iso.

Code:

mkdir /AAA2
mount /dev/sda1 /AAA2        < -- check you linux root partition drive #

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

chroot /AAA /bin/bash

mount /dev/sda2 /boot/efi    < -- your efi fat partition, check the drive # and the path

mkinitrd is presently : < -- read the path /lib/modules to check the kernel modules availability

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.15.94

https://docs.slackware.com/howtos:sl...edia#chrooting

Loomx · 04-27-2023, 11:26 PM

Quote:

Originally Posted by Petri Kaukasoina

Why did you have it unmounted? Wasn't it in /etc/fstab after installation?

Just add it in initrd, like the root file system.

I can't remember why I had it unmounted, but there had been some reason.
Anyway, even before rebooting, the upgrade of the kernel-modules package meant that I couldn't mount it to copy files to it.

I guess I could have rebooted, which would have used the existing kernel and initrd that was on the EFI partition... I didn't think of that. Instead I downloaded the previous kernel-modules package and reinstalled it, mounted the EFI partition, then removed the package.

The UEFI spec says that (at least) FAT partitions need to be readable by the EFI firmware, so that's why I was suggesting that the vfat module be built into the generic kernel. I can't think of any downside to doing this, and it would have saved me (more than once, I am embarrassed to say...)

Petri Kaukasoina · 04-28-2023, 12:09 AM

Quote:

Originally Posted by Loomx

the upgrade of the kernel-modules package meant that I couldn't mount it to copy files to it.

This is the problem. Kernel and modules should be blacklisted by default for slackpkg. The modules of the running kernel should not be removed during the kernel upgrade. Slackpkg pulls the rug out from under the running kernel by removing its modules. The old kernel should be allowed to load whatever modules it needs as long as it still runs. Only after the new kernel has been booted up, should the old modules be removed from the disk.

In other words. The problem is that after removing modules, something does not work any longer. It's not the right solution to build everything possibly needed in the kernel to make it work without modules. The solution is to keep the modules available.

Didier Spaier · 04-28-2023, 12:28 AM

(useless post, deleted)

jazzi · 04-28-2023, 07:27 AM

Quote:

Originally Posted by _peter

jazzi, on every kernel upgrade using slackpkg upgrade-all I often make the mistake of not running the mkinitrd properly in addition to mounting the efi vfat partition and that eliloconfig which is itself a copy for dummies as others have said, fairly.

Peter, it works, thank you.

As Petri Kaukasoina suggested, I also blacklist the kernel and module.

I found the kernel used now is huge, put another menu entry that generated by mkinitrd_command_generator.sh for generic kernel to elilo.conf, then reboot but Elilo doesn't show up the menu, should I run eliloconf in advance to make the new elilo.conf work? hereby is my new elilo.conf

Code:

chooser=simple
delay=1
timeout=1
default=vmlinuz
#
image=vmlinuz
        label=vmlinuz
        initrd=initrd.gz
        read-only
        append="root=/dev/nvme0n1p2 vga=normal ro"
#
# Linux bootable partition config begins
# initrd created with 'mkinitrd -c -k 5.15.94 -f ext4 -r /dev/nvme0n1p2 -m usb-storage:xhci-hcd:xhci-pci:ohci-pci:ehci-pci: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 -u -o /boot/initrd.gz'
image=vmlinuz-generic
	initrd=initrd.gz
	label=generic
	read-only
	append="root=/dev/nvme0n1p2 vga=normal ro"

elcore · 04-28-2023, 08:30 AM

@jazzi

It works now? Better make backups.
Or, you will sooner or later find that you should've made them long time ago.
What happened to me (longtimeagoingalaxyfarwaway) was I removed a symlink which everything including "ln" depended on so then I couldn't create another symlink.
Now, I have offline double system for each system I install/use so if that thing happens again I just move back the missing stuff from another system.

colorpurple21859 · 04-28-2023, 08:36 AM

Quote:

then reboot but Elilo doesn't show up the menu,

Press the tab key when you first see elilo boot prompt.

Petri Kaukasoina · 04-28-2023, 08:38 AM

Quote:

Originally Posted by elcore

I removed a symlink which everything including "ln" depended on so then I couldn't create another symlink.

For that situation there is /sbin/sln

Code:

$ file /sbin/sln 
/sbin/sln: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), static-pie linked, not stripped
$ ldd /sbin/sln 
        statically linked

That was in -current. In 15.0 the output differs a little:

Code:

$ file /sbin/sln 
/sbin/sln: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, not stripped
$ ldd /sbin/sln 
        not a dynamic executable

elcore · 04-28-2023, 08:56 AM

Quote:

Originally Posted by Petri Kaukasoina

For that situation there is /sbin/sln

Cheers, very helpful. Not all systems do this, but yeah, very useful to have it.
Still plenty of 'shoot your own foot off" situations though, I had to work around one in particular: FAT
Because there's no tool to make it support symlinks, now I have to tar all the backup stuff I put on FAT drives.
And some drives only support FAT16 or FAT32 and nothing else, so I guess this is where backup archiving is the one and only workaround.

LuckyCyborg · 04-28-2023, 09:04 AM

Quote:

Originally Posted by elcore

It works now? Better make backups.

Yep. Never is too soon for making a full backup.