Computing > General Computing

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

(1/3) > >>

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

There was an error while thanking
Thanking...
Go to full version