Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] Kernels not being added to grub, grub too risky to update (Read 460 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[SOLVED] Kernels not being added to grub, grub too risky to update

I recently had to reinstall after an installation of 2 years broke. I ended up having to do a fresh reinstall that took 8 hours (due to having to additionally redownload the contents of /home from a backup for another reason) to get back to operation.

The issue I had was that kernel versions being updated through pacman would not go through into grub, eventually I ran: grub-mkconfig -o /boot/grub/grub.cfg  , Which caused my system to fail booting at the "Welcome to GRUB" screen and go into UEFI settings screen (AKA BIOS screen).

I have reinstalled my system and have encountered the same issue now. Downloading and installing newer kernels does not result in them being added to grub, and I fear I may accidentally lock myself out again. How do I go about making grub workable?

On running lsblk -f, my output is :
~ % lsblk -f
NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                        
└─sda1
     ext4   1.0   HOME2 aca61459-0ca8-44fa-8afa-48989e53235c  545.5G    65% /storage/home2
sr0                                                                        
nvme1n1
                                                                           
├─nvme1n1p1
│    vfat   FAT32       0742-B23C                             510.7M     0% /boot/efi
├─nvme1n1p2
│    ext4   1.0         aec65ec4-3a10-4e33-9979-742a09b7c886   21.5G    48% /
└─nvme1n1p3
     ext4   1.0         cf25500a-d2fb-4b76-a5c7-f4b8d1715748  333.1G    14% /home
nvme0n1
     ext4   1.0         3b7d89a8-600c-4831-96c1-9feee8f60118  382.9G    53% /storage/M2-1TB

This to me looks odd, but I can't say for certain that /boot/efi being 0% use is a problem or not. It does seem to me that grub bootloader only got set up at install stage, but I can't get it working post-install.

Any help here is appreciated!

Re: Kernels not being added to grub, grub too risky to update

Reply #2 –
Yep, I resolved this the other day (will mark) and forgot to post on the forum.
I had a look at https://forum.artixlinux.org/index.php/topic,5187 and took note.

Will probably keep it in mind that update-grub and grub-install are good to run after a grub update, though it would be good if automated.

Will be updating my laptop some time soon as well, so it's probably well worth remembering. If I somehow forget, could always keep it simple and chroot to do it instead of full reinstall.

Is the newest ISO a version behind in grub? I don't quite remember.

Re: Kernels not being added to grub, grub too risky to update

Reply #3 –
In one thread on the subject someone suggested writing your own simple script with the correct grub install command to make this easier in future, or at least make a note of what you used. The problem with automating grub install is that it would be difficult on systems with more than one drive and OS for anyone except the user to know what it should do, and cover all possibilities with BIOS settings and whatever. I think Grub breaking changes are rare though, hence it being in Arch News. Unlike some other distros, update-grub is not run automatically because it's rarely needed and makes updates faster.

Re: Kernels not being added to grub, grub too risky to update

Reply #4 –
You're right, but at the same time for your run of the mill system you can detect if it's "typically" installed, then the oneliner grub installer script will work fine. :-)
 

Re: [SOLVED] Kernels not being added to grub, grub too risky to update

Reply #5 –
Yes, it was unclear above but I wasn't really counting writing your own script as automation because you would have to write and run it yourself, I meant that's why the Grub package updates don't try to do everything automatically.  Possibly if grub left a record of exactly how it was installed and the UUID of the OS running the command in the stub so only the relevant grub in the correct partition would update it again in the same way as before it could be done, but I expect there still might be complications, if it was that easy you'd think it would have been done already.  :D