Products > Computers
[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: ---fdisk -l /dev/sdd
gdisk -l /dev/sdd
file -s /dev/sdd*
smartctl -a /dev/sdd
--- End code ---
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: ---dd </dev/sdd >/dev/sdd skip=old_offset seek=new_offset
--- End code ---
If 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 |O
PKTKS:
--- Quote from: RoGeorge on June 14, 2021, 04:33:59 pm ---
So far I've "dd"-ed the entire /dev/sdd disk to a file on another HDD as a crude backup.
Now what?
--- End quote ---
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: ---
sfdisk MY_SCREWED_PARTITION_DEVICE < sfdisk --dump MY_GOOD_BACKUP_RAW_IMAGE
--- End code ---
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: ---sfdisk --dump MY_GOOD_BACKUP_DEVICE.raw > xxx_device.sf
sfdisk MY_SCREWED_PARTITION_DEVICE < xxx_device.sf
sfdisk -l MY_SCREWED_PARTITION_DEVICE
--- End code ---
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: ---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
--- End code ---
gdisk output
--- Code: ---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
--- End code ---
file output
--- Code: ---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
--- End code ---
smartctl output
--- Code: ---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.
--- End code ---
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 ;D )
Navigation
[0] Message Index
[#] Next page
Go to full version