16.04 and 20.04 side by side on one harddisk

[Liam Proven]

On Thu, 18 Mar 2021 at 19:02, Lentes, Bernd
<bernd.lentes at helmholtz-muenchen.de> wrote:
>
> Hi,
>
> we have an Ubuntu 16.04 installed on a normal pc. It has installed a lot of applications, especially Bioinformatic tools which have been complicated to install.
> We are thinking of upgrading to 20.04, but want to keep the old installation as an emergency solution.

That should be fine.

> I'm thinking of installing 20.04 beside 16.04 so that we can try to get all applications running on 20.04, but still having 16.04.
> I never did that before, that's why i asked. Is that possible ?

Yes, certainly.

> I assume Grub is intelligent enough to recognize the old system during the installation of 20.04 and insert it in the boot menu.
> Yes ?

Yes, it is.

> Beside the two systems we have large partitions (several TB) with data.

OK, this is where it gets a little more complicated. :-)

If the data is elsewhere, that is good, it makes it easier, but the
answers stop being "yes". ;-)

> Another idea is to use virtualization, KVM. Install KVM on 16.04 and install 20.04 in a VM.
> So we have both systems running simultaneously.

I would suggest that you do it the other way round, if this was what
you really want. 20.04 is of course bigger and takes more disk and
more RAM. It would be easier to run 16.04 in a VM under 20.04.

> We could change the FS of the data partitions to OCFS2, so concurrent access should be possible.

That sounds like a major, possibly breaking, change.

> I found an article using OCFS2 without pacemaker, it seems to be easy.

I don't know it and have not used it, but I doubt it. I have used Ceph
a little and it is _not_ easy, not at all.

> Can i access partitions directly with a VM under KVM ?

You can, yes, but it too is not trivial and I would not recommend it.

As far as multibooting different versions: no problem.

What I do one some of my systems is this:

(Let us assume a laptop with only 1 big disk, say 1TB, partitioned MBR)

• one _primary_ partition with Windows, for BIOS updates
• one _extended_ partition
• inside that:
    • one logical partition per distro or version, formatted ext4, say
32GB each, mounted as / (root)
    • one relatively big logical partition, formatted ext4, as a
single global /home partition
    • at the end, one smallish partition as swap

So you could have, say:

[#1: Windows, NTFS, 128GB] [#2 Extended, 896GB (#5 Root A)(#6 Root
B)(#7 Root C)(#8 /home)(#9 swap)]

Inside distro A:
/dev/sda1 ... /windows
/dev/sda5 ... /
/dev/sda8 ... /home
/dev/sda9 ... swap

Inside distro B:
/dev/sda1 ... /windows
/dev/sda6 ... /
/dev/sda8 ... /home
/dev/sda9 ... swap

Inside distro C:
/dev/sda1 ... /windows
/dev/sda7 ... /
/dev/sda8 ... /home
/dev/sda9 ... swap

So long as you only boot 1 at a time, this is fine.

Caveats:

#1, *important* — make sure that all distros have non-overlapping
usernames. "root" does not have a home directory on /home so is fine,
but other users must all have different names.

Distro A: root, liam_a
Distro B: root, liam_b
Distro C: root, lproven

Then there are no collisions over home directory names and all is well.

Shared swap is fine if you do not use hibernation.

#2, less important — all distros default to putting GRUB in /dev/sda

This is a problem. The last distro to be updated will "take control"
of the boot sector. If you update A, then B and C  will try to boot
A's _previous_ kernel. This may well fail.

Easy solution:

Allow Distro A to put GRUB in /dev/sda
Tell distro B to use /dev/sda6 (its root partition)
Tell distro C to use /dev/sda7 (its root partition)

If you update distro B or distro C, then boot distro A and run
`update-grub` and it will update its boot menu and all will be well.
Until  you do this, if you reboot distros B or C after an update,
_they will not get their new kernel_

More complicated solution 1: use the Windows boot manager; get it to
chainload bootloaders, and tell all distros to put GRUB in their root
partitions. This works but is a pain.

More complicated solution 2: if you don't use Windows, then make
/dev/sda1 bootable with plain old MS-DOS or FreeDOS and use a DOS boot
manager. My favourite is PowerQuest BootMagic, which was eventually
freeware.
e.g. https://powerquest-bootmagic.software.informer.com/8.0/

Again, tell each distro to use its own root partition. Build the boot
menu in DOS and just chainload each of the 3 copies of GRUB. Easier
than it sounds.

If you only have 2 distros:

[1] Install new version. Put GRUB in MBR
[2] Boot old version. Tell it to install GRUB into its own root partition.
[3] Reboot  into new version. Run `update-grub

Now both will work but only the newer version is in control of the MBR
and of GRUB. As noted, if you update the old version, boot the new one
and run `update-grub` to pick up the new kernel.

I advise _against_ trying to let a VM and a host OS both try to access
partitions at once. This is a recipe for disaster. Move the data
partitions onto a dedicated server, put new and old versions on
different boxes, network both to your host server, and all will be
well.



-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lproven at cix.co.uk – gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053