[SOLVED] Startx failed after system upgrade - Elilo hits the wrong kernel
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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
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...)
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.
Last edited by Petri Kaukasoina; 04-28-2023 at 12:32 AM.
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
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.