My 150 GB home partition is mangled!

Question

I've been riding Ubuntu 16.04 down to the wire; with EOL now only four months off, I'm exploring options for replacement (since Linux apparently never will support real upgrades). One of the replacements I'm looking at is Kubuntu 20.04; I previously used Kubuntu 14.04, then switched DTE for 16.04.

Today, I was using the Kubuntu 20.04 Live "Try Ubuntu" option to do a job I couldn't do when running from my SSD: resize my /home partition. I've been getting "low space" messages for weeks what with downloads related to game updates and downloading Linux distro .iso files (each a couple gigabytes or more). Emptying the trash was no longer doing the job, and I had a partition immediately above (to the "left" of) my /home that was leftover from a trial install of Kubuntu 16.04. There were about 2 GB of free space in the 150+ GB /home partition.

Using the KDE Partition Manager on the 20.04 Live trial, I selected to shrink that old Kubuntu partition (which hasn't been used in years, may not even be bootable), move the /home into the freed space, and expand /home to fill the newly freed space at the end of the drive. Everything went smoothly for 45+ minutes while the partition geometry was set, the partition moved, and the geometry reset for the larger space -- but during "expand file system" I was informed that "errors occurred -- aborting". Now, my entire 150 GB /home partition is inaccessible. KDE Partition Manager now reports 160 GiB "unallocated" where my /home should be, 1.84 TiB unallocated space following it (on a 256 GB SSD), and 150.36 GiB (the size of my old /home) with mount point /run and outside the extended partition that it should be in.

I'm confident my data is still present -- the move operation had completed successfully -- but my 16.04 won't boot without /home. I'm not a CLI guru at all, but sudo fsck /dev/sda9 won't even admit that /sda9 exists (it's fine with the other partitions). This partition, like my others, is in ext4 format. At present, the only tools I have are those included on the Kubuntu 20.04 Live download. My old copy of Parted Magic is in the damaged partition, and I don't have a copy on my laptop. And I can't just restore from backup; despite the way things ought to be, backups for hundreds of gigabytes are neither easy nor free.

Most of the data in the partition are games, Wine prefixes for games, downloaded files (largely for games, but also Linux .iso files) -- but also in there are about 100,000 words of partial novels I haven't worked on lately but would very strongly prefer not to lose.

How can I repair this?

So far, I've attempted to use fsck -- which won't admit there's a partition there at all. KDE Partition manager reads out what I've told you -- I might be able to edit in a screenshot from the 20.04 Live session, but I doubt it'll gain anything. I have a working Firefox and wired connection to the Internet on the machine, but the USB isn't set up as persistent, so anything I install will vanish next restart. There's 1.43 GiB of "Writable" partition on the USB stick, but it's not being used for persistence and I don't know how to set it up to be so.

$ sudo blkid
/dev/sda1: LABEL="Boot" UUID="5244bd6b-56d2-4966-bc64-b5d145e681ec" TYPE="ext4" PARTUUID="000e3de9-01"
/dev/sda5: LABEL="Kubuntu64" UUID="b401b3f9-9dc6-4c3d-80fe-aabaf5f327cc" TYPE="ext4" PARTUUID="000e3de9-05"
/dev/sda6: LABEL="Dropbox" UUID="9ddd5013-36af-4d63-a492-710a4069af68" TYPE="ext4" PARTUUID="000e3de9-06"
/dev/sda7: UUID="8cd256cb-e942-425b-acce-e189f0bcf4c9" TYPE="ext4" PARTUUID="000e3de9-07"
/dev/sda8: LABEL="Kubuntu64 16.04" UUID="42b5719f-9dc4-4f92-88d2-c1ec48f25395" TYPE="ext4" PARTUUID="000e3de9-08"
/dev/sdb1: LABEL="Seagate 1T-C" UUID="5E5C65065C64D9F3" TYPE="ntfs" PARTUUID="8623c7fc-01"
/dev/sdb5: LABEL="Seagate 1T-D" UUID="88CCAB91CCAB77D8" TYPE="ntfs" PARTUUID="8623c7fc-05"
/dev/sdb6: LABEL="Seagate 1T-E" UUID="3680C08C80C05451" TYPE="ntfs" PARTUUID="8623c7fc-06"
/dev/sdb7: LABEL="Seagate 1T-F" UUID="E6ACC7B2ACC77B95" TYPE="ntfs" PARTUUID="8623c7fc-07"
/dev/sdb8: LABEL="Seagate 1T-G" UUID="48CCD912CCD8FB60" TYPE="ntfs" PARTUUID="8623c7fc-08"
/dev/sdb9: LABEL="Seagate 1T-H" UUID="CA58E44A58E436BB" TYPE="ntfs" PARTUUID="8623c7fc-09"
/dev/sdc1: UUID="2020-07-31-16-50-07-00" LABEL="Kubuntu 20.04.1 LTS amd64" TYPE="iso9660" PTUUID="7341469f" PTTYPE="dos" PARTUUID="7341469f-01"
/dev/loop0: TYPE="squashfs"
/dev/sda2: UUID="a7bf4f9c-f525-4646-87dd-f897cec03c66" TYPE="swap" PARTUUID="000e3de9-02"
/dev/sdc2: SEC_TYPE="msdos" UUID="C26E-047E" TYPE="vfat" PARTUUID="7341469f-02"
/dev/sdc3: LABEL="writable" UUID="e3579a86-3ecb-4ef0-a21d-983e5b417714" TYPE="ext4" PARTUUID="7341469f-03"

The /home should be /dev/sda9 -- I don't recall immediately whether it was labelled as "Home" or not.

Here's the exported partition table -- I'm afraid to edit this without coaching, but apparently KDE Partition manager can export and import it, so it's possible. As noted, the /home should have been in /sda9.

##|v1|## partition table of /dev/sda
# on Friday, 25 December 2020 22:16:46 UTC
type: "msdos"
align: "sector"
number start end type roles label flags
1;63;208844;ext4;primary;"Boot";"boot"
2;208845;16996769;linuxswap;primary;"";""
3;16996831;500103449;extended;extended;"";""
5;16996833;79907309;ext4;logical;"Kubuntu64";""
6;79907373;100888199;ext4;logical;"Dropbox";""
7;100888263;142833914;ext4;logical;"";""
8;142833978;164562943;ext4;logical;"Kubuntu64_16.04";""
9;4459532288;4774856044;unknown;primary;"";""

I think it should look like this:

##|v1|## partition table of /dev/sda
# on Friday, 25 December 2020 22:16:46 UTC
type: "msdos"
align: "sector"
number start end type roles label flags
1;63;208844;ext4;primary;"Boot";"boot"
2;208845;16996769;linuxswap;primary;"";""
3;16996831;500103449;extended;extended;"";""
5;16996833;79907309;ext4;logical;"Kubuntu64";""
6;79907373;100888199;ext4;logical;"Dropbox";""
7;100888263;142833914;ext4;logical;"";""
8;142833978;164562943;ext4;logical;"Kubuntu64_16.04";""
9;164562944;500321424;ext4;logical;"/home";""

However, while other devices have an option to import a partition table within KDE Partition Manager, that option is greyed out for this SSD ("Export partition table" is available, but not "Import partition table").

I have a working laptop with Unbuntu 16.04, and an external disk test device I can use to access the SSD outside the desktop machine if needed -- so I can use a fully installed 16.04 for the repair work if that's easier/better than the 20.04 Live session. And I have two more days of the weekend (I should be spending this time in my darkrooms, but this is kind of an emergency), with another four-day weekend over New Year's.

@OrganicMarble The block quote mangles the formatting, but there it is, along with the screenshot of KDE Partition Manager displaying that device. — Zeiss Ikon, Dec 25 '20 at 21:15
I am sorry to hear this. IMHO one must haves backups. HDDs and SSDs fail all the time. Sorry, I have no solution other than reformat and restore from backup. — user68186, Dec 25 '20 at 21:19
@user68186 Reformat is the endpoint if I can't get this repaired, but if I can regain read/write access to the partition, fsck might fix it. — Zeiss Ikon, Dec 25 '20 at 21:21
Thanks, @user68186 -- did you just insert hard returns? Every time I've tried to edit a block quote that was mangled like that, it either did nothing, or made it worse. — Zeiss Ikon, Dec 25 '20 at 22:00
Can you change format to ext4 in partition table (not reformat it which would erase it)? Only may work if really ext4. Or does testdisk see it? — oldfred, Dec 25 '20 at 22:02
Hmm, I suppose sda9 is your old /home, which is not read out by lsblk. /run seems to be a mountpoint for temporary filesystems, perhaps as part of the KDE Partition manager ops. Any ideas I have are uninformed and therefore likely to cause greater harm. — Organic Marble, Dec 25 '20 at 22:07
@oldfred Testdisk sees the bad partition, but I'm not sure how to use it to attempt a repair. Been about 30 years since I fixed a disk partition with a sector editor... — Zeiss Ikon, Dec 25 '20 at 23:58
With testdisk it finds all the old versons of partitions. So if changed a lot, can be difficult to know which combination of partitions is correct. But you only have one to restore. parted rescue may be easier since you know start & end sectors. Parted rescue seems easier than testdisk https://askubuntu.com/questions/665445/upgraded-to-windows-10-on-dual-boot-and-cant-boot-to-ubuntu-partition — oldfred, Dec 26 '20 at 00:12
@oldfred It took a little bit, but I've used 'testdisk' or a very similar tool long ago, so it came back to me. Had to verify it was detecting what should have been there, then I let it write the new table back to the drive and rebooted. Partition was readable! Then repeated the "grow partition" and found it was failing the filsystem check -- hence the original abort. Running a check manually (from inside KDE Partition Manager) was successful, after which I was able to resize the partition on the third try (won't let me leave 0 space after, but 36 MiB won't matter in the grand scheme). — Zeiss Ikon, Dec 26 '20 at 00:25
If you want to write that up as an answer (with a link to a good manual for testdisk) I'd be happy to give you a vote and accept. :D — Zeiss Ikon, Dec 26 '20 at 00:26
I changed the block quote to format as code, the { } icon above the edit window. — user68186, Dec 26 '20 at 00:58
Thanks, @user68186. I did get that for later pastes, but it's good to have it confirmed. — Zeiss Ikon, Dec 26 '20 at 01:36

score 1 · Accepted Answer · answered Dec 26 '20 at 04:34

You can try partition recovery tools to reset partition. Testdisk is often used and parted rescue. Testdisk finds all the old versions of the partitions you have, so if many changes, can be difficult to sort out correct set of or partition to restore. You only have one partition so should be a bit easier. Some also use parted rescue where you have to give it approximate start & end of a partition.

http://www.cgsecurity.org/wiki/TestDisk

https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

https://www.gnu.org/software/parted/manual/html_node/rescue.html

Often after a repair you need file system checks. if ext4 format, you run fsck or e2fsck. Example commands for e2fsck:

Ubuntu 14.04 is not booting normaly after a manual hard boot

My 150 GB home partition is mangled!

number start end type roles label flags

number start end type roles label flags

1 Answers1