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:
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
Edit: SOLVED
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!
https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
Regards / Jesper