0

I have an MSI GL73-8RD with an SSD and an HDD. I installed windows on the SSD with some files stored in the HDD, then partitioned the HDD and installed Ubuntu 18.04 there.

Later on, Ubuntu was upgraded to 20.04. I just had to click a prompt. Apparently this resulted in 20.04 being installed alongside 18.04, but for some reason I can't use my password on the 18.04 installation anymore.

Moreover, after a windows update, 20.04 would only launch in emergency mode. I checked several gotchas and then found in the logs that there was an issue with the partition /dev/sda7. I ran fsck on this partition, and now 20.04 won't boot even in recovery mode. Windows 10 and 18.04 still start fine however.

There are important files I need to recover from the failed Ubuntu install. I think the hardware is fine, so the files should still be there. HOw do I go about this ?

Do I first copy the content of the HDD as a safety precaution and then try to recover the files with a live usb stick ?

Are there specific tools dedicated to this problem ? I know there are tools dedicated to data recovery, but I don't know which would be the right one.

EDIT

Following the recommendations from @vanadium, I booted on a live USB stick and tried to mount the partitions. Because my installation is very dirty, there are two windows related partitions which work fine, a location named "Computer" and three unnamed volumes, /dev/sda4-5-7.

I tried to mount them, unfortunately the one that seems to contain my data is /dev/sda7 and it cannot be mounted.

@vanadium pointed to Testdisc and Photorec as potential alternatives. I'm looking for specific guidance on these tools.

Alex
  • 1
  • 4

2 Answers2

0

It will depend on what the damage is with the file system and eventually the partition. Even if the system will not boot, the file system may still be readable.

I would start a live session from an installation DVD or USB, and then try to mount the volume where the files are in read only mode. If that succeeds, you will be able to copy the files off to another hard drive without needing to resort to more advanced recovery.

If it fails, then unfortunately the damage is severe, and you may need to resort to advanced data recovery. Tools like Testdisk and Photorec allow for some repair of partitions (Testdisk) and recovery of files from the binary data on the disks (Photorec).

vanadium
  • 88,010
  • Thank you very much. Can you expand on 'mount the volume where the files are in read-only mode' ? How can I check which volume is in read-only mode ? Or do you mean to say I should mount it in read_only mode ? – Alex Sep 09 '21 at 09:14
  • I added a link: you need to mount using the terminal: it is a matter of including the option -o ro. ro means "read-only". The answer indicates to add the noload option, but I would not include that in a first attempt - it is an option not to read the journal (see man ext4). – vanadium Sep 09 '21 at 09:29
  • Understood. I cannot try that right away, I should be able to give it a try on Saturday. I'll keep you posted and accepyour answer if it goes well. Thanks again ! – Alex Sep 09 '21 at 09:42
  • I've reported about my attempt in an edit – Alex Sep 09 '21 at 17:19
0

So, after trying the solution proposed by @vanadium to no avail, I reasoned that in the absence of shock to the drive or creaky noises, and given the fact that I had interrupted a windows update, this was probably a logical failure caused by an I/O error.

I burned a live USB stick with SystemRescueCD, a special purpose linux distribution which comes with utilities useful when trying to fix an installation.

I first used ddrescue with the option -n to copy the damaged partition to an external hard drive which I call the clean copy. -n allows for a first quick pass and minimizes damage to the reading head. As I conjectured, I was able to read 100% of the bytes in the partition.

I then used dd to copy the clean copy on a second external hard drive, the working copy. This ensures that if any work I do on the working copy is destructive, I can go back to the clean copy without having to copy from a potentially failing drive.

I then ran TestDisk on the partition located on the working copy. Following the menu, I selected the partition, and TestDisk provided me with a list of the superbloxks in the failed filesystem.

Superblocks are the blocks in memory containing the metadata about the structure of the filesystem. TestDisk detected that the file system was an ext4 filesystem and proposed a command to fix the filesystem : fsck.ext4 -p -b <start of superblock> -B <size of superblock> /path/to/working/copy

The arguments <start of superblock> and <size of superblock> were taken from the output of TestDisk.

After running this command, the first superblock which had been corrupted was fixed, and the files were accessible in their entirety. I then backed them up on a third hard drive which I usually used for Windows backups.

Total cost : roughly 200$ to acquire the external hard drives. A data recovery company had quoted me 800$ to do this job.

Alex
  • 1
  • 4