A couple of weeks ago I bought a new laptop with a fast but small SSD. I also ordered a HDD-caddy so I could replace the DVD-drive with the old, slow but large HDD from the previous laptop, to use as my /home partition. Since my old laptop had a broken screen I couldn't wait for the delivery of the caddy, so I installed Linux Mint (LM) 18.2 and started to use the new machine immediately. This meant that when I got the caddy I had some items in my new laptop's /home folder that i needed, so after the quick and painless install of the old HDD I copied them to the old /home folder there. It is possible - but very unlikely - that I forgot to eject the HDD after copying before shutting down. After reboot though the laptop couldn't find LM (which was the only OS on it). No problems I thought - I've already copied all that's important to the old HDD, so I just make a fresh install and all should be well. I used the same USB-thumbdrive (unaltered) that I'd used the last install, and it went without a hitch. When prompted I choose to install in the SSD (I made very sure it was indeed the SSD, I even rolled down the list of possible installation devices to make sure that both the HDD and SSD was present before I explicitly choose the SSD), I also choose to use lvm (which also was used in both the previous install on the SSD and the old HDD) and I made no alterations to LM's default installation partitioning. After reboot all was well, but for the HDD. It was found, but unmountable! I then hoped that a newer kernel might help, so I updated to LM 18.3 through the Update Manager (which is also the version I had on it before the crash) but to no avail.
I do have a back up of the /home folder but it is hopelessly out of date. I know, my fault, it's stupid and so on, but since I became a parent I've cut some corners where I havn't previously seen the downsides of doing so, in order to actually have some time with my kids (and sometimes to stop them from burning the house down). This seems to be one corner I shouldn't have cut, but that's difficult to know beforehand...
Here is the output from some commands that I thought might be helpful:
The GUIs says about the same thing:
Code: Select all
jesper@asimov ~ $ sudo fdisk -l [sudo] password for jesper: Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 6E7C135E-B649-4502-9060-87190451201E Device Start End Sectors Size Type /dev/sda1 2048 1050623 1048576 512M EFI System /dev/sda2 1050624 2050047 999424 488M Linux filesystem /dev/sda3 2050048 250068991 248018944 118,3G Linux LVM Disk /dev/sdb: 698,7 GiB, 750156374016 bytes, 1465149168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x77f897a3 Disk /dev/mapper/mint--vg-root: 110,8 GiB, 118975627264 bytes, 232374272 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/mapper/mint--vg-swap_1: 7,5 GiB, 8006926336 bytes, 15638528 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes jesper@asimov ~ $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 698,7G 0 disk sda 8:0 0 119,2G 0 disk ├─sda2 8:2 0 488M 0 part /boot ├─sda3 8:3 0 118,3G 0 part │ ├─mint--vg-swap_1 253:1 0 7,5G 0 lvm [SWAP] │ └─mint--vg-root 253:0 0 110,8G 0 lvm / └─sda1 8:1 0 512M 0 part /boot/efi jesper@asimov ~ $ sudo blkid [sudo] password for jesper: /dev/sda1: UUID="E461-C256" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="d4bafdbf-a6a3-4810-b870-3b8e3718766b" /dev/sda2: UUID="c80ac5eb-1803-4806-8230-4f53bcea6fa3" TYPE="ext2" PARTUUID="cedc27d2-f2be-4244-ae6a-26f194e9a5a8" /dev/sda3: UUID="FK1maf-4k5J-gdB4-tMbl-XbbS-TfMc-Rmk9dN" TYPE="LVM2_member" PARTUUID="d54df4b2-976d-4dd6-a9c4-049349e906ce" /dev/mapper/mint--vg-root: UUID="2978e8ad-2942-47c7-b2cf-4c29e5598dc3" TYPE="ext4" /dev/sdb: PTUUID="77f897a3" PTTYPE="dos" /dev/mapper/mint--vg-swap_1: UUID="7dbbcc90-0537-4706-b869-f880dedfac30" TYPE="swap" jesper@asimov ~ $ sudo vgs VG #PV #LV #SN Attr VSize VFree mint-vg 1 2 0 wz--n- 118,26g 0 jesper@asimov ~ $ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root mint-vg -wi-ao---- 110,80g swap_1 mint-vg -wi-ao---- 7,46g jesper@asimov ~ $ sudo pvs PV VG Fmt Attr PSize PFree /dev/sda3 mint-vg lvm2 a-- 118,26g 0
- Nemo finds the HDD and displays it in the "Computer" folder, but when double clicked it will just say that the "file" can't be mounted. It isn't displayed among the removable devices.
- Gparted finds it, but all it says is that it's called sdb, is completely unallocated and is this big and contains thus many sectors. On right click all options are greyed out apart from "New" and "Information" (the latter only containing the info related above).
- system-config-lvm crashes most of the time, but when it's up long enough it'll say about the same as the cli commands vgs, lvs and pvs (it can't find it at all).
Regards / Jesper
By using the guide in the following link I repaired the partitions and it now works as it should (or at least as it did, but the problems are not related to this question). It's actually easy to use testdisk (at least with that step-by-step...) and I recommend anyone with similar problems to give it a go. And remember: DON'T WRITE ANYTHING TO A DISC YOU'RE TRYING TO RESCUE!
Regards / Jesper