You are not logged in.
Pages: 1
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)
Offline
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)
Offline
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
Offline
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)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
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?
Offline
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.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Pages: 1