Ubuntu 20.04.6 LTS apt problems - how to upgrade f/w?

[Nils Kassube]

On 28.11.24 Bo Berglund wrote:
> On Wed, 27 Nov 2024 17:21:09 +0100, Nils Kassube via ubuntu-users
> <ubuntu-users at lists.ubuntu.com> wrote:
> >I think you can still boot the current kernel from the boot menu of the old system because you have a menuentry there. It doesn't matter that the actually used partition is nvme0n1p6 and not nvme0n1p5. Please check the line like
> >
> >   set default="0"
> >
> >near the top of the grub.cfg file on nvme0n1p5. If the number is "8" (if I counted right) you are very likely booting with grub from the other partition.
> >
> Well if a desktop user reboots and selects the boot menu item:
>
> Ubuntu, with Linux 5.4.0-89-generic
>
> then he will surely boot into the *server* using that kernel, which I want to
> upgrade from....
>
> To answer the question:
>
> The numbers have been 3 and 0...
>
> Long reply below:
>
> In the boot/grub/grub.cfg file on the non-used Ubuntu Desktop I see this about
> 23 lines down:
>
> if [ "${next_entry}" ] ; then
>    set default="${next_entry}"
>    set next_entry=
>    save_env next_entry
>    set boot_once=true
> else
>    set default="3"
> fi

> Looking at the Desktop disk:
> ----------------------------
> I mounted /dev/nvme0n1p5, which is the disk for the Desktop Ubuntu I have
> not used after October 2021 but still here.
>
> $ cd /mnt/ubuntudsk  #This is the mount for the Desktop partition
> $ grep "menuentry " boot/grub/grub.cfg
>
> The result after editing out the end of long lines to make it fit here:
>
> menuentry 'Ubuntu'
> 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)'
> ----- The above are on the Ubuntu Desktop machine --------
>
> menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)'
> ----- The line above is for the Windows boot ---------------
>
> ----- And below are read from the Ubuntu Server back in 2021 ----
> 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)'
[...]

Well, as the desktop system would automatically select the entry number 3 it would be
menuentry 'Ubuntu, with Linux 5.11.0-27-generic'
which is not your current kernel. OTOH, I don't know what the lines above set default="3" would actually do (including the lines above what you posted). It seems to be some sort of magic to select a working kernel in case of a failure. So maybe your working kernel is selected by that magic. Hopefully someone else can comment about it.

> As you can see the 5.4.0-89 entries on Server are referenced by the Desktop...
> And by the timestamp of the file it was done back in 2021!
>
> Also note that the other external entries from the Desktop back then are no
> longer available there, they have long since been replaced by later versions.

> So could it be that the fact that there is a grub boot menu on the Desktop
> machine that references the Server active kernel 5.4.0-89 makes it remain also
> on the Server machine, since if it was removed from the Server then the grub.cfg
> on the Desktop would be broken? Or what could it be that keeps the kernel on the
> Server?

I suppose the 5.4.0-89 kernel was never removed from the server because it is the running kernel, IIRC, you can remove it but you will be asked if you really want to remove the running kernel. If you do so, the desktop grub entries will be broken and your system may not boot without manual action if it actually uses that grub menu.

> Probably the apt update/upgrade/remove and update-grub actions on the Server
> cannot include *removing* a kernel referenced from the Desktop....

I don't think so. When I test a new Kubuntu version, I keep the older version on a separate partition on the same disk. So each system has entries for the other version. I know I have removed kernels which were still referenced on the other system making those entries broken. So it is more likely that it just refuses to automatically remove the running kernel.

> Now when the update-grub command is executed it seems like it scans both the
> current disk but also searches through all other partitions for an Ubuntu
> installation with a /boot/grub/grub.cfg file and possibly also /etc/default/grub
> and if found it merges in data from that too into its main boot menu
> compilation?

Yes, that's what the os-prober part of update-grub does. If you don't like that feature, you can put a line

GRUB_DISABLE_OS_PROBER=true

in /etc/default/grub.

> That would happen when one issues sudo update-grub on the Server machine.
>
> If at that time there is no longer any partitions containing references to those
> kernels surely nothing would be fetched into the grub menu from the Desktop,
> or???
>
> Of course the final grub boot menu in the efi partition has to contain current
> stuff from all bootable partitions in order to start any machine if the user so
> chooses...

"grub boot menu in the efi partition" ...

Sorry, I'm not familiar with EFI, the only system I have with UEFI runs Windows only. But if you have a grub boot menu on the EFI partition, that could be the place where the wrong kernel is selected.

> My best bet now is to simply reformat the Desktop partition completely thus
> purging its Ubuntu Desktop from the system altogether.
>
> After that I should be able to sudo update-grub to clean it all up and finally
> boot into a newer kernel, right?

No, if the system boots with the grub menu from the desktop system it will stop working after reformatting the desktop partition because the menu is gone. You should first install grub from within the running server, BUT what I can't tell you is how to do it with a EFI/UEFI system.

> Do you think I have to hook up a display and keyboard to the PC so I can
> interact with the boot menu in this case?

I think you should really connect display + keyboard so you can find out which grub menu is in use. You could add a line

GRUB_DISTRIBUTOR="Ubuntu-Server"

to your /etc/default/grub and then run update-grub again. Then you should see on the display if you are getting the grub menu from the server system or not.


Nils