[solved] OS partition lost after move and resize with "KDE Partition Manager" - Page 1
Forum section: electronics / general

author: RoGeorge
author_rank: Super Contributor
timestamp: June 14, 2021, 04:33:59 pm
content: 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 diskOn 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 partitionSteps that ended in error- moving the sdd5 to the left, so to start where the now smaller sdd4 endsSteps not yet performed- enlarge moved sdd5 to occupy all the empty space up to the end of the diskI 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 partitionzfsfilesystem - 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?

author: SeanB
author_rank: Super Contributor
timestamp: June 14, 2021, 04:53:47 pm
content: 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.

author: magic
author_rank: Super Contributor
timestamp: June 15, 2021, 09:39:47 am
content: Code:fdisk -l /dev/sddgdisk -l /dev/sddfile -s /dev/sdd*smartctl -a /dev/sddIf 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 toCode: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

author: PKTKS
author_rank: Super Contributor
timestamp: June 15, 2021, 11:30:41 am
content: Quote from: RoGeorge on June 14, 2021, 04:33:59 pmMAKE DEAD SURE YOU ARE AWARE THAT THIS IS DESTRUCTIVEONE WAY ONLY AND NOT NEWBIE STUFFExcellent 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:sfdisk MY_SCREWED_PARTITION_DEVICE < sfdisk --dump MY_GOOD_BACKUP_RAW_IMAGEMe in particular case as for experience would do therestoration of data on the restored partition by usinga safe method.Some alternatives possible:- Using an exported NBD logical device from the GOOD_BACKso only the partition number would be mounted and restores..- Using a raw disk image mount from the GOOD BACKUP deviceThe NBD method allows direct dd of the desired partitionBut honestly I would go re-formatting the restored partitionand rsyncing the data...MAKE DEAD SURE YOU ARE AWARE THAT THIS IS DESTRUCTIVEONE WAY ONLY AND NOT NEWBIE STUFFYou may for the sake of security do that in stepsCode:sfdisk --dump MY_GOOD_BACKUP_DEVICE.raw > xxx_device.sfsfdisk MY_SCREWED_PARTITION_DEVICE < xxx_device.sfsfdisk -l MY_SCREWED_PARTITION_DEVICEAfter that you should be able to handle the screwed partitionPaul

author: RoGeorge
author_rank: Super Contributor
timestamp: June 15, 2021, 01:45:30 pm
content: 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 outputCode:sudo fdisk -l /dev/sdd password for muuu:Disk /dev/sdd: 149.1 GiB, 160041885696 bytes, 312581808 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: 4B...3FDevice 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 filesystemgdisk outputCode:sudo gdisk -l /dev/sddGPT fdisk (gdisk) version 1.0.3Partition table scan:MBR: protectiveBSD: not presentAPM: not presentGPT: presentFound valid GPT with protective MBR; using GPT.Disk /dev/sdd: 312581808 sectors, 149.0 GiBModel: ST3160023ASSector size (logical/physical): 512/512 bytesDisk identifier (GUID): 4B...3FPartition table holds up to 128 entriesMain partition table begins at sector 2 and ends at sector 33First usable sector is 34, last usable sector is 312581774Partitions will be aligned on 2048-sector boundariesTotal free space is 106886765 sectors (51.0 GiB)Number Start (sector) End (sector) Size Code Name1 2048 6143 2.0 MiB 0700 grub2 6144 268287 128.0 MiB EF00 boot3 268288 1316863 512.0 MiB 8300 swap4 1316864 73222143 34.3 GiB 8300 rootfs5 73222144 205697023 63.2 GiB 8300file outputCode: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: datasmartctl outputCode:sudo smartctl -a /dev/sddsmartctl 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=== START OF INFORMATION SECTION ===Model Family: Seagate Barracuda 7200.7 and 7200.7 PlusDevice Model: ST3160023ASSerial Number: 3......3Firmware Version: 3.18User Capacity: 160,041,885,696 bytes [160 GB]Sector Size: 512 bytes logical/physicalDevice is: In smartctl database [for details use: -P show]ATA Version is: ATA/ATAPI-6 T13/1410D revision 2Local Time is: Tue Jun 15 15:19:33 2021 EESTSMART support is: Available - device has SMART capability.SMART support is: Enabled=== START OF READ SMART DATA SECTION ===SMART overall-health self-assessment test result: PASSEDGeneral SMART Values:Offline data collection status: (0x82)Offline data collection activitywas completed without error.Auto Offline Data Collection: Enabled.Self-test execution status: ( 0)The previous self-test routine completedwithout error or no self-test has everbeen run.Total time to complete Offlinedata collection:( 430) seconds.Offline data collectioncapabilities:(0x5b) SMART execute Offline immediate.Auto Offline data collection on/off support.Suspend Offline collection upon newcommand.Offline surface scan supported.Self-test supported.No Conveyance Self-test supported.Selective Self-test supported.SMART capabilities: (0x0003)Saves SMART data before enteringpower-saving mode.Supports SMART auto save timer.Error logging capability: (0x01)Error logging supported.No General Purpose Logging support.Short self-test routinerecommended polling time:( 1) minutes.Extended self-test routinerecommended polling time:( 111) minutes.SMART Attributes Data Structure revision number: 10Vendor Specific SMART Attributes with Thresholds:ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE1 Raw_Read_Error_Rate 0x000f 061 052 006 Pre-fail Always - 941510133 Spin_Up_Time 0x0003 096 096 000 Pre-fail Always - 04 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 2215 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 07 Seek_Error_Rate 0x000f 086 060 030 Pre-fail Always - 4260888339 Power_On_Hours 0x0032 049 049 000 Old_age Always - 4476910 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 012 Power_Cycle_Count 0x0032 090 090 020 Old_age Always - 10803194 Temperature_Celsius 0x0022 043 060 000 Old_age Always - 43195 Hardware_ECC_Recovered 0x001a 061 051 000 Old_age Always - 94151013197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0199 UDMA_CRC_Error_Count 0x003e 200 188 000 Old_age Always - 49200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0202 Data_Address_Mark_Errs 0x0032 100 253 000 Old_age Always - 0SMART Error Log Version: 1ATA Error Count: 66 (device log contains only the most recent five errors)CR = Command Register FR = Features Register SC = Sector Count Register SN = Sector Number Register CL = Cylinder Low Register CH = Cylinder High Register DH = Device/Head Register DC = Device Command Register ER = Error register ST = Status register Powered_Up_Time is measured from power on, and printed asDDd+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 = 5448690Commands 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 EXT25 00 49 b7 22 53 e0 00 02:23:24.515 READ DMA EXT25 00 5f 80 0d 53 e0 00 02:23:24.515 READ DMA EXT25 00 28 97 ca 52 e0 00 02:23:24.513 READ DMA EXT25 00 10 80 a1 52 e0 00 02:23:24.513 READ DMA EXTError 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 = 1355790Commands 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 EXT25 00 08 37 b9 14 e0 00 02:20:41.775 READ DMA EXT25 00 08 77 b0 14 e0 00 02:20:41.774 READ DMA EXT25 00 08 97 b1 14 e0 00 02:20:42.035 READ DMA EXT25 00 08 8f b1 14 e0 00 02:20:42.032 READ DMA EXTError 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 = 1369983Commands 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 EXT25 00 08 17 8d 15 e0 00 02:08:22.437 READ DMA EXT25 00 80 80 e6 14 e0 00 02:08:22.433 READ DMA EXT25 00 80 00 e6 14 e0 00 02:08:22.432 READ DMA EXT25 00 08 8f 8b 15 e0 00 02:08:22.432 READ DMA EXTError 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 = 12673529Commands 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 EXT25 00 12 80 61 c1 e0 00 00:58:36.811 READ DMA EXT25 00 69 17 61 c1 e0 00 00:58:36.810 READ DMA EXT25 00 29 d7 60 c1 e0 00 00:58:36.808 READ DMA EXT25 00 57 80 60 c1 e0 00 00:58:36.808 READ DMA EXTError 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 = 4912270Commands 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 EXT25 00 71 0f f4 4a e0 00 00:23:36.227 READ DMA EXT25 00 08 3f f3 4a e0 00 00:23:36.227 READ DMA EXT25 00 30 0f f3 4a e0 00 00:23:36.226 READ DMA EXT25 00 0f 00 f3 4a e0 00 00:23:36.226 READ DMA EXTSMART Self-test log structure revision number 1Num 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 1SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS1 0 0 Not_testing2 0 0 Not_testing3 0 0 Not_testing4 0 0 Not_testing5 0 0 Not_testingSelective 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)

author: magic
author_rank: Super Contributor
timestamp: June 15, 2021, 02:26:09 pm
content: 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 misteryI 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.

author: PKTKS
author_rank: Super Contributor
timestamp: June 15, 2021, 02:41:08 pm
content: Quote from: RoGeorge on June 15, 2021, 01:45:30 pmThat is a good pointBackups after the disaster are hopelessPaul

author: magic
author_rank: Super Contributor
timestamp: June 16, 2021, 08:32:13 am
content: 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:losetup -o $(( 180105216 * 512 )) -s $(( 132474880 * 512 )) -r -f /dev/sddfile -s /dev/loop0fsck.ext4 -n /dev/loop0testdisk /dev/loop0etcPhotorec 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".

author: RoGeorge
author_rank: Super Contributor
timestamp: June 16, 2021, 06:45:50 pm
content: 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 Idon'tknow 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!

author: RoGeorge
author_rank: Super Contributor
timestamp: June 16, 2021, 08:13:49 pm
content: Quote from: magic on June 16, 2021, 08:32:13 amOMG, 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:sudo losetup -o $(( 180105216 * 512 )) --sizelimit $(( 132474880 * 512 )) -r -f /dev/sddsudo 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!

author: magic
author_rank: Super Contributor
timestamp: June 16, 2021, 09:49:45 pm
content: GoodRunningfsck -nshould be safe and it will tell you at once if any metadata are screwed up.Furthermore, the-roption tolosetupmeans "read only", so it really should be safe.Then I would back up the partition and move it manually:Code:pv /dev/loop55 >/dev/sdd5Not sure why testdisk didn't find it

author: RoGeorge
author_rank: Super Contributor
timestamp: June 18, 2021, 02:09:39 am
content: 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:~$ sudo wipefs /dev/sdd*DEVICE OFFSET TYPE UUID LABELsdd 0x254337f000 zfs_member 10864663617085670887 rpoolsdd 0x254337e000 zfs_member 10864663617085670887 rpoolsdd 0x254337d000 zfs_member 10864663617085670887 rpoolsdd 0x254337c000 zfs_member 10864663617085670887 rpoolsdd 0x254337b000 zfs_member 10864663617085670887 rpoolsdd 0x254337a000 zfs_member 10864663617085670887 rpoolsdd 0x2543379000 zfs_member 10864663617085670887 rpoolsdd 0x2543378000 zfs_member 10864663617085670887 rpoolsdd 0x2543377000 zfs_member 10864663617085670887 rpoolsdd 0x2543376000 zfs_member 10864663617085670887 rpoolsdd 0x2543375000 zfs_member 10864663617085670887 rpoolsdd 0x2543374000 zfs_member 10864663617085670887 rpoolsdd 0x2543373000 zfs_member 10864663617085670887 rpoolsdd 0x2543372000 zfs_member 10864663617085670887 rpoolsdd 0x2543371000 zfs_member 10864663617085670887 rpoolsdd 0x2543370000 zfs_member 10864663617085670887 rpoolsdd 0x254336f000 zfs_member 10864663617085670887 rpoolsdd 0x254336e000 zfs_member 10864663617085670887 rpoolsdd 0x254336d000 zfs_member 10864663617085670887 rpoolsdd 0x254336c000 zfs_member 10864663617085670887 rpoolsdd 0x254336b000 zfs_member 10864663617085670887 rpoolsdd 0x254336a000 zfs_member 10864663617085670887 rpoolsdd 0x2543369000 zfs_member 10864663617085670887 rpoolsdd 0x2543368000 zfs_member 10864663617085670887 rpoolsdd 0x2543367000 zfs_member 10864663617085670887 rpoolsdd 0x2543366000 zfs_member 10864663617085670887 rpoolsdd 0x2543365000 zfs_member 10864663617085670887 rpoolsdd 0x2543364000 zfs_member 10864663617085670887 rpoolsdd 0x2543363000 zfs_member 10864663617085670887 rpoolsdd 0x25433bf000 zfs_member 10864663617085670887 rpoolsdd 0x25433be000 zfs_member 10864663617085670887 rpoolsdd 0x25433bd000 zfs_member 10864663617085670887 rpoolsdd 0x25433bc000 zfs_member 10864663617085670887 rpoolsdd 0x25433bb000 zfs_member 10864663617085670887 rpoolsdd 0x25433ba000 zfs_member 10864663617085670887 rpoolsdd 0x25433b9000 zfs_member 10864663617085670887 rpoolsdd 0x25433b8000 zfs_member 10864663617085670887 rpoolsdd 0x25433b7000 zfs_member 10864663617085670887 rpoolsdd 0x25433b6000 zfs_member 10864663617085670887 rpoolsdd 0x25433b5000 zfs_member 10864663617085670887 rpoolsdd 0x25433b4000 zfs_member 10864663617085670887 rpoolsdd 0x25433b3000 zfs_member 10864663617085670887 rpoolsdd 0x25433b2000 zfs_member 10864663617085670887 rpoolsdd 0x25433b1000 zfs_member 10864663617085670887 rpoolsdd 0x25433b0000 zfs_member 10864663617085670887 rpoolsdd 0x25433af000 zfs_member 10864663617085670887 rpoolsdd 0x25433ae000 zfs_member 10864663617085670887 rpoolsdd 0x25433ad000 zfs_member 10864663617085670887 rpoolsdd 0x25433ac000 zfs_member 10864663617085670887 rpoolsdd 0x25433ab000 zfs_member 10864663617085670887 rpoolsdd 0x25433aa000 zfs_member 10864663617085670887 rpoolsdd 0x25433a9000 zfs_member 10864663617085670887 rpoolsdd 0x25433a8000 zfs_member 10864663617085670887 rpoolsdd 0x25433a7000 zfs_member 10864663617085670887 rpoolsdd 0x25433a6000 zfs_member 10864663617085670887 rpoolsdd 0x25433a5000 zfs_member 10864663617085670887 rpoolsdd 0x25433a4000 zfs_member 10864663617085670887 rpoolsdd 0x25433a3000 zfs_member 10864663617085670887 rpoolsdd 0x25433a2000 zfs_member 10864663617085670887 rpoolsdd 0x25433a1000 zfs_member 10864663617085670887 rpoolsdd 0x25433a0000 zfs_member 10864663617085670887 rpoolsdd 0x200 gptsdd 0x25433d5e00 gptsdd 0x1fe PMBRsdd1 0x52 vfat DBF9-92B7sdd1 0x0 vfat DBF9-92B7sdd1 0x1fe vfat DBF9-92B7sdd2 0x36 vfat 1FFB-27B2sdd2 0x0 vfat 1FFB-27B2sdd2 0x1fe vfat 1FFB-27B2sdd3 0xff6 swap 26......37sdd4 0x438 ext4 0d......85sdd5 0x438 ext4 a2......ecsdd5 0x1c88a7f000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a7e000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a7d000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a7c000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a7b000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a7a000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a79000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a78000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a77000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a76000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a75000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a74000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a73000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a72000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a71000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a70000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a6f000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a6e000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a6d000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a6c000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a6b000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a6a000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a69000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a68000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a67000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a66000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a65000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a64000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88a63000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88abf000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88abe000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88abd000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88abc000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88abb000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aba000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab9000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab8000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab7000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab6000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab5000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab4000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab3000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab2000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab1000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88ab0000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aaf000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aae000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aad000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aac000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aab000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aaa000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa9000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa8000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa7000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa6000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa5000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa4000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa3000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa2000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa1000 zfs_member 10864663617085670887 rpoolsdd5 0x1c88aa0000 zfs_member 10864663617085670887 rpoolThat 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:DEVICE OFFSET TYPE UUID LABELsdd 0x200 gptsdd 0x25433d5e00 gptsdd 0x1fe PMBRsdd1 0x52 vfat DBF9-92B7sdd1 0x0 vfat DBF9-92B7sdd1 0x1fe vfat DBF9-92B7sdd2 0x36 vfat 1FFB-27B2sdd2 0x0 vfat 1FFB-27B2sdd2 0x1fe vfat 1FFB-27B2sdd3 0xff6 swap 26......37sdd4 0x438 ext4 0d......85sdd5 0x438 ext4 a2......ecWith 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.