Dist-upgraded server 20.04.6 => 22.04.1 => 24.04.1 - Apache problems....

[Bo Berglund]

On Mon, 16 Dec 2024 11:27:44 +0100, Oliver Grawert <ogra at ubuntu.com> wrote:

>hi,
>Am Sonntag, dem 15.12.2024 um 18:34 +0100 schrieb Bo Berglund:
>> 
>> But there is another thing I discovered and that is that after the
>> release
>> upgrade the grub menu is not correctly updated!
>> 
>> I have repeatedly run the sudo update-grub command and yet the grub
>> menu insists
>> on only showing the Ubuntu 20.04 entry for the now upgraded server!
>> Why is that so?
>
>$ grep -B6 OS_PROBER /etc/default/grub

It returns nothing at all....

># If your computer has multiple operating systems installed, then you
># probably want to run os-prober. However, if your computer is a host
># for guest OSes installed via LVM or raw disk devices, running
># os-prober can cause damage to those guest OSes as it mounts
># filesystems to look for things.
>#GRUB_DISABLE_OS_PROBER=false
>$ _
>
>You probably want to re-enable os-prober and re-run update-grub 

The computer is a Lenovo PC that came with Windows pre-installed.
It was bought in October of 2021.

I wanted to use it as my server in place of a really old PC from roundabout 2005
or so.
So I installed Ubuntu Desktop on it, the version was 20.04.1
I experimented with Linux using it and then I tried the following:

1) I dist-upgraded my older *server* from 18.04 to 20.04 (same level as the
desktop I just put on it).

2) Then I extracted its hard drive and using GParted on the new Ubuntu Desktop
on Lenovo with the old drive attached via USB I copied the partition with server
20.04 to the Lenovo disk as a new partition directly after the Ubuntu Desktop
partition.

3) Somehow I managed to boot to it, don't remember now but I could have run
grub-update on the Desktop to put the server on the grub menu as well...

Since several years now I have not used the desktop at all but I had two chunks
of data on the root partition of the server, which I really did not want to keep
there.

These are the Subversion repositories and also the home dir.
So with a bootable GPartedLive I managed to move the SVN data into its own
partition as well as the complete /home dir into its own partition too.
These are now mounted into the old positions on boot using fstab.

A couple of weeks ago when I had the problems with an old kernel refusing to be
removed and replaced by a more recent one I finally rebooted the box and found
myself looking at a violet-pink screen with nothing showing.
I had probably selected the wrong entry on the grub menu...

I tried to connect using PuTTY and was greeted with a warning screen about a
mismatch on connection. So I canceled and tried to use the PuTTY shortcut for
the desktop instead and sure enough, when I got into it via SSH I could browse
through it and also run apt update/full-upgrade to bring it up to date. It WAS
the desktop that booted but failed to show anything after the boot menu except
the pink screen.

I also did a grub update from there and when I rebooted and selected my server
instead of the desktop I was running the later kernel finally.

So the above story is in one of the messages above too but I repeated it here
because:

It looks like the grub menu has to be managed from the *same* operating system
all the time! Is that really so?

If I run grub update on the desktop then the menu gets an updated version of the
server, but not if I do the same from the server itself...

Now after having done two dist-upgrades on the server and it is at 24.04.1 do I
have to boot into the non-working (for GUI access) desktop and via SSH do the
grub-update from it in order to get it to actually update the menu so one sees
the actual Ubuntu level for the server?


-- 
Bo Berglund
Developer in Sweden