Ubuntu 20.04.6 LTS apt problems - how to upgrade f/w?
Bo Berglund
bo.berglund at gmail.com
Wed Nov 27 15:17:48 UTC 2024
On Wed, 27 Nov 2024 12:47:08 +0100, Nils Kassube via ubuntu-users
<ubuntu-users at lists.ubuntu.com> wrote:
>On 27.11.24 Bo Berglund wrote:
>> menuentry 'Ubuntu 20.04.3 LTS (20.04) (on /dev/nvme0n1p5)'
>
>So you also have an older Ubuntu version on the system.
It seems like there is, I remember that when I started this Linux device a
number of years back it was migrated from an older machine that also had a
desktop version on the side, which I only used a few times.
But its hardware was really old and performance was low so I bought this Lenovo
minitower instead and moved the partitions over from the old to the new hard
drive.
I used to have the desktop Ubuntu in order to use GParted for disk management,
but later I was adviced here of a standalone GParted that could boot off of a
USB stick, so I added that to a Ventoy USB which can boot up GParted without
running anything on the actual hard drive. But I also added it as a separate
item to the hard drive so it is visible on the grub menu if one boots the PC
with a display and keyboard attached. Then n o Ventoy USB is needed for disk
maintenance.
>Could it be that you actually boot from the grub menu of 20.04.3?
>I would suggest to mount /dev/nvme0n1p5 and check if there is a grub
>entry for your current kernel there.
I have mounted the partition now and it sure looks like a linux system.
If I go into it I find:
$ ll boot/grub/grub.cfg
-r--r--r-- 1 root root 15508 2021-10-31 11:24 boot/grub/grub.cfg
$ ll etc/default/grub
-rw-r--r-- 1 root root 1210 2021-10-29 11:23 etc/default/grub
The dates show when this was last used, I guess, so 3 years ago...
Looking on the grub of that not running machine:
$ grep "menuentry " boot/grub/grub.cfg
(Result edited to shorten the lines)
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu
menuentry 'Ubuntu, with Linux 5.11.0-38-generic'
menuentry 'Ubuntu, with Linux 5.11.0-38-generic (recovery mode)'
menuentry 'Ubuntu, with Linux 5.11.0-27-generic'
menuentry 'Ubuntu, with Linux 5.11.0-27-generic (recovery mode)'
menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)'
menuentry 'Ubuntu 20.04.3 LTS (20.04) (on /dev/nvme0n1p6)'
menuentry 'Ubuntu (on /dev/nvme0n1p6)'
menuentry 'Ubuntu, with Linux 5.4.0-89-generic (on /dev/nvme0n1p6)' <== HERE
menuentry 'Ubuntu, with Linux 5.4.0-89-generic (recovery mode) (on
/dev/nvme0n1p6)'
menuentry 'Ubuntu, with Linux 4.15.0-161-generic (on /dev/nvme0n1p6)'
menuentry 'Ubuntu, with Linux 4.15.0-161-generic (recovery mode) (on
/dev/nvme0n1p6)'
menuentry 'Ubuntu, with Linux 4.15.0-159-generic (on /dev/nvme0n1p6)'
menuentry 'Ubuntu, with Linux 4.15.0-159-generic (recovery mode) (on
/dev/nvme0n1p6)'
menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
menuentry "GParted live" {
menuentry "Bootable ISO Image: gparted-live-1.3.1-1-amd64" {
So the kernel I cannot get away from is *not* part of the "other" linux since it
is listad as coming from /dev/nvme0n1p6 (my active machine) while the partition
for the other Ubuntu is /dev/nvme0n1p5....
However, the existence of another Ubuntu on the same disk complicates matters...
I have looked at the /boot dir (on my problem machine):
$ ll /boot
total 358720
drwxr-xr-x 4 root root 4096 2024-11-26 18:52 .
drwxr-xr-x 27 root root 4096 2024-11-26 18:52 ..
-rw-r--r-- 1 root root 262408 2024-11-14 17:23 config-5.15.0-126-generic
-rw-r--r-- 1 root root 237778 2024-09-27 14:40 config-5.4.0-200-generic
-rw-r--r-- 1 root root 237884 2021-09-24 15:50 config-5.4.0-89-generic <==
drwx------ 6 root root 4096 1970-01-01 01:00 efi
drwxr-xr-x 5 root root 4096 2024-11-27 10:14 grub
-rw-r--r-- 1 root root 138822274 2024-11-26 18:52 initrd.img-5.15.0-126-generic
-rw-r--r-- 1 root root 88013226 2024-11-02 06:53 initrd.img-5.4.0-200-generic
-rw-r--r-- 1 root root 86876205 2023-06-12 09:22 initrd.img-5.4.0-89-generic
-rw------- 1 root root 6258849 2024-11-14 17:23 System.map-5.15.0-126-generic
-rw------- 1 root root 4762321 2024-09-27 14:40 System.map-5.4.0-200-generic
-rw------- 1 root root 4754490 2021-09-24 15:50 System.map-5.4.0-89-generic
-rw------- 1 root root 11569992 2024-11-14 17:26 vmlinuz-5.15.0-126-generic
-rw------- 1 root root 13701896 2024-09-27 14:56 vmlinuz-5.4.0-200-generic
-rw------- 1 root root 11780352 2021-09-24 15:35 vmlinuz-5.4.0-89-generic <==
I see that config-5.4.0-89-generic and vmlinuz-5.4.0-89-generic are both there
*locally* on my Ubuntu Server.
So there is probably no cross-feed...
And they are both dated 2021-09-24, so really old.
Why are they then not retired but instead forcing themselves to the front???
--
Bo Berglund
Developer in Sweden
More information about the ubuntu-users
mailing list