5

I have an encrypted install (Full drive, not only home directory) of Ubuntu 14.04 on a 1TB SSD. I do know the passkey to unencrypt everything. It's just a matter of finding the files now. Here's what happened; Yesterday, on the same computer where that SSD is installed, I plugged in another SSD with a fresh install of Windows 7 Ultimate to test a Windows keyboard to see if it worked. It did, so I finished with that (did not touch the Ubuntu SSD), shut down the computer, unplugged the SSD with Windows 7 and then proceeded to boot as normal. As soon as I did that, I got put into Grub Rescue "Entering rescue mode..." and have been stuck in it ever since. I've been looking around Google all morning to try to find a solution to get back into Ubuntu but I'm stumped. Here's what I've tried as far as commands in grub rescue, and what they return:

grub rescue> ls
(hd0) (hd0,msdos5) (hd0,msdos1)

grub rescue> ls (hd0)
(hd0): Filesystem is unknown.

grub rescue> ls (hd0,msdos1)
(hd0,msdos1): Filesystem is ntfs.

grub rescue> ls (hd0,msdos5)
(hd0,msdos5): Filesystem is ntfs.

grub rescue> ls (hd0,5)/boot
error: file '/boot' not found.

grub rescue> ls (hd0,1)/boot
error: file '/boot' not found.

grub rescue> ls (hd0,msdos5)/boot
error: file '/boot' not found.

grub rescue> ls (hd0,msdos1)/boot
error: file '/boot' not found.

I did try running the Recommended Repair from a Boot-Repair-Disk and nothing changed even though the application said the process was successful. I am not trying to dual boot this system and Ubuntu was the only thing on this SSD. At this point, I'm just trying to recover my files.

This is the /dev/sda I'm trying to recover:

$ sudo fdisk -l
Disk /dev/ram0: 64 MiB, 67108864 bytes, 131072 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/ram1: 64 MiB, 67108864 bytes, 131072 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/ram2: 64 MiB, 67108864 bytes, 131072 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/ram3: 64 MiB, 67108864 bytes, 131072 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/ram4: 64 MiB, 67108864 bytes, 131072 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/ram5: 64 MiB, 67108864 bytes, 131072 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/ram6: 64 MiB, 67108864 bytes, 131072 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/ram7: 64 MiB, 67108864 bytes, 131072 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/ram8: 64 MiB, 67108864 bytes, 131072 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/ram9: 64 MiB, 67108864 bytes, 131072 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/ram10: 64 MiB, 67108864 bytes, 131072 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/ram11: 64 MiB, 67108864 bytes, 131072 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/ram12: 64 MiB, 67108864 bytes, 131072 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/ram13: 64 MiB, 67108864 bytes, 131072 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/ram14: 64 MiB, 67108864 bytes, 131072 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/ram15: 64 MiB, 67108864 bytes, 131072 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/loop0: 1.3 GiB, 1433468928 bytes, 2799744 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




Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 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: dos
Disk identifier: 0x2ca9a8a1

Device     Boot   Start        End    Sectors  Size Id Type
/dev/sda1  *       2048     999423     997376  487M  7 HPFS/NTFS/exFAT
/dev/sda2       1001470 1953523711 1952522242  931G  5 Extended
/dev/sda5       1001472 1953523711 1952522240  931G  7 HPFS/NTFS/exFAT

I have tried ecryptfs recovery through a LiveCD USB drive (within Trying Ubuntu) and gotten this:

$ sudo ecryptfs-recover-private
INFO: Searching for encrypted private directories (this might take a while)...
find: '/run/user/999/gvfs': Permission denied
find: File system loop detected; 'sys/kernal/debug/pinctrl' is part of the same file system loop as '/sys/kernal/debug'.

It looks like it doesn't want to find the encrypted files. When I try to browse the drive, all I see are $RECYCLE.BIN and System Volume Information folders. I had about half the drive full of stuff, so I'm looking at about a 500GB recovery if we can find my stuff. Can anyone please help?

J. Forest
  • 51
  • This is wiered - Windows 7 shouldn't destroy the contents of Linux partitions. However, check this, and one of the possibilities there might work (check TestDisk especially). I hope you have a backup. – Jonas Czech Jun 27 '16 at 11:39
  • Hi, thank you for your answer. I did not have a backup. I don't know why just booting into Windows 7 blasted everything on the other SSD, but it seems to look like that's what happened. I will be trying those tools in the coming days and if nothing works, I'll be looking into possible data recovery services to see if anything can be salvaged. In any means, I'm pissed this happened as it was half a terabyte of data I lost. – J. Forest Jun 29 '16 at 06:37

1 Answers1

0

Was it encrypted using LUKS? I've got Ubuntu 14.04 running in a LUKS container on an SSD. With it up and running /boot is not encrypted, but everything else is. So df -h reports /dev/sda1 as the source of /boot and /dev/dm-1 as the source of /. The actual container for dm-1 is /dev/sda5

If you do have LUKS, you should be able to boot to a rescue disk, and use cryptsetup to access it. 

cryptsetup open <device> <mapping name>

is used to open devices (so would allow me to mount /dev/sda5 from a system booted via LiveCD)

cryptsetup isLuks <device> will tell you if the device is LUKS

cryptsetup repair <device> might fix your partition. Personally, I have take and emailed myself encrypted copies of the luks header, so I can still repair the disk if the header gets corrupted.

What do you see in /proc/partitions on a LiveCD? It looks to me as though you have the same partition setup as me, although different partition types.

You may find that sda1 is in fact /boot and sda5 is your encrypted drive. On my system fdisk reports that sda1 and sda5 are Id 83. Yours has changed that to 7. You should be able to change them back, without damaging any data. If they're wrong, it can confuse the boot loader, as seems to be happening in your case.
fdisk /dev/sda t 1 83 t 5 83 w q should test things. If it works, you should be able to reboot, as did originally. If not run it again, and change the type back to 7 on partitions 1 and 5, and you're back where you started.

sibaz
  • 793
  • 1
  • 7
  • 20