dd over boot drive

trout420 · 2022-11-30 17:03:52

While trying to make a live ISO I accidentally gave a dd command the wrong device for the output file, sda, which happens to be my drive with my arch install on it. I realize that this is a very stupid and big mistake and that the effects of the command cannot be undone, but I am confused as to what actually happened and what I can do to fix any issues.

full command:

sudo dd if=EndeavourOS_Artemis_nova_22_9.iso of=/dev/sda bs=1024k status=progress

my confusion began right after realizing I had run the command with the wrong device. Given that I supplied the drive which my OS, bootloader, and home directory are on, and my current understanding of dd I would think that the drive would be completely overwritten and my system would stop working. This does not appear to be the case, I am able to run programs, and view and edit files just fine. The directory structure seems unchanged, although I have not rebooted this machine since the command. Does dd have any sort of protection built in that stopped the drive from being overwritten? (I am under the impression it does not) Or maybe the changes are not applied until a reboot? If the latter is the case is there any way I could throw away the changes before they take effect?

If I am unable to cleanly undo the changes, what actions should I take in order to get my system back into a similar state. I have already backed up my home directory and some configuration files to a separate drive, but I am unsure of what would need to be done and the best way to go about it. Should I just do a full system install again? Or is there a simpler way to only fix what has been affected.

I am not sure what other information would be useful in this case, so please let me know if any information would be helpful.

Last edited by trout420 (2022-11-30 17:04:29)

V1del · 2022-11-30 17:12:26

How sure are you that /dev/sda is your root drive? The device letters are not set in stone and you might have "won" the race and /dev/sda actually being the stick you intended to write on. Check/post

lsblk -f
fdisk -l

and the like. This is the reason you shouldn't rely on device letters for your fstab and bootloader since they will fail to mount disks if the drive letters aren't matching: https://wiki.archlinux.org/title/Persis … ice_naming

Last edited by V1del (2022-11-30 17:12:54)

trout420 · 2022-11-30 17:25:05

I am pretty certain sda is my boot drive. At this point the output of lsblk -f is:

NAME        FSTYPE  FSVER            LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda         iso9660 Joliet Extension EOS_202209 2022-09-10-10-51-40-00
├─sda1                                                                                548.6M     0% /efi
├─sda2                                                                                              [SWAP]
└─sda3      ext4    1.0                         16c005ad-3ecf-467d-b9b8-afa65d89c470   48.5G    85% /
sdb
├─sdb1
└─sdb2      ntfs                     HDD        66E81D5FE81D2F35
nvme0n1
├─nvme0n1p1 vfat    FAT32                       7C85-89A6
├─nvme0n1p2
├─nvme0n1p3 ntfs                                0A748B44748B320D
└─nvme0n1p4 ntfs                                4638BC0C38BBF94F

I have 3 drives, the NVME drive containing my windows partition, a large hard drive for mass storage (this is where I have backed up my files) and a SATA ssd for arch. Given this and the fact that the sda is now labeled EOS (endeavourOS, the distro of the ISO) I don't see how I did not overwrite my arch install. Additionally, I noticed I had done something wrong when trying to boot from the USB I though I had burned to, only to find it booting into the OS I had on it previously.

here is the output of fdisk -l:

Disk /dev/sda: 489.05 GiB, 525112713216 bytes, 1025610768 sectors
Disk model: Crucial_CT525MX3
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: 0x1e784590

Device     Boot   Start     End Sectors  Size Id Type
/dev/sda1  *         64 3583359 3583296  1.7G  0 Empty
/dev/sda2       3583360 3796351  212992  104M ef EFI (FAT-12/16/32)


Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000NE001-2MA1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8992FA99-5863-4997-B47E-D2E67CB64DD9

Device     Start        End    Sectors  Size Type
/dev/sdb1     34      32767      32734   16M Microsoft reserved
/dev/sdb2  32768 7814033407 7814000640  3.6T Microsoft basic data

Partition 1 does not start on physical sector boundary.


Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 970 EVO Plus 1TB
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: gpt
Disk identifier: E40EEA5A-E483-40BF-88B6-1D5D6B3247F7

Device              Start        End    Sectors   Size Type
/dev/nvme0n1p1       2048     206847     204800   100M EFI System
/dev/nvme0n1p2     206848     239615      32768    16M Microsoft reserved
/dev/nvme0n1p3     239616 1952485492 1952245877 930.9G Microsoft basic data
/dev/nvme0n1p4 1952487424 1953521663    1034240   505M Windows recovery environment

Trilby · 2022-11-30 17:37:52

You don't need anything in /efi or (or swap really) for your system to keep running. So even if you let the dd command run to completion, depending on the size of the iso and your swap partition, then perhaps the root partition wasn't even touched.

But even if this is the case, the partition table would have been obliderated. This can be recovered, which could then leave you in the state of just having to restore anything in the /efi partition which is fairly simple (resintall the kernel and microcode packages and reinstall any bootmanager code to /efi).

Last edited by Trilby (2022-11-30 17:40:40)

trout420 · 2022-11-30 17:54:59

Okay, so if I understand correctly dd only wrote to the drive the size of the ISO. How would I go about recovering the partition table? Correct me if I'm wrong but reinstalling the kernel and microcode would be something along the lines of

 pacman -S linux amd-ucode

?

looking at the ISO I used, it is 1.9G (from ls -lh) but my swap and efi partitions are only 1.2G judging by this output from lsblk:

sda           8:0    0   489G  0 disk
├─sda1        8:1    0   300M  0 part /efi
├─sda2        8:2    0     1G  0 part [SWAP]
└─sda3        8:3    0 487.8G  0 part /

(489-487.8 = 1.2)

Therefore about .7G of my root partition has been overwritten?

cfr · 2022-11-30 20:33:19

Do you know whether the partition table was GPT or MBR before? If it was GPT, I believe there should be a second copy of the partition table. However, I don't know if you should restore this given that more than simply the partition table was destroyed.

Trilby · 2022-11-30 21:50:33

Ah, yes, if 0.7G of root was likely overwritten, my previous suggestion almost certainly doesn't apply. But if you wanted to try it, recreating the partition table is done just as you did initially to create the partitions - just don't format them with mkfs.

Arch Linux

#1 2022-11-30 17:03:52

dd over boot drive

#2 2022-11-30 17:12:26

Re: dd over boot drive

#3 2022-11-30 17:25:05

Re: dd over boot drive

#4 2022-11-30 17:37:52

Re: dd over boot drive

#5 2022-11-30 17:54:59

Re: dd over boot drive

#6 2022-11-30 20:33:19

Re: dd over boot drive

#7 2022-11-30 21:50:33

Re: dd over boot drive

Board footer