Join Log in
Score:0
cdahms avatar Ubuntu

Ubuntu 18.04 is attempting to load the wrong vmlinuz file, how to fix?

cn flag
cdahms

I have a machine with a 2 TB M.2 HD dual booted with Ubuntu 20.04 and 18.04 (still need 18.04 for legacy reasons, please don't ask for the details :).

I just did an update to 20.04 and now 18.04 won't boot without choosing a special option. Here is my usual grub screen upon boot:

enter image description here

If I choose Ubuntu 18.04 I get this:

enter image description here

If instead at the main boot menu I choose Advanced options for Ubutnu 18.04.5 LTS (18.04) (on /dev/nvme0n1p2) I get this:

enter image description here

If I choose any of these non-recovery mode options everything boots and works normally.

What I don't understand is why is the usual boot option looking for kernel version ending in 70? It's not there anymore! How can I make it look for one of the kernel versions that is there?

I did some more poking around, when I ls the contents of /boot I get:

$ ls -l
total 169176
-rw-r--r-- 1 root root   237757 Apr 16 07:44 config-5.4.0-73-generic
-rw-r--r-- 1 root root   237757 Jul 13 10:52 config-5.4.0-80-generic
-rw-r--r-- 1 root root   237757 Jul 23 05:56 config-5.4.0-81-generic
drwx------ 3 root root     4096 Dec 31  1969 efi
drwxr-xr-x 6 root root     4096 Aug 19 11:17 grub
-rw-r--r-- 1 root root 43261536 Jul 22 09:33 initrd.img-5.4.0-73-generic
-rw-r--r-- 1 root root 43267722 Jul 23 10:31 initrd.img-5.4.0-80-generic
-rw-r--r-- 1 root root 43266831 Aug 17 11:26 initrd.img-5.4.0-81-generic
-rw-r--r-- 1 root root   182704 Jan 28  2016 memtest86+.bin
-rw-r--r-- 1 root root   184380 Jan 28  2016 memtest86+.elf
-rw-r--r-- 1 root root   184840 Jan 28  2016 memtest86+_multiboot.bin
-rw------- 1 root root  4586616 Apr 16 07:44 System.map-5.4.0-73-generic
-rw------- 1 root root  4587397 Jul 13 10:52 System.map-5.4.0-80-generic
-rw------- 1 root root  4587874 Jul 23 05:56 System.map-5.4.0-81-generic
-rw------- 1 root root  9449728 Apr 16 07:44 vmlinuz-5.4.0-73-generic
-rw------- 1 root root  9453824 Jul 13 11:28 vmlinuz-5.4.0-80-generic
-rw------- 1 root root  9457920 Jul 23 05:59 vmlinuz-5.4.0-81-generic

So once again vmlinuz ending in 73, 80, and 81 are present but not the 70 that grub seems to be looking for. I also checked /boot/grub/grub.conf and it also has entries for 73, 80, and 81 but not 70! Where is grub getting 70 from?

Based on some other posts I also tried pressing c from the grub main menu to do a terminal session, I found the following information but I'm not sure what do to, sorry this pic is a bit blurry:

enter image description here

I'm not sure how to enter a command here to resolve this if that is possible.

One more thing I should mention is after doing the advanced boot option to get back into Ubuntu 18.04 I tried:

sudo apt-get update
sudo apt-get upgrade

and

sudo update-grub

hoping that these would resolve the concern but they did not. Suggestions ??

-- Response to @heynnema --

here is my terminal output from your suggested command:

$ sudo update-initramfs -c -k 5.4.0-81-generic
[sudo] password for cdahms: 
update-initramfs: Generating /boot/initrd.img-5.4.0-81-generic
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169

After reboot result is same as before (same error with usual 18.04 boot menu choice, still works with advanced options choice)

-- 2nd Response to @heynnema --

fdisk:

$ sudo fdisk -l
Disk /dev/loop0: 32.3 MiB, 33865728 bytes, 66144 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 704 KiB, 720896 bytes, 1408 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop2: 243.9 MiB, 255762432 bytes, 499536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop3: 276 KiB, 282624 bytes, 552 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop4: 2.5 MiB, 2621440 bytes, 5120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop5: 32.3 MiB, 33853440 bytes, 66120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop6: 2.4 MiB, 2555904 bytes, 4992 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop7: 61.7 MiB, 64729088 bytes, 126424 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/nvme0n1: 1.9 TiB, 2048408248320 bytes, 4000797360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 63850E58-ACD2-4B55-B5D5-29E46C830D03

Device              Start        End    Sectors   Size Type
/dev/nvme0n1p1       2048    1050623    1048576   512M EFI System
/dev/nvme0n1p2    1050624 2029461901 2028411278 967.2G Linux filesystem
/dev/nvme0n1p3 2029463552 4000796671 1971333120   940G Linux filesystem




Disk /dev/loop8: 65.1 MiB, 68259840 bytes, 133320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop9: 548 KiB, 561152 bytes, 1096 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop10: 2.5 MiB, 2605056 bytes, 5088 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop11: 219 MiB, 229638144 bytes, 448512 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop12: 2.2 MiB, 2342912 bytes, 4576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop13: 219 MiB, 229629952 bytes, 448496 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop14: 64.8 MiB, 67915776 bytes, 132648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop15: 548 KiB, 561152 bytes, 1096 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop16: 55.4 MiB, 58130432 bytes, 113536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop17: 55.5 MiB, 58134528 bytes, 113544 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop18: 61.8 MiB, 64770048 bytes, 126504 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

blkid:

$ sudo blkid
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/nvme0n1: PTUUID="63850e58-acd2-4b55-b5d5-29e46c830d03" PTTYPE="gpt"
/dev/nvme0n1p1: UUID="B97B-4975" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="b1d40bc5-1bc0-490b-92d4-256bad74c673"
/dev/nvme0n1p2: UUID="cdc92bbb-f4d8-4a31-9cbf-5215632adb49" TYPE="ext4" PARTUUID="3079da12-a09d-4a1a-a21a-61af34810c23"
/dev/nvme0n1p3: UUID="93b02138-35e3-4446-a2b9-e16cf6c22786" TYPE="ext4" PARTUUID="51df7e8c-fa57-4275-9348-27902134ee6a"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/loop11: TYPE="squashfs"
/dev/loop12: TYPE="squashfs"
/dev/loop13: TYPE="squashfs"
/dev/loop14: TYPE="squashfs"
/dev/loop15: TYPE="squashfs"
/dev/loop16: TYPE="squashfs"
/dev/loop17: TYPE="squashfs"
/dev/loop18: TYPE="squashfs"

Based on one of the answers to this post How can I detect whether my disk is using GPT or MBR from a terminal? I did:

$ sudo ls
 aws                  IntelliScan_Haze_Class_005   pycharm
 awscliv2.zip             IntelliScan_Images_005       rotated_IntelliScan_Images_007
 Desktop              IntelliScan_Images_006       snap
 Documents            IntelliScan_Images_007       temp
 Downloads            minicom.log          temp2.txt
 Downloads2           Music            Templates
 Dropbox             'Nala devices'        temp.txt
 eclipse              Nala_PVT3_2mm_lens_haze      Videos
 examples.desktop         Pictures            'Volumetric Dummy Devices.txt'
 IntelliScan_Haze_Class_001   Public               workspace-apps
 IntelliScan_Haze_Class_002   PVT3_haze            workspace-prod
 IntelliScan_Haze_Class_003   PVT4
 IntelliScan_Haze_Class_004  'PVT4 IMEIs.txt'

then:

$ sudo fdisk -l | grep -B 5 Disklabel

Disk /dev/nvme0n1: 1.9 TiB, 2048408248320 bytes, 4000797360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

So it seems I'm using GPT formatting

-- 3rd Response to @heynnema --

Yes I did use Grub Customizer, did that jack things up? I've heard it can do that but I've never had a problem before. Here is my ls -al /etc/grub.d:

$ ls -al /etc/grub.d
total 100
drwxr-xr-x   5 root root  4096 Aug 19 11:00 .
drwxr-xr-x 140 root root 12288 Aug 19 10:32 ..
-rwxr-xr-x   1 root root 10046 Jul 30  2020 00_header
-rwxr-xr-x   1 root root  6258 Jul 20  2020 05_debian_theme
-rwxr-xr-x   1 root root   914 May 23 22:55 10_linux_proxy
-rwxr-xr-x   1 root root   221 May 23 22:55 40_custom_proxy
-rwxr-xr-x   1 root root   914 May 23 22:55 41_linux_proxy
-rwxr-xr-x   1 root root 11298 Jul 30  2020 44_linux_xen
-rwxr-xr-x   1 root root  1992 Jan 28  2016 45_memtest86+
-rwxr-xr-x   1 root root  1539 May 23 22:55 46_os-prober_proxy
-rwxr-xr-x   1 root root  1418 Jul 30  2020 47_uefi-firmware
-rwxr-xr-x   1 root root   285 May 23 22:55 48_custom_proxy
-rwxr-xr-x   1 root root   216 Jul 30  2020 49_custom
drwxr-xr-x   4 root root  4096 May 23 22:55 backup
drwxr-xr-x   2 root root  4096 May 23 22:55 bin
drwxr-xr-x   2 root root  4096 May 23 22:55 proxifiedScripts
-rw-r--r--   1 root root   483 Jul 30  2020 README
-rw-r--r--   1 root root   272 May 23 22:55 .script_sources.txt

-- 4th Response to @heynnema -- grep -i 5.4.0-70 /etc/grub.d/*:

$ grep -i 5.4.0-70 /etc/grub.d/*
/etc/grub.d/10_linux_proxy:-'SUBMENU' as 'Advanced options for Ubuntu'{-'Advanced options for Ubuntu'/*, -'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-73-generic'~408f07b7e0dd8d620374c5b681855861~, -'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-73-generic (recovery mode)'~003de087994ae2af14e29d21bf9905b2~, -'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-72-generic'~c5a297cf454d7588afd791e38e600c79~, -'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-72-generic (recovery mode)'~fdd81b462724bdc5fe27e5506ee615f4~, -'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-70-generic'~6f6c570f06cb15f97ea26de817f5f40a~, -'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-70-generic (recovery mode)'~6b0d22eb9c2641ea1add550c2162c631~}
/etc/grub.d/41_linux_proxy:+'SUBMENU' as 'Advanced options for Ubuntu'{+'Advanced options for Ubuntu'/*, +'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-73-generic'~408f07b7e0dd8d620374c5b681855861~, +'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-73-generic (recovery mode)'~003de087994ae2af14e29d21bf9905b2~, +'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-72-generic'~c5a297cf454d7588afd791e38e600c79~, +'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-72-generic (recovery mode)'~fdd81b462724bdc5fe27e5506ee615f4~, +'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-70-generic'~6f6c570f06cb15f97ea26de817f5f40a~, +'Advanced options for Ubuntu'/'Ubuntu, with Linux 5.4.0-70-generic (recovery mode)'~6b0d22eb9c2641ea1add550c2162c631~}
grep: /etc/grub.d/backup: Is a directory
grep: /etc/grub.d/bin: Is a directory
grep: /etc/grub.d/proxifiedScripts: Is a directory

It seems 5.4.0-70 is in grub.d!! Perhaps this is the problem?

cat /etc/fstab:

$ 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>
# / was on /dev/nvme0n1p2 during installation
UUID=cdc92bbb-f4d8-4a31-9cbf-5215632adb49 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=B97B-4975  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0

-- 5th Response to @heynnema --

Here is my Grub Customizer edit screen for the regular Ubuntu 18.04 menu item:

enter image description here

I don't understand this b/c -73 is here not -70 ?!?!

-- 6th Response to @heynnema --

Main Grub Customizer screen:

enter image description here

203
1 + 15
heynnema avatar
ru flag
heynnema
Is there anything shared between 20.04 and 18.04? You're missing some symlinks in /boot. Did you delete them? It's possible that your ramdisk file needs to be rebuilt. Boot to 18.04, open `terminal`, and type `sudo update-initramfs -c -k 5.4.0-81-generic`, then `reboot`. Report back.
0
Reply
cdahms avatar
cn flag
cdahms
To my knowledge nothing is shared and I'm sure I did not delete anything in /boot. I'll try your command.
0
Reply
cdahms avatar
cn flag
cdahms
updated question with terminal output for your suggested command, no change
0
Reply
heynnema avatar
ru flag
heynnema
What's on hd0? Are both 20.04 and 18.04 on hd1? Are both drives internal drives?
0
Reply
cdahms avatar
cn flag
cdahms
When I installed I installed Ubuntu 20.04 first with mostly default install options, then I installed Ubuntu 18.04 with mostly default options, choosing to split the HD about 50/50 between them. There is only one HD in the machine, the 2 TB M.2. I'm not sure what hd0 is, I would suppose it's the boot partition created by the Ubuntu installer. The one HD is the only drive present, there are no external drives.
0
Reply
heynnema avatar
ru flag
heynnema
Edit your question and show me `sudo fdisk -l` and `sudo blkid`. Is your 2 TB formatted GPT or MBR?
0
Reply
cdahms avatar
cn flag
cdahms
Updated question with fdisk and blkid output, I'm using GPT formatting, also edited question for this
0
Reply
heynnema avatar
ru flag
heynnema
Did you use `GRUB Customizer`? Show me `ls -al /etc/grub.d`.
0
Reply
heynnema avatar
ru flag
heynnema
Show me `grep -i 5.4.0-70 /etc/grub.d/*` and `cat /etc/fstab`.
0
Reply
heynnema avatar
ru flag
heynnema
Do you have access to a Ubuntu Live DVD/USB?
0
Reply
cdahms avatar
cn flag
cdahms
just added ls -al /etc/grub.d to question
0
Reply
cdahms avatar
cn flag
cdahms
just added grep -i 5.4.0-70 /etc/grub.d/* and cat /etc/fstab
0
Reply
cdahms avatar
cn flag
cdahms
I still have the thumb drives I installed Ubuntu 20.04 and Ubuntu 18.04 from, I made them via usual download and thumb drive prep process as instructed on the Ubuntu website.
0
Reply
heynnema avatar
ru flag
heynnema
We found the problem. `GRUB Customizer` probably did the deed. Bring it up and check for a custom entry for -70.
0
Reply
nobody avatar
gh flag
nobody
grub costumizer is a pain. `mkdir $HOME/grub-bak` Move any files with proxy in name to this created folder. Also mv folder `bin` and `backup` and file `proxifiedScripts` from `/etc/grub.d/`
0
Reply
Score:1
heynnema avatar Ubuntu
ru flag
heynnema

The default GRUB boot was looking for kernel vmlinuz-5.4.0-70-generic which doesn't exist.

The Additional Options boot was correctly showing kernels -73, -80, and -81.

GRUB Customizer was used to tailor the GRUB menu, and it screwed up. Review the GRUB Customizer menus looking for a custom entry for -70, or for a way to revert back to the standard GRUB menus.

0 + 9
cdahms avatar
cn flag
cdahms
Just posted my Grub Customizer screen for the Ubuntu 18.04 menu entry in the question, there is an entry for -73 but not -70 so I'm still not sure where the -70 is comming from. I'll accept your answer though since at this point I can just manually change it to -81 in those 2 grub.d files
0
Reply
heynnema avatar
ru flag
heynnema
@cdahms If you look on the screen directly behind what you just posted, does -70 show up there?
0
Reply
heynnema avatar
ru flag
heynnema
@cdahms In `GRUB Customizer`, is there a choice to reset the GRUB menus back to default?
0
Reply
cdahms avatar
cn flag
cdahms
There is a "Revert" button but that only reverts the list to the default order. I'll post the Grub Customizer screenshot without the pop-up
0
Reply
cdahms avatar
cn flag
cdahms
I'll keep poking around in Grub Customizer and researching this, bottom line it's a Grub Customizer bug
0
Reply
heynnema avatar
ru flag
heynnema
@cdahms Yes. Please keep me posted.
0
Reply
heynnema avatar
ru flag
heynnema
@cdahms Status please...
0
Reply
cdahms avatar
cn flag
cdahms
still working on it, using advanced options menu to boot for now
0
Reply
heynnema avatar
ru flag
heynnema
@cdahms I would try the REVERT in GRUB Customizer.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.