Score:0

How can I recover files from a broken dual boot installation?

at flag

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.

Score:0
cn flag

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).

Alex avatar
at flag
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 ?
vanadium avatar
cn flag
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`).
Alex avatar
at flag
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 avatar
at flag
I've reported about my attempt in an edit
Score:0
at flag

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.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.