[solved]LM19 can't get new kernel into boot menu

[oldgranola]

Hello,
I have a dual boot LM system with LM17.3 and LM19, still testing LM19 (amd apu issues etc). I see both in the boot menu. However, I can't get newest kernel for LM19 4.15.0-29 to show in the boot menu, only will boot to 4.15.0-20. For LM17.3 it shows option for older kernels and recovery mode so why not for LM17. Plus I'd like to see LM19 on top in the boot menu. Yes I've run update grub after kernel installation. So far my reading here and elsewhere has not quite gotten to exactly this issue for me, sure its somewhere. Thanks for any help.
udate-grub gives

Code: Select all

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-29-generic
Found initrd image: /boot/initrd.img-4.15.0-29-generic
Found linux image: /boot/vmlinuz-4.15.0-23-generic
Found initrd image: /boot/initrd.img-4.15.0-23-generic
Found linux image: /boot/vmlinuz-4.15.0-20-generic
Found initrd image: /boot/initrd.img-4.15.0-20-generic
Found Linux Mint 17.3 Rosa (17.3) on /dev/sda2
Adding boot menu entry for EFI firmware configuration
done

ls -l boot from root gives

Code: Select all

total 211296
-rw-r--r-- 1 root root  1536934 Apr 23 21:56 abi-4.15.0-20-generic
-rw-r--r-- 1 root root  1537050 May 23 09:54 abi-4.15.0-23-generic
-rw-r--r-- 1 root root  1537161 Jul 17 01:57 abi-4.15.0-29-generic
-rw-r--r-- 1 root root   216807 Apr 23 21:56 config-4.15.0-20-generic
-rw-r--r-- 1 root root   216807 May 23 09:54 config-4.15.0-23-generic
-rw-r--r-- 1 root root   216807 Jul 17 01:57 config-4.15.0-29-generic
drwxr-xr-x 5 root root     4096 Jul 21 10:45 grub
-rw-r--r-- 1 root root 57787793 Jul  8 09:36 initrd.img-4.15.0-20-generic
-rw-r--r-- 1 root root 57919147 Jul 17 21:17 initrd.img-4.15.0-23-generic
-rw-r--r-- 1 root root 57926680 Jul 21 09:07 initrd.img-4.15.0-29-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-r--r-- 1 root root        0 Apr 23 21:56 retpoline-4.15.0-20-generic
-rw-r--r-- 1 root root        0 May 23 09:54 retpoline-4.15.0-23-generic
-rw-r--r-- 1 root root        0 Jul 17 01:57 retpoline-4.15.0-29-generic
-rw------- 1 root root  4038188 Apr 23 21:56 System.map-4.15.0-20-generic
-rw------- 1 root root  4039393 May 23 09:54 System.map-4.15.0-23-generic
-rw------- 1 root root  4040379 Jul 17 01:57 System.map-4.15.0-29-generic
-rw-r--r-- 1 root root  8249080 Jun 26 08:36 vmlinuz-4.15.0-20-generic
-rw------- 1 root root  8257272 May 23 10:49 vmlinuz-4.15.0-23-generic
-rw------- 1 root root  8257272 Jul 17 08:26 vmlinuz-4.15.0-29-generic

and the uncommented# contents of the /etc/default/grub are

Code: Select all

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

[all41]

This sounds like the same issue on my dual Mint system:
viewtopic.php?f=47&t=273782

[oldgranola]

Thanks all41. Took me a bit to understand to reboot into the dominant OS and update-grub from there.. Now I can boot new LM kernel

Code: Select all

$uname -r 
4.15.0-29-generic

So now how do I make LM19 'dominant' so when booted update-grub works from there and that it is on top of the bootup menu?
fdkis -l gives

Code: Select all

Device         Start       End   Sectors   Size Type
/dev/sda1       2048   1050623   1048576   512M EFI System
/dev/sda2    1050624 504639762 503589139 240.1G Linux filesystem
/dev/sda3  970078208 976771071   6692864   3.2G Linux swap
/dev/sda4  504641536 504643583      2048     1M BIOS boot
/dev/sda5  504643584 970078207 465434624   222G Linux filesystem

sda2 is LM17.3, sda5 is LM19

[all41]

Thanks all41. Took me a bit to understand to reboot into the dominant OS.. Now

Code: Select all

$uname -r 
4.15.0-29-generic

So now how do I make LM19 'dominant'?

I will let others more familiar with grub answer here because I 'stumbled' my way through this with difficulties.
This system is a workstation. The two Mint 19 systems involved are on a ssd drive, there is also Mint 17.3
on a another hdd, the original oem Win 7 on another, plus a storage drive. During the process I had disconnected all but the sdd. When I got the ssd grub working correctly I reconnected the other drives---
lo and behold, the bios boot order had changed and there was yet another grub to contend with.

[gm10]

So now how do I make LM19 'dominant' so when booted update-grub works from there and that it is on top of the bootup menu?

From within LM19 run:

Code: Select all

sudo grub-install /dev/sda
sudo update-grub

The next time you install another Mint or other Ubuntu-based distro run the installer with the -b/--no-bootloader option to prevent this dual grub situation in the first place.

[oldgranola]

Thanks all. [solved] I think..

[all41]

Thanks gm10.
I scrolled my terminal history and found that sometime during my fiasco I had entered those lines, except in my case it was sdb. At one point I had no grub at all (not even by holding down the Shift key at oem splash)--it was booting directly into sdb1 (MATE 19 /). Cinnamon 19 / is sdb7. It was late, but eventually things got back to normal.

The next time you install another Mint or other Ubuntu-based distro run the installer with the -b/--no-bootloader option

Could you provide an example cl using this option?

[gm10]

Thanks gm10.
I scrolled my terminal history and found that sometime during my fiasco I had entered those lines, except in my case it was sdb. At one point I had no grub at all (not even by holding down the Shift key at oem splash)--it was booting directly into sdb1 (MATE 19 /). Cinnamon 19 / is sdb7. It was late, but eventually things got back to normal.

You always have GRUB if you're managing to boot the system. Remember for update-grub to find all your installations you may need to mount their boot/root partitions while you run the command.

Could you provide an example cl using this option?

Code: Select all

ubiquity -b

[all41]

Good to know, thanks
Both Mate and Cinnamon came to the ssd via dd from individual hdd installs,
thus creating my puzzle. On the up note--I came out wiser