Lost both 20.04 and 24.04 when upgrading from former to latter

Support and Help
1

Background: a 64-bit desktop PC with a 2012 UEFI BIOS, 7.8 Gb of RAM, and an ~ 1 Tb disc. Prior to the events to be related, the disc was split into two partitions, one (~ 800 Gb) with Ubuntu 20.04 and the other with Ubuntu 14.04, left as a precaution when I upgraded to 20.04.

I recently installed Ubuntu 24.04, splitting the 800 Gb partition into one with 360 Gb (where I left 20.04) and one with 430 Gb for 24.04. I then found that none of my documents and data files had been put in the 24.04 partition, which I ruefully attributed to having merely installed 24.04 rather than upgrading to it.

Wishing to return to square one so as to do a proper upgrade, I removed Ubuntu 24.04 with OS-Uninstaller. I noted that I still had three partition, but failed to consider the possible implications of this. Through Ubuntu 20.04 I then tried to upgrade to 24.04, and to judge by the output on the terminal the upgrade was completed successfully. But the grub boot menu has Ubuntu 14.04 as its default, fails to list Ubuntu 24.04, and, when Ubuntu 20.04 is chosen, returns an error sheet:

[0.440201] Initramfs unpacking failed: invalid magic at start of compressed archive
[2.342338] Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
etc.

So now I can only use Ubuntu 14.04 and the old files in that partition. Its file manager shows all three partitions, but when I try to look inside the 430 Gb volume I get an error message:

Error mounting /dev/sda7 at /media/papa1/9edf34bb-af1e-48f0-9739-04bedf2fd891: Command line ‘mount -t “ext4” -o “uhelper=udisks2,nodev,nosuid” “/dev/sda7” ”/media/papa1/9edf34bb-af1e-48f0-9739-04bedf2fd891” exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/sda7, missing codepage or helper program, or other error
In some cases useful info is found in syslog – try dmesg | tail or so

When I look in the 360 Gb volume all the files previously shown under Ubuntu 20.04 appear to be there, but I have no idea whether they can be used to recover the ability to boot Ubuntu 20.04 – and if they can, that still leaves the problem of establishing a state in which I can upgrade successfully to ubuntu 24.04.

Any help would be much appreciated.

2

Do you want to use this as a learning experience?
Or do you want the fastest way to restore a working system?

Do you have a complete backup of your data from your /home directory?
If not, do you have the capability (external media capacity) to make one?

3

You have not told us at all how you tried to do that update in detail, could you elaborate on the process you have used ?

You also seem to have used a third party tool called OS-Uninstaller (not sure what it is supposed to do or how it is tested even, there does not seem to be any source code around for it either when searching for it), if that did something wrong we will not be able to help with it …

4

I want my system back. Yes, I have an external backup of my home directory, but not of the complete 360 Gb partition.

5

As I recall, I went through Software Updater, clicking on an Upgrade button and following the instructions thereafter. There was a small hitch that I believe has been complained of many times (the computer seems to hang after emitting the message “Pregenerating Context MarkIV format. This may take some time …”), but I solved it (apparently) following community advice simply to press Enter.

I was directed to OS-Uninstaller by a Ubuntu community page, OS-Uninstaller - Community Help Wiki. I believe its code is on Source Forge.

6

Ah, the old tex stuff … that was long removed from the default install …

Well, when you used the official upgrader you did not go from 20.04 to 24.04 (there is no possibility to do that without pretty gross hacks that bypass the proper upgrade process, which is why I was asking the question about your process in the first place) but you would upgrade from 20.04 to 22.04 instead … from where you would (only then) go to 24.04 afterwards … so your currently broken 20.04 upgrade is likely a broken 22.04 now …

7

Sure. I have no objection to getting to 24 via 22, and probably overlooked any indication of the version to which I was upgrading.

8

I think it might help if we have a clearer picture of where things stand right now.

You need a bootable USB with a recent version of Ubuntu for this.

Boot the computer and choose to Try Ubuntu and not install.

Then follow the instructions here to create a summary report and post the pastebin link back here.

Important: do not try and repair anything yet, we need to see the report.

9

Right, it might just be important info for the people helping you, this is why I was asking all the stuff above :wink:

10

The report is at https://paste.ubuntu.com/p/SjJj8xgh9/. During its production a message came up informing of a program bug, which was sent to the developers.

11

Since the first boot info summary seems to have disappeared, I repeated the process, assuming (as before) that my system has no RAID, and noting this time that the system program problem is in subiquity 315. The new address for the boot info is Ubuntu Pastebin

12

Your predicament could well be a blessing in disguise.
Your current systems are installed in old-fashioned Legacy mode with msdos partition table.
UEFI mode with GPT is the modern way.

According to this info, your PC is UEFI compatible, therefore I would recommend that you start from scratch.

Make sure that you backup is up-to-date.
Create an installation disk from the Ubuntu 24.04 iso.
Importantly, boot the installer in UEFI mode so that the installation follows suit.
GPT is now the default.

13

Boot repair suggests reinstalling Grub to the MBR of sda pointing to sda1 which is your 14.04 install. I don’t know why unless that is the old Grub you were using. I would have expected it to point to sda6 which was your 20.04 and now shows 22.04 but may not be complete. Your sda7 partition (24.04 attempt?) is corrupted so is not likely to do anything.

You could accept the suggestion of boot repair and install Grub for 14.04 to the MBR and see if you can boot it then run sudo update-grub to see if you get an entry for 20.04 or 22.04 and see if you can boot that. You could also try to chroot into the system on sda6 (22.04) and reinstall/update grub.

As pointed out above, direct upgrade is only available to consecutive LTS versions and in your case going from 20.04 to 22.04 and after that is successful, going from 22.04 to 24.04. You waited until after support for 20.04 ended before trying this which is what led to the problems.

14

As I understand it, support for 20.04 ends on May 31st. That is why I wanted to upgrade.

What I would like of a solution would include merging the 20/22 and 24 partitions into one prior to upgrade or, if upgrade is no longer possible, direct installation of 24.

I will first try the first plan of your second paragraph.

15

Boot-repair worked - many thanks - in that I now have a working 22.04, with all my documents etc., in my 360 GB partition, and this system shows up on the GRUB boot menu. However, Ubuntu 14.04 is still the default on that menu, and before upgrading to 24.04 I would like to recover the 430 GB that is now unusable. Any suggestions?

16

Re: Recovery of 430 GB. Here follows just an outlier idea, others might offer standard solution.

You might experiment with Recoll indexing your 430 GB. Note that (a) you will need about 10% plus headroom to hold the index. (b) You will need a fresh separate data silo (another mounted SSD perhaps) to retrieve the indexed files. Another similar recovery ploy is testdisk. Here is one link referring to Recoll usage.

17

Thanks, but I don’t think Recoll will be much use. There is nothing of value in the 430 GB volume - it just contains a folder named ‘Deleted OS’ which presumably contains the 24.04 I deleted; I stored nothing of value there before deleting. What I mean by ‘recover’ is to recover all that space by some kind of merger with the 360 GB partition.

18

Unfortunately that I did not pick up. But keep Recoll in mind when you are back in play. Powerful little beast.

19

OS#2 (linux): Ubuntu 22.04.5 LTS on sda6
Your OS is located on sda6

sda6        392634368 1100484607  707850240 337.5G 83 Linux
sda7       1100486656 1936840703  836354048 398.8G 83 Linux

sda7 is the partition to recover (i.e. merge to sda6)

Manipulating partitions can lead to tragic consequences, therefore make sure your personal data is backed up.

  • Boot into a 24.04 “Try Ubuntu” live session
  • Open Gparted
  • Delete partition sda7
  • Grow/extend partition sda6 to incorporate the unused space

N.B. I have assumed that the partition info from the boot-repair report is still current.

Notwithstanding the above, I still recommend that you start from scratch with UEFI mode and GPT

3 Likes
20

The boot repair report provided with the successful repair is at Ubuntu Pastebin

Does the sequence of actions Boot into Try Ubuntu - Open Gparted - Delete sda7 - Extend sda6 still stand?