Update-grub does not update main grub entry

Hi folks,

after the last main update my main grub entry is incorrect. The main entry simply called „Manjaro“ is complaining about vmlinuz-5.6-x86_64 not found – well yeah, because apparently 5.7 was installed during the update.

Sorry, I’m not allowed to embed media, so here’s the text:

error: file '/boot/vmlinuz-5.6-x86_64' not found.
error: you need to load the kernel first.

When I manually edit the values in the main entry from 5.6 to 5.7, it boots fine. Also if I choose „Advanced options for Manjaro“ in the boot screen it offers me 5.7 kernel and an older kernel – both boot fine.

So I tried sudo update-grub as well as sudo grub-mkconfig -o /boot/grub/grub.cfg, which run smooth and detect correctly kernel 5.7:

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.7-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.7-x86_64.img
Found initrd fallback image: /boot/initramfs-5.7-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.4-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.4-x86_64.img
Found initrd fallback image: /boot/initramfs-5.4-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.7-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.7-x86_64.img
Found initrd fallback image: /boot/initramfs-5.7-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.4-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.4-x86_64.img
Found initrd fallback image: /boot/initramfs-5.4-x86_64-fallback.img
Found Ubuntu 20.04 LTS (20.04) on /dev/sda1
Found Windows 10 on /dev/sdb1
Found memtest86+ image: /boot/memtest86+/memtest.bin
done

But when I reboot, I’m back at square one: vmlinuz-5.6-x86_64 not found. So the big question is: What prevents the main entry from being updated?

Thank in advance.

Just so you know

cat /usr/bin/update-grub

#! /bin/sh
grub-mkconfig -o /boot/grub/grub.cfg

It is the same :slight_smile:

2 Likes
  • Go to advanced options in the grub menu
  • take one of the other options to boot (preferably 5.7)
  • update-grub again…

:innocent:

Nah, that didn’t work – and why should it? These are just different entry points into the same system. Would you please mind to explain what you expected to happen?

Have you check your /boot/grub/grub.cfg after running update-grub? Is it updated? Is the content what it should be?
Do you use grub-customizer or something that can tamper with grub?

1 Like

is an EOL kernel and doesn’t exist on your system any more:

So I expected the 5.7 kernel still to work and the update-grub there to fix the problem.

Go here for further help:

Start at #3: manjaro-chroot - auto

:sob:

But in the first post he stated that he already did what you propose. The thing is that even update-grub is executed successfuly, grub’s menu still uses kernel 5.6

Anyway @Stanzer now I have the doubt, what other entries are in the grub menu? Are there entries for kernel 5.7? Because you can have a custom entry with kernel 5.6 (although it’s true it should show up in the output in that case)

1 Like

can you return

uname -a
sudo parted -l 
sudo cat /etc/fstab
1 Like

But

  1. Anyway user was already using 5.7. He had to change manually the grub menu entry because kernel 5.6 is not there anymore. So if I understand you correctly you were proposing him to do something he already did.
  2. what kernel are you running doesn’t affect update-grub detection capabilities. Update-grub checks /boot/ to look for kernels. The current kernel is not a factor there.

Honest question, am I missing something here?

1 Like

There seems to be nothing suspicous here…

uname -a
Linux dk93 5.7.15-1-MANJARO #1 SMP PREEMPT Tue Aug 11 15:00:37 UTC 2020 x86_64 GNU/Linux
sudo parted -l
Model: ATA SanDisk SDSSDA12 (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  53,7GB  53,7GB  primary  ext4
 3      53,7GB  111GB   56,9GB  primary  ext4            boot
 2      111GB   120GB   9449MB  primary  linux-swap(v1)

Model: ATA SanDisk SDSSDA12 (scsi)
Disk /dev/sdb: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  119GB  119GB  primary  ntfs         boot
 2      119GB   119GB  877MB  primary  ntfs         msftres
 3      119GB   120GB  543MB  primary  ntfs         msftres

Model: ATA ST1000DM003-1CH1 (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  1000GB  1000GB                     msftdata

Model: ATA CT2000BX500SSD1 (scsi)
Disk /dev/sdd: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  2000GB  2000GB  primary
sudo cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=b2bf973e-58e6-48fd-a530-37c9cf16b57b /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

Aah, this gets me a step further. Looking into /boot/grub/grub.cfg the 5.6 entry seem to be generated by

### BEGIN /etc/grub.d/40_custom_proxy ###

After that 43_linux_proxy creates the advanced option entries with kernel 5.7 and 5.4, which are working.

So when I look into /etc/grub.d/40_custom_proxy it looks like this

#!/bin/sh
#THIS IS A GRUB PROXY SCRIPT
'/etc/grub.d/proxifiedScripts/custom' | /etc/grub.d/bin/grubcfg_proxy "-*
-#text
+'Manjaro Linux'~2af9dfaccd04624d71784f7c45037a65~
"

And lo and behold! /etc/grub.d/proxifiedScripts/custom contains this:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Manjaro Linux" --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-b2bf973e-58e6-48fd-a530-37c9cf16b57b' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos3'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos3' --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  b2bf973e-58e6-48fd-a530-37c9cf16b57b
	else
	  search --no-floppy --fs-uuid --set=root b2bf973e-58e6-48fd-a530-37c9cf16b57b
	fi
	linux	/boot/vmlinuz-5.6-x86_64 root=UUID=b2bf973e-58e6-48fd-a530-37c9cf16b57b rw  apparmor=1 security=apparmor udev.log_priority=3
	initrd	/boot/intel-ucode.img /boot/initramfs-5.6-x86_64.img
}

So now… Can I safely delete this file? If it’s gone, will there nevertheless be some script create a new main entry or is it possible that I break grub?

1 Like

The unmodified version of /etc/grub.d/40_custom is:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
1 Like
chmod a-x /etc/grub.d/40_custom_proxy
sudo update_grub

should do the trick as only executable files are used by grub.

:innocent:

P.S. Yes, you can also delete the file… (up to you)

1 Like

Just for your reference, this is the content of my unmodified /etc/grub.d/:

-rwxr-xr-x 1 root root 8,7K 31. 7. 09:18 00_header*
-rwxr-xr-x 1 root root  13K 31. 7. 09:18 10_linux*
-rwxr-xr-x 1 root root  14K 31. 7. 09:18 20_linux_xen*
-rwxr-xr-x 1 root root  12K 31. 7. 09:18 30_os-prober*
-rwxr-xr-x 1 root root 1,4K 31. 7. 09:18 30_uefi-firmware*
-rwxr-xr-x 1 root root  214 31. 7. 09:18 40_custom*
-rwxr-xr-x 1 root root  216 31. 7. 09:18 41_custom*
-rwxr-xr-x 1 root root 1,2K 16. 5. 14:45 60_memtest86+*
-rw-r--r-- 1 root root  483 31. 7. 09:18 README

You better check if there is something odd in your folder. Just in case for the future

PS: If you consider this as solved, please mark the thread accordingly.

1 Like

Well, yeah, this is kind of solved for me. My grub menu is missing the main entry now, since I disabled /etc/grub.d/40_custom, but the cursor line is at Advanced Options and boots the first entry there automatically, which is kernel 5.7 and this is fine by me.

Now I’m just curious: Would it be possible to replace all files in /etc/grub.d/ with the default ones? Where could I get those files? From an actual Manjaro image, I guess?

Rename the folder sudo mv /etc/grub.d /etc/grub.d.bak (just in case) and reinstall grub package: sudo pacman -S grub

2 Likes

And this is where the party started. Yeah, that did the trick. The reinstall of grub moaned about inaccessible /etc/grub.d and just recreated all necessary files. Big thanks man!

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.