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

Software & Operating Systems Linux
, ,
1

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.

I booted on a live USB stick and tried to mount the partitions in read_only. 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.

2

Response from Ubuntu community.

TLDR Ubnutu upgrade issue, then windows update broke your boot on Ubuntu.

You try and crack your password on the 18.04 and recovering the files there?

3

Yes this is my post on the Ubuntu community. I followed the recommendations there but it did not pan out. Are there flags when requests are reposted from askubuntu ?

From what I understand the 18.04 is on another partition. If I could not mount the broken partition from the live USB stick, I don’t see why I could from the 18.04.

4

You said you didnt know the password to that one not that it couldnt be booted anymore just that the 20.04 couldnt be booted

1 Like
5

Yes, I can still boot on the 18.04 which looks like it is installed in a separate partition. I do not know the password though, so I’m stuck at the login screen. Instead of trying to crack it, I booted on a live distro on a USB stick. Isn’t that the same ? What I am saying is I don’t see the point of cracking it.

6

Is it possible that by logging in the previous 18.04 install I will be able to recover my file ? If so, I’ll try some of my common passwords.

7

Do they share the same user storage space?
Are the needed files just on the 20.04 user storage space or on the 18 if that one still exists

8

I could not tell. This was my first linux setup and it worked for 2 years until it didn’t.

9

It is possible they are still on the 18.04, I did not consider it.
Although I mounted every possible partition and could not find the data anywhere.

10

Pull the windows drive, then try and fix the grub bootloader?

https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows

Then get files and redo the linux install after you put the windows drive back in

11

Pull the windows drive as in disconnect it ? It is a ssd in a laptop, I’m not sure I can do that. Would running boot repair without unplugging the windows drive do the trick ?

12

Indeed, I intended to redo a clean install after having retrieved the data.

13

You can pull the drive and just leave the one in there. Just remove the bottom plate and disconnect the ssd its probably a m.2 if you have a ssd and hdd

1 Like
14

Thank you for your input, I will try this.

1 Like
15

I am confused here. I did not look at the other post.

Riddle me this, Batman. How did you end up with a separate installation of Ubuntu. If you upgraded from 18.04 to 20.04, then it would not have installed to a new location.

Can you present the instructions that you followed to do this?

Also, if you use the Live Distro from the USB stick, could you do something like lsblk --fs so that we can see what disks are in the system and what they are partitioned for. It could be that uEFI got messed up in one of the updates and is pointing to the wrong drive (which is why you should always use UUIDs instead of block device paths).

16

Honestly I’m confused as well. I am a fairly novice user and I don’t understand everything/have probably made a nonsensical install.

I remember being prompted for an upgrade, but I also remember repartitioning the disk. I think I wanted to play it safe with a separate partition. It was 6 months + ago so I don’t think that is an issue, but rather that the windows update broke something.

At any rate, I’ve sent my computer to a data recovery company, I’m waiting for them to quote me a price. If they can’t deal with the issue I’ll do what you suggested and update here. Thank you very much for your help.

17

sounds to me like you could just boot an arch distro and chroot the partition, you would then have access to the files through mount as root, could also change permissions on the files etc if needed I believe.

https://wiki.archlinux.org/title/Chroot

18

Hi ! This is actually something I already tried, but the partition couldn’t be mounted.

I finally fixed my issue using a different method than those proposed in this thread. I will post it “step by step” to hopefully help someone in the future. I’d like to thank everyone who sent time on this issue !

19

copy pasted and slightly edited from AskUbuntu

So, 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 in case the hard drive is physically damaged. 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 superblocks 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.

3 Likes
20

ah, I didn’t realize the partition was corrupted, that explains everything. glad you posted the solution!

2 Likes