[solved] OS partition lost after move and resize with "KDE Partition Manager"

[RoGeorge]

On the main disk there were two Linux installations, each with its own partition, and wanted to shrink the least used OS partition, then to grow the size of the main OS partition (Kubuntu 20.04 LTS).

- downloaded the latest Kubuntu 20.04 LTS iso image
- dd the iso to an USB stick
- boot from the USB into the live version
- used the default GUI partition manager "KDE Partition Manager" to resize the two partition from the hard disk

On that disk (/dev/sdd) there were 5 partitions:
- /dev/sdd1 - FAT32 - boot partition
- /dev/sdd2 - FAT16 - EFI partition
- /dev/sdd3 - Linux swap
- /dev/sdd4 - Ext4 - the other OS partition (for Gentoo, the one to shrink)
- /dev/sdd5 - Ext4 - the main OS partition (for Kubuntu, the one that got damaged)

Steps that went well
- shrink the sdd4 partition

Steps that ended in error
- moving the sdd5 to the left, so to start where the now smaller sdd4 ends

Steps not yet performed
- enlarge moved sdd5 to occupy all the empty space up to the end of the disk



I let the move sdd5 step to run overnight, and in the morning the message was the move step ended in an error.  No other details.   

So far I've "dd"-ed the entire /dev/sdd disk to a file on another HDD as a crude backup.
- Ubuntu 2018 (from yet another HDD) sees the whole disk /dev/sdd/ as one big piece the size of the entire disk when looked with Gparted (a single partition zfs filesystem - I thought it was Ext4)
- Ubuntu 2018 "Disks" sees the other 4 partitions OK (those other 4 can be mounted, too), but /dev/sdd5 is listed as ZFS member, and automount doesn't work.  No idea why is so instead of being seen as ext4, how it was before moving it.

If I try "sudo mount -t ext4 /dev/sdd5 ~/mnt_tst/sdd5" it doesn't mount with the error "wrong fs type, bad option, bad superblock on /dev/sdd5, missing codepage or helper program, or other error."

Now what?

[SeanB]

Yes partitions often do not move, you can shrink them, or grow them, but in general moving them does, as the partition manager says, run the risk of data loss. Would have been best to simply make a link to the Gentoo partition, and used that space, which is what I do with my laptop and it's unused Win7 partition. Have used the Win7 side only twice, once to make the back up disk images for the system, and then because I needed to use GoToWebinar, so was easiest to use it than the try to get it working on the VM of XP in there. So there is a folder of my stuff in the Win directory, and it works well, storage that is on the same drive, just slightly less convenient.

For the best results I always make /home a separate partition, so that even if the OS brain farts and dies, you can simply reinstall and not format your home directory, and pretty much carry on where you left off.  Did mean I did have to do some risky partition surgery, when the installer decided to make /boot only 128M, but left 8G of partition space after for swap, which I then moved to another SSD instead, and used the 8G to grow the boot partition. Swap now is it's own drive, along with /temp, and both are barely used. Does make the sizes look odd, file system is 192G free, while /home is 640G free. FSCK still sees it all though as one large drive.

[magic]

Code: [Select]

fdisk -l /dev/sdd
gdisk -l /dev/sdd
file -s /dev/sdd*
smartctl -a /dev/sdd
If you are lucky, your old filesystem may still be in its original location and it's just a matter of pointing the partition to it.
If you are not, it may have been mangled by the move process. I don't know exactly how it works, although I have a suspicion it's akin to

Code: [Select]

dd </dev/sdd >/dev/sdd skip=old_offset seek=new_offsetIf you are very unlukcy, the disk itself could be screwed and hence the move error. I gather you haven't checked dmesg after it crapped out.

Your experience makes me reconsider using those GUI toys and move partitions like a man (on the odd occasion that I want to move one).
Save for hardware failure there is nothing in this process that is supposed to go wrong

[PKTKS]

So far I've "dd"-ed the entire /dev/sdd disk to a file on another HDD as a crude backup.
Now what?

MAKE DEAD SURE YOU ARE AWARE THAT THIS IS DESTRUCTIVE
ONE WAY ONLY AND NOT NEWBIE STUFF

Excellent so you are good to go...

Restore your old partition table..
(Note: sfdisk  can handle MBR,GPT,disklabels and other partition schemas..
unlike  fdisk MBR only and dd which depends on device logical block magics)

Code: [Select]


sfdisk MY_SCREWED_PARTITION_DEVICE  < sfdisk --dump MY_GOOD_BACKUP_RAW_IMAGE

Me in particular case as for experience would do the
restoration of data on the restored partition by using
a safe method.

Some alternatives possible:

-  Using an exported NBD  logical device from the GOOD_BACK
so only the partition number would be mounted and restores..

- Using a raw disk image mount from the GOOD BACKUP device

The NBD method allows direct dd of the desired partition
But honestly I would go re-formatting the  restored partition
and rsyncing the data...

MAKE DEAD SURE YOU ARE AWARE THAT THIS IS DESTRUCTIVE
ONE WAY ONLY AND NOT NEWBIE STUFF

You may for the sake of security do that in steps

Code: [Select]

sfdisk --dump MY_GOOD_BACKUP_DEVICE.raw  > xxx_device.sf
sfdisk MY_SCREWED_PARTITION_DEVICE < xxx_device.sf

sfdisk -l MY_SCREWED_PARTITION_DEVICE


After that you should be able to handle the screwed partition

Paul

[RoGeorge]

There is no good dd backup.  The dd backup was made after the partition was lost, for just in case some recovery tool might mess it even more.  Should have made the dd backup before running the KDE Partition Manager... 



fdisk output

Code: [Select]

sudo fdisk -l /dev/sdd
[sudo] password for muuu:
Disk /dev/sdd: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4B...3F

Device        Start       End   Sectors  Size Type
/dev/sdd1      2048      6143      4096    2M Microsoft basic data
/dev/sdd2      6144    268287    262144  128M EFI System
/dev/sdd3    268288   1316863   1048576  512M Linux filesystem
/dev/sdd4   1316864  73222143  71905280 34.3G Linux filesystem
/dev/sdd5  73222144 205697023 132474880 63.2G Linux filesystem


gdisk output

Code: [Select]

sudo gdisk -l /dev/sdd
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdd: 312581808 sectors, 149.0 GiB
Model: ST3160023AS     
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 4B...3F
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 312581774
Partitions will be aligned on 2048-sector boundaries
Total free space is 106886765 sectors (51.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            6143   2.0 MiB     0700  grub
   2            6144          268287   128.0 MiB   EF00  boot
   3          268288         1316863   512.0 MiB   8300  swap
   4         1316864        73222143   34.3 GiB    8300  rootfs
   5        73222144       205697023   63.2 GiB    8300 


file output

Code: [Select]

sudo file -s /dev/sdd*
/dev/sdd:  DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 312581807 sectors, extended partition table (last)
/dev/sdd1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, sectors 1048576 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1024, reserved 0x1, serial number 0xdb...b7, unlabeled
/dev/sdd2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, reserved sectors 4, root entries 512, Media descriptor 0xf8, sectors/FAT 256, sectors/track 63, heads 255, hidden sectors 6144, sectors 262144 (volumes > 32 MB), serial number 0x1f...b2, unlabeled, FAT (16 bit)
/dev/sdd3: Linux/i386 swap file (new style), version 1 (4K pages), size 131071 pages, no label, UUID=26...37
/dev/sdd4: Linux rev 1.0 ext4 filesystem data, UUID=0d...85 (extents) (64bit) (large files) (huge files)
/dev/sdd5: data


smartctl output

Code: [Select]

sudo smartctl -a /dev/sdd
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.18.0-13-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, [url=http://www.smartmontools.org]www.smartmontools.org[/url]

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.7 and 7200.7 Plus
Device Model:     ST3160023AS
Serial Number:    3......3
Firmware Version: 3.18
User Capacity:    160,041,885,696 bytes [160 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA/ATAPI-6 T13/1410D revision 2
Local Time is:    Tue Jun 15 15:19:33 2021 EEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (  430) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
No General Purpose Logging support.
Short self-test routine
recommended polling time: (   1) minutes.
Extended self-test routine
recommended polling time: ( 111) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   061   052   006    Pre-fail  Always       -       94151013
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       221
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   086   060   030    Pre-fail  Always       -       426088833
  9 Power_On_Hours          0x0032   049   049   000    Old_age   Always       -       44769
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   090   090   020    Old_age   Always       -       10803
194 Temperature_Celsius     0x0022   043   060   000    Old_age   Always       -       43
195 Hardware_ECC_Recovered  0x001a   061   051   000    Old_age   Always       -       94151013
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   188   000    Old_age   Always       -       49
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
202 Data_Address_Mark_Errs  0x0032   100   253   000    Old_age   Always       -       0

SMART Error Log Version: 1
ATA Error Count: 66 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 66 occurred at disk power-on lifetime: 196 hours (8 days + 4 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 0d f2 23 53 e0  Error: ICRC, ABRT 13 sectors at LBA = 0x005323f2 = 5448690

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 7f 80 23 53 e0 00      02:23:24.527  READ DMA EXT
  25 00 49 b7 22 53 e0 00      02:23:24.515  READ DMA EXT
  25 00 5f 80 0d 53 e0 00      02:23:24.515  READ DMA EXT
  25 00 28 97 ca 52 e0 00      02:23:24.513  READ DMA EXT
  25 00 10 80 a1 52 e0 00      02:23:24.513  READ DMA EXT

Error 65 occurred at disk power-on lifetime: 196 hours (8 days + 4 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 00 0e b0 14 e0  Error: ICRC, ABRT at LBA = 0x0014b00e = 1355790

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 07 b0 14 e0 00      02:20:41.775  READ DMA EXT
  25 00 08 37 b9 14 e0 00      02:20:41.775  READ DMA EXT
  25 00 08 77 b0 14 e0 00      02:20:41.774  READ DMA EXT
  25 00 08 97 b1 14 e0 00      02:20:42.035  READ DMA EXT
  25 00 08 8f b1 14 e0 00      02:20:42.032  READ DMA EXT

Error 64 occurred at disk power-on lifetime: 196 hours (8 days + 4 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 00 7f e7 14 e0  Error: ICRC, ABRT at LBA = 0x0014e77f = 1369983

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 80 00 e7 14 e0 00      02:08:22.438  READ DMA EXT
  25 00 08 17 8d 15 e0 00      02:08:22.437  READ DMA EXT
  25 00 80 80 e6 14 e0 00      02:08:22.433  READ DMA EXT
  25 00 80 00 e6 14 e0 00      02:08:22.432  READ DMA EXT
  25 00 08 8f 8b 15 e0 00      02:08:22.432  READ DMA EXT

Error 63 occurred at disk power-on lifetime: 188 hours (7 days + 20 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 07 f9 61 c1 e0  Error: ICRC, ABRT 7 sectors at LBA = 0x00c161f9 = 12673529

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 69 97 61 c1 e0 00      00:58:36.801  READ DMA EXT
  25 00 12 80 61 c1 e0 00      00:58:36.811  READ DMA EXT
  25 00 69 17 61 c1 e0 00      00:58:36.810  READ DMA EXT
  25 00 29 d7 60 c1 e0 00      00:58:36.808  READ DMA EXT
  25 00 57 80 60 c1 e0 00      00:58:36.808  READ DMA EXT

Error 62 occurred at disk power-on lifetime: 187 hours (7 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 00 8e f4 4a e0  Error: ICRC, ABRT at LBA = 0x004af48e = 4912270

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 0f 80 f4 4a e0 00      00:23:36.230  READ DMA EXT
  25 00 71 0f f4 4a e0 00      00:23:36.227  READ DMA EXT
  25 00 08 3f f3 4a e0 00      00:23:36.227  READ DMA EXT
  25 00 30 0f f3 4a e0 00      00:23:36.226  READ DMA EXT
  25 00 0f 00 f3 4a e0 00      00:23:36.226  READ DMA EXT

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%        95         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.



I am surprised by the number of errors reported by smartctl (thought it seems the errors were always corrected).  The disk was always very reliable, bought two of them 15+ years ago and they still work just fine.  Their first decade or so they worked in RAID0, and never lost any data AFAIK.



Yesterday I've tried to identify the ext4 with "testdisk", but without any success.

Another tool I've found out yesterday is "photorec", that can extract files without a valid ext4 filesystem.  The downside is "photorec" can only tell the extension, not the name of the file and not the directory structure, so in the end it produces a gazillion of folders with gazillion of files, with all the directories flattened only one level deep.

Since the home and root were on the same partition, finding the content of the home directory would be very time consuming.

Seems like I was not the only one who lost a partition after moving it with "KDE Partition Manager", a dude tried and failed 8 times when using KDE Partition Manager (he did the dd before, not like me after the disaster happened  )

[magic]

The disk seems alright and the last error in the log is an interface CRC error on the 8th day of operation. So I don't know why the transfer failed.

The partition does indeed point to the space right behind sdd4 and the reminder of the disk is unallocated. The new location overlaps the beginning of the old location, so there is some possibility the original data may have been destroyed, but how and why would that happen is a big mistery

I have never used testdisk but it looks like exactly the sort of tool that should be able to locate the lost old ext4 filesystem, if it's still intact. Note that it begins within the new sdd5 partition, so scanning the unallocated space after sdd5 is not enough.

Heck, sdd5 could now be removed with some tool that doesn't monkey with its contents and only deletes the partition table entry. Its only possible value is that it (hopefully ) tells us the size of the old filesystem and how far from the end of the disk it began.

[PKTKS]

There is no good dd backup.  The dd backup was made after the partition was lost, for just in case some recovery tool might mess it even more.  Should have made the dd backup before running the KDE Partition Manager... 

That is a good point 

Backups after the disaster are hopeless

Paul

[magic]

All partitions are aligned to 2048 sectors (=1MB), which has been common practice for a while.
New sdd5 is 132474880 sectors long.

Assuming that old sdd5 was same size, 1MB-aligned and placed maximally to the right, it should have been in sectors 180105216 to 312580095 if my math is right.

You could create a loop device which covers this region and see what happens.

Code: [Select]

losetup -o $(( 180105216 * 512 )) -s $(( 132474880 * 512 )) -r -f /dev/sdd
file -s /dev/loop0
fsck.ext4 -n /dev/loop0
testdisk /dev/loop0
etc
Photorec is always an option, but rather masochistic one.

You could also try to find who is to blame for the software you used and ask them what happened and how to recover, but the answer may simply be "oughta have had a backup".

[RoGeorge]

Meanwhile I've found out that the USB Kubuntu made a Casper partition on the USB, and it saves there the logs and crash reports at each boot of the USB Kubuntu, so I have all the dmesg, syslog, and .crash files, but I didn't see any errors in the logs.

No idea what's in the .crash files, but there are some .crash files at each USB session.  Apparently the USB Kubuntu is working fine, so I don't know what could be in those .crash reports.

Aren't the .crash reports supposed to be created only when the OS hangs or crashes unrecoverably?   



Others complained recently about partition lost when moved to the left with "KDE Partition Manager" (KPM), including in Kubuntu forums, so I suspect the cause is a software bug, and not a hardware error.

Browsed a little the sources for the KPM, and couldn't understand how it moves the content of an ext 4.  Most probably the KDE is just a frontend GUI calling some backend libraries, and the bug is probably in a backend library and not in the KPM itself, but I'm not a programmer and never wrote in C++ so I might have been jumped to the wrong conclusions here.



My lost partition is from 2019, when Kubuntu 20.04 was still in alfa, so there were a ton of installs and customization, and a few years of unsorted $HOME files.  Usually I am letting files for a while in $HOME, then when something turns into a project I move it from $HOME to another storage disk, but many times I simply forget about what files are lurking in $HOME until I need them again.

Ultimately I care only about the lost $HOME directory, and mostly because of what I don't know I lost.   



About the possible starting sector of the sdd5, yes, the old sdd5 was not yet resized.  KPM told it can't enlarge a partition to its left side, so sdd5 had to be shifted to the left first, and shifting the old sdd5 somehow failed.

So far I didn't try to mount with a manually given offset, thank you, let's see how that goes!   

[RoGeorge]

All partitions are aligned to 2048 sectors (=1MB), which has been common practice for a while.
New sdd5 is 132474880 sectors long.

Assuming that old sdd5 was same size, 1MB-aligned and placed maximally to the right, it should have been in sectors 180105216 to 312580095 if my math is right.

You could create a loop device which covers this region and see what happens.

Code: [Select]

losetup -o $(( 180105216 * 512 )) -s $(( 132474880 * 512 )) -r -f /dev/sdd
file -s /dev/loop0
fsck.ext4 -n /dev/loop0
testdisk /dev/loop0
etc

OMG, IT WORKED, IT WORKED!!!   
magic, you are a genius, 1 000 000 THANK YOU!!!





All I did was to create the loop device with your calculated offset/size, and it appears as an ext4, apparently in good working.  The "file" tool recognizes the newly created /dev/loop55 as an ext4 filesystem, and can be mounted by 'mount'.

Didn't run any fsck yet, but opened some files and they appear to be OK.

Code: [Select]

sudo losetup -o $(( 180105216 * 512 )) --sizelimit $(( 132474880 * 512 )) -r -f /dev/sdd

sudo file -s /dev/loop55
    #  /dev/loop55: Linux rev 1.0 ext4 filesystem data, UUID=a2...ec (extents) (64bit) (large files) (huge files)

sudo mount /dev/loop55 ~/mnt_tst/rec/
(yeah, don't ask, it's loop55 because Ubuntu uses snap, and snap mounts a loop device for every installed program)

You have no idea how happy I am to see all my files back!   

[magic]

Good

Running fsck -n should be safe and it will tell you at once if any metadata are screwed up.
Furthermore, the -r option to losetup means "read only", so it really should be safe.

Then I would back up the partition and move it manually:

Code: [Select]

pv /dev/loop55 >/dev/sdd5
Not sure why testdisk didn't find it

[RoGeorge]

I didn't know about 'pv', very nice tool, thank you!   

Thanks to your help everything was restored on the now bigger partition.  But I don't understand how come that the data was still at the old location, I'm very sure I've heard the disk crunching for about an hour when I initially tried to move the old partition with the KPM's GUI.   

Anyway, I might have accidentally found out why KPM failed in the first place.  Here's what I did today:

- copied from the saved dd backup file to the /dev/sdd5 with 'pv'.  At this point the sdd5 was still small in size, but with ext4 and data placed at the beginning, as it should be
- ext4 had no errors and was able to boot in the recovered Kubuntu.  All was working fine.
- then I wanted to enlarge the sdd5, and since I was having a dd backup of the whole disk, to do that I've used the GUI mode of the KDE Partition Manager, enlarging the same partition I was booted.  The enlarging finished OK, no ext4 error, partition enlarged, the OS still running, and the file exploring was seeing the extra space.  Great!   

There were some OS upgrades waiting, but decided before the upgrade to reboot and check if the OS can boot after its partition was enlarged.  It didn't boot!   

Long story short, one of the tools has told there are more magic signatures, and suggested to use fswipe to manage the file system signatures.  To my total surprise, both the /dev/sdd and the /dev/sdd5 were found to be marked as zfs_member, and not only once, but about 30 times or so each.   

Code: [Select]

~$ sudo wipefs /dev/sdd*
DEVICE OFFSET       TYPE       UUID                                 LABEL
sdd    0x254337f000 zfs_member 10864663617085670887                 rpool
sdd    0x254337e000 zfs_member 10864663617085670887                 rpool
sdd    0x254337d000 zfs_member 10864663617085670887                 rpool
sdd    0x254337c000 zfs_member 10864663617085670887                 rpool
sdd    0x254337b000 zfs_member 10864663617085670887                 rpool
sdd    0x254337a000 zfs_member 10864663617085670887                 rpool
sdd    0x2543379000 zfs_member 10864663617085670887                 rpool
sdd    0x2543378000 zfs_member 10864663617085670887                 rpool
sdd    0x2543377000 zfs_member 10864663617085670887                 rpool
sdd    0x2543376000 zfs_member 10864663617085670887                 rpool
sdd    0x2543375000 zfs_member 10864663617085670887                 rpool
sdd    0x2543374000 zfs_member 10864663617085670887                 rpool
sdd    0x2543373000 zfs_member 10864663617085670887                 rpool
sdd    0x2543372000 zfs_member 10864663617085670887                 rpool
sdd    0x2543371000 zfs_member 10864663617085670887                 rpool
sdd    0x2543370000 zfs_member 10864663617085670887                 rpool
sdd    0x254336f000 zfs_member 10864663617085670887                 rpool
sdd    0x254336e000 zfs_member 10864663617085670887                 rpool
sdd    0x254336d000 zfs_member 10864663617085670887                 rpool
sdd    0x254336c000 zfs_member 10864663617085670887                 rpool
sdd    0x254336b000 zfs_member 10864663617085670887                 rpool
sdd    0x254336a000 zfs_member 10864663617085670887                 rpool
sdd    0x2543369000 zfs_member 10864663617085670887                 rpool
sdd    0x2543368000 zfs_member 10864663617085670887                 rpool
sdd    0x2543367000 zfs_member 10864663617085670887                 rpool
sdd    0x2543366000 zfs_member 10864663617085670887                 rpool
sdd    0x2543365000 zfs_member 10864663617085670887                 rpool
sdd    0x2543364000 zfs_member 10864663617085670887                 rpool
sdd    0x2543363000 zfs_member 10864663617085670887                 rpool
sdd    0x25433bf000 zfs_member 10864663617085670887                 rpool
sdd    0x25433be000 zfs_member 10864663617085670887                 rpool
sdd    0x25433bd000 zfs_member 10864663617085670887                 rpool
sdd    0x25433bc000 zfs_member 10864663617085670887                 rpool
sdd    0x25433bb000 zfs_member 10864663617085670887                 rpool
sdd    0x25433ba000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b9000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b8000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b7000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b6000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b5000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b4000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b3000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b2000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b1000 zfs_member 10864663617085670887                 rpool
sdd    0x25433b0000 zfs_member 10864663617085670887                 rpool
sdd    0x25433af000 zfs_member 10864663617085670887                 rpool
sdd    0x25433ae000 zfs_member 10864663617085670887                 rpool
sdd    0x25433ad000 zfs_member 10864663617085670887                 rpool
sdd    0x25433ac000 zfs_member 10864663617085670887                 rpool
sdd    0x25433ab000 zfs_member 10864663617085670887                 rpool
sdd    0x25433aa000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a9000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a8000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a7000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a6000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a5000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a4000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a3000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a2000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a1000 zfs_member 10864663617085670887                 rpool
sdd    0x25433a0000 zfs_member 10864663617085670887                 rpool
sdd    0x200        gpt                                             
sdd    0x25433d5e00 gpt                                             
sdd    0x1fe        PMBR                                           
sdd1   0x52         vfat       DBF9-92B7                           
sdd1   0x0          vfat       DBF9-92B7                           
sdd1   0x1fe        vfat       DBF9-92B7                           
sdd2   0x36         vfat       1FFB-27B2                           
sdd2   0x0          vfat       1FFB-27B2                           
sdd2   0x1fe        vfat       1FFB-27B2                           
sdd3   0xff6        swap       26......37
sdd4   0x438        ext4       0d......85
sdd5   0x438        ext4       a2......ec
sdd5   0x1c88a7f000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a7e000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a7d000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a7c000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a7b000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a7a000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a79000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a78000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a77000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a76000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a75000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a74000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a73000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a72000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a71000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a70000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a6f000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a6e000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a6d000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a6c000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a6b000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a6a000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a69000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a68000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a67000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a66000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a65000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a64000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88a63000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88abf000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88abe000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88abd000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88abc000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88abb000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aba000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab9000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab8000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab7000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab6000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab5000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab4000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab3000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab2000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab1000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88ab0000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aaf000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aae000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aad000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aac000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aab000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aaa000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa9000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa8000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa7000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa6000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa5000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa4000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa3000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa2000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa1000 zfs_member 10864663617085670887                 rpool
sdd5   0x1c88aa0000 zfs_member 10864663617085670887                 rpool


That explains why gparted was always showing the whole disk as zfs, and why some other tools might have been confused, including the KDE Partition Manager.

I did tried once to install Gentoo using zfs for root and failed, but re-partitioned many times since then.   

After removing all the zfs_member signatures, I kept all the other signatures, first 2 FAT partitions still have more than one signature, but I let them there, not very sure why they are 3 magic numbers, same for the whole disk. 

Code: [Select]

DEVICE OFFSET       TYPE       UUID                                 LABEL
sdd    0x200        gpt                                             
sdd    0x25433d5e00 gpt                                             
sdd    0x1fe        PMBR                                           
sdd1   0x52         vfat       DBF9-92B7                           
sdd1   0x0          vfat       DBF9-92B7                           
sdd1   0x1fe        vfat       DBF9-92B7                           
sdd2   0x36         vfat       1FFB-27B2                           
sdd2   0x0          vfat       1FFB-27B2                           
sdd2   0x1fe        vfat       1FFB-27B2                           
sdd3   0xff6        swap       26......37
sdd4   0x438        ext4       0d......85
sdd5   0x438        ext4       a2......ec


With all those "zfs_member" markings, I tried again and the KDE Partition Manager was able to enlarge the running ext4 OS of the sdd5 from GUI mode, and bootable.