Copying UM16.04 to smaller drive

[Crotchety]

First, about the GPT error that you are seeing, notice the text that says:

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

This is an indication of the fact that gdisk starts with the assumption that your disk probably has a GPT table (unlike fdisk and other older utils which first look for an MBR type table).

When you run gdisk on the 110G drive, it’s not finding the main GPT table at the beginning of the drive (because that has been replaced with the 16.04 MBR table), but it is finding the old no-longer-used backup table at the end of the drive.

If you post a Gparted screen capture of your current 110G drive partitioning, we can look at how to fix this manually by zeroing out this table with a special dd command using the skip= option, to skip over the 16.04 O.S. and delete the unwanted GPT backup table.

You may want to do this in conjunction with resizing your 16.04 working partition back to the max size possible, let me know, it’s not that difficult.

Now moving on to the strange grub boot loader behavior . . .

If you boot up into your old 16.04 installation and from your 16.04 mate terminal run:

sudo update-grub

… it should see the 110GB drive as sda, and the update-grub should fix your older 16.04 grub boot loader so that it will drop the now-nonexistent 12.04 entry, and correctly show both the 18.04 and 16.04 boot options (although the order may be reversed – 16.04 first, 18.04 second )

The issue of your system sometimes booting from the wrong grub is a little strange, because which boot loader loads should purely depend on the boot drive order specified in your BIOS.

What could be potentially happening is that for some reason your 220GB drive is a little slow to spin up, and sometimes the system moves on to boot from the other drive, and so loads the other grub…

You might be able to fix that by removing the 110GB drive from the boot device list in your BIOS so the system will be forced to wait for the 220GB drive and boot from that.

With MBR partitions we are booting in legacy non-UEFI mode, and sometimes your PC BIOS will also have some additional setting related to “legacy compatibility” for the SATA ports that might help.

[Crotchety]

Also, you mentioned that all your partitions now have unique UUIDs, which should be the case if you reinstalled using the MATE 18.04 installer.

BUT - Disks also have an overall “disk identifier” that is stored in the MBR, and this value may not be unique if you did not go through the additional step of zeroing out the MBR on the 220G drive before you installed MATE 18.04. This is true because the MATE installer will try to preserve the existing partition table and only update and change the partitions where it’s actually installing something.

So, even if you told mate to delete everything and install Mate from scratch, it may not have deleted and recreated the partition table or disk identifier.

Not sure if this will cause weird behavior with grub or not, but it’s a possibility, since this “disk identifier” is ALSO supposed to be unique.

You can easily check the “disk identifier” for all your installed storage devices using the terminal command:

sudo fdisk -l

Sorry I can’t be more definite, but what you are describing really shouldn’t be happening, so just tossing out a few idea’s here . . .

[jaybo]

I already install 18.04 prior to your suggestion of manually zeroing out the table. I also went into the bios and adjusted the boot order, so the default boot now is sda. Some how the boot order changed during this process. I already added swap partition and extended boot partition. Below is a gparted screenshot. Interestingly, I see UM 18.04 installation did not create a swap partition. Is this normal or did this happen because no swap was on sda at time of installation?

[Crotchety]

At this point, since you have already resized the working partition and recreated swap, and it seems to be working, I would not worry about that erroneous GPT error, so long as everything seems to be ok otherwise.

From the way you described things working (with the old 12.04 phantom info sometimes showing up when you boot) it sounds like you are correct in assuming that you now have TWO grub boot-loaders installed, one for the new 18.04 and one for your older 16.04 installation.

In general this is a good thing, since if one grub install gets corrupted somehow, you should be able to just boot from the other drive in your BIOS.

While you were tweaking your BIOS boot settings, did you get a chance to boot up into 16.04 from the 110G drive version of grub and clear out the bogus 12.04 entries by running “sudo update-grub”?

If so, did the old grub installation then properly detect your 18.04 install on the other drive?

Not sure what to make of the missing swap partition on the 18.04 install, unless you had already restored the 16.04 swap partition on the other drive before you installed 18.04, and the 18.04 installer decided to use the existing swap rather than create a new one.
:
To find out for sure, just boot up into your new MATE 18.04 desktop and open a terminal and run:

swapon -s

EDIT:
Just a quick added note, to say that in general having two Linux installs share a swap partition is not an issue so long as you don’t try to use “hibernate” mode standby.

In hibernate mode, the system writes out RAM contents to the swap area before shutting down, then restores from swap when waking, which would obviously get boogered up if two installations were sharing a swap area . With large amounts of RAM, hibernate is MUCH slower than suspend to RAM sleep mode, so it’s normally disabled by default. This can be confusing in recent versions of Ubuntu, where the power manager will say it’s set to ‘hibernate’ for some settings but just use ‘sleep’ anyway.

[jaybo]

Yes, I did restore SWAP on 16.04 before installing 18.04.

From 18.04
$ swapon -s
Filename Type Size Used Priority
/swapfile file 2097148 0 -2

So if the SWAP partition on sdd is being used by 18.04 on sda, I don’t understand the size indicated as the swap partition on sdd is 8GB. Looking at the 18.04 fstab it indicates no swap is being used.:
/swapfile none swap sw 0 0

Wouldn’t it be a good idea to add one, and if so, I think it makes senses for each distribution have its own swap on the same drive as the boot.

BTW…I just logged into 16.04 via the bios, and it seems the grub some how was fixed without me doing anything except logging in back and forth between distributions as I build up 18… The sdd grub now indicates 16.04 first then 18.04 as expected. The 12.04 is no longer listed.

[Crotchety]

BTW…I just logged into 16.04 via the bios, and it seems the grub some how was fixed without me doing anything except logging in back and forth between distributions as I build up 18… The sdd grub now indicates 16.04 first then 18.04 as expected. The 12.04 is no longer listed.

Great!

It sounds like you have things on track.

The reason I suggested that you check the swap status with swapon -s is that Ubuntu 18.04 can install with multiple swap options.

If you assign a dedicated swap partition, or install with LVM/LUKS encryption, then 18.04 will use a separate swap partition, but since version 17 Ubuntu can also use a simple swap file.

From the swapon -s response that you posted, it looks like your MATE 18.04 installation is using a simple 2 Gig swap file (2,097,148 1K blocks).

There are several ways to enable swap using a swap file in Debian based releases, but I suspect that they handle it like they did in the earlier Ubuntu 17 release using a simple /etc/fstab entry.

If you want to shift back to using the traditional disk partition method, look in your /etc/fstab for an entry like:

/swapfile none swap sw 0 0

… and change it to something like:

UUID=xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx none swap sw 0 0

… where the UUID matches your new swap partition (just like you did with 16.04)