So I have two hard drives. Hard drive A (HDDA) had a version of windows 7 that suffered a Windows Explorer error that caused it to go through a constant reboot cycle and caused us to lose access to the file system and most software. Then we have Hard drive B (HDDB) that had three partitions each with different OS. One with Debian 10, one with Windows 8.1, and one with Ubuntu.

I tried all sorts of fixes for HDDA but it came to the point where I needed to just try a repair on the windows OS and did not have the original installation disk and for a number of reasons could not make a working repair disk, or do a backup with just disks. So we decided to just upgrade to windows 10 but I wanted to make a disk image as the computer is used for lab equipment with all sorts of drivers that may or may not have issues once upgraded.

What I tried to do then was create a disk image of HDDA onto HDDB in case something happened. The partition on HDDA was ~70 GB and I was copying it onto a partition of ~430GB. I used the command:

sudo dd if=/dev/sdb1 of=/dev/sda5

After doing that however, all of the space on the partition on HDDB was used and I could no longer open the directory for that partition in the files GUI. On closing out of the computer I was given a ext4-fs error. Once I turned the computer back on it just brings me up to a blank screen with a blinking underscore.

Is there anyway to fix this issue and reach any of the OS on HDDB?

Thank you

I'm afraid it seems you nuked your HDDB.

What you did wrong

Doing sudo dd if=/dev/sdb1 of=/dev/sda5 from one disk into another that is live (i.e. mounted, or their sibling partitions are mounted) is incredibly risky.

The first problem is that we don't know what partition sda5 was. It may have been NTFS, FAT, ext4, etc. Preferrably it should be the same.

Second, we don't know if sda5 was critical to your systems. The command you ran doesn't append the data, it overwrites it.

Third, the main problem with your command is that we don't know a lot about HDDA and HDDB. For example if one uses MBR and other GPT, you can't transplant the partitions. If it was MBR, we don't know which ones were secondary and which ones primary partitions.

What you should have done.

You should've backed up the entire disk to a file, not a partition on your backup disk.

i.e.

sudo dd if=/dev/sdb of=/home/username/mybackup.bin

Or alternatively compressed:

sudo apt-get install zstd

# To backup
zstd -16v </dev/sdb >/home/username/mybackup.zst
# To restore
zstdcat -v /home/username/mybackup.zst >/dev/sdb

Check for drive health

What you described about HDDA sounds suspicious. It's possible it is failing.

Running smartctl -a /dev/sdb will give you more info. If you are on Windows, you can run SW like CrystalDiskInfo.

It is a good idea to regularly check SMART values on all your disks anyway.

What you can do now

Create a LiveUSB, boot from there, and start GPart. You need to see what is recognized from your HDDB to see what can be salvaged, if anything.

If your other partitions are still recognized, then it may just be a problem of restoring your EFI boot partition and install a boot manager that wants to boot from Windows or your other Linux partition.

You may have to also edit /etc/fstab from your still-alive Debian/Ubuntu to no longer try to mount sda5 (which won't be written as sda5 but rather its now-non-existent GUID) otherwise booting will take a long time or fail to boot.

If what was nuked was your EFI boot partition, you're then in luck. Just recreating it as FAT32, setting the EFI boot bit, and installing GRUB on it again will restore your system.

But there's like a thousand possibilities, you don't know yet what will find when you open GPart on your HDDB.

At worse nothing is recognized and the only alternative would be to use the same techniques professional disk recovery services use for when a drive fails (scrap raw disk, try to recognize partition tables, if that fails try to recognize files by their common patterns) or just format everything and install from scratch.