Don't sudo gnome-disks after beers

  • Published: —
  • Modified: 2017-07-30 21:53
  • By: Mishoo
  • Tags: linux
  • Comments: 0 (add)
Jul
30
2017

Don't sudo gnome-disks after beers

So yesterday I was repartitioning an USB stick and I was, say, less vigilant than I usually am when I play with these tools: the wrong disk was selected. I clicked through the confirmation dialogs without thinking too much, and gnome-disks happily removed my /boot and swap partitions. About the third partition, however, it complained with a “can't unmount it” message! (that was the root partition). As I was re-reading the message in horror, I realized I was messing with the wrong disk. Holy shmoly, so it did try to unmount it! "Thanks" goes to whoever made it impossible to remove a mounted partition, and "Thanks NOT!" goes to gnome-disks for not displaying a big fat warning when I try to remove a mounted partition that it can unmount.

Evaluating the situation, I first hoped that gnome-disks would queue the operations and that there's some Apply button. I closed it, and checked with fdisk, to dismiss my hopes. Only the root partition was there. I thought, oh well, this machine won't boot — but right now it still works. I don't care about swap (it wasn't even used, in fact; 16G of RAM is enough for what I do). Worst case scenario, I create a new boot partition. Not ideal, because I'm not sure what files to put on it. But, but... the data should still be there, if I can re-create the partition.

I googled and I found it quickly: testdisk is a tool sent from Heaven for me to restore the partitions that I accidentally delete over beers. After pacman -S testdisk and testdisk /dev/sda, it did a quick scan of the disk and promptly restored my /boot partition. I mounted it and yay, the files were there. "Moment of truth", I say, "will it boot?". Closed all apps and rebooted the machine, only to end up in the BIOS menu.

What are my options now? (1) go to some old laptop, download some distro (probably still Arch) and make a bootable USB stick with the tool I need: efibootmgr, because the bloody boot entry was no longer there in EFI (or UEFI, or... heck, I'm too old for this stuff); or (2) go to sleep.

I chose (2), and did (1) in the morning; after booting the Arch Linux ISO (which basically leaves you in console with a blinking cursor and a root prompt, because you're a wizard and know how to install Linux by hand), I mounted my boot and root partitions and checked that the files are there. The root partition was marked “Microsoft basic data” or something — not sure why, perhaps a small bug in testdisk. I used fdisk to make it “Linux root (x86-64)” and then used the magic spell, which I've relearned after more googling:

efibootmgr -d /dev/sda -p 1 -c -L "Arch Linux" -l /vmlinuz-linux \
           -u "root=/dev/sda2 initrd=/intel-ucode.img initrd=/initramfs-linux.img"

Then I've rebooted in glory and everything is in place :-) (except swap, which is the reason why root became sda2 instead of sda3... oh well). Disaster averted. Thanks Google, thanks Internet, thanks Arch and thanks testdisk. And thanks NOT gnome-disks (I think chances for this to happen were much smaller if I sticked to command line).

No comments yet. Wanna add one? Please?

Add your comment