Follow

Just ran `sudo rm -rf /dev/*` by accident. Whoops!

(I'd intended to run `sudo rm - rf /mnt/*` to clear out some no-longer mounted USB drives. I swear, some days I just shouldn't be allowed near a keyboard…)

I've never been more grateful to be working in a virtual machine and be able to restore painlessly!

@codesections congratulations! You're now admitted to the best of the best Linux club!

@brandon

> congratulations! You're now admitted to the best of the best Linux club!

Because of the error or the use of a VM that protected me from the consequences of my folly?

@codesections The error :3 We all make them mistakes, it was slightly sarcastic

@codesections I've made the habit of putting -r or -rf at the end, after the directory name. I think it prevents a lot of accidents.

@codesections Would that do anything that wouldn't be fixed by a restart?

Doesn't /dev just contain device files that are autogenerated anyway?

@faho

> Would that do anything that wouldn't be fixed by a restart? Doesn't /dev just contain device files that are autogenerated anyway?

You know, I was wondering that too. Restarting the VM certainly worked, and maybe restarting on bare metal would have had the same effect.

@mike, you replied to this thread—any idea if that would have worked?

(Glad I didn't have to find out, though!)

@codesections @faho @mike I've never had the misfortune of wiping out all of the /dev/ files. But I think that, since those files were wiped out, you would probably not be able to talk to the underlying hardware.

For all I know, the kernel may *still* be able to talk to the hardware, and could recreate those files even when the system is running.

@Ertain @codesections @mike Of course the kernel can (it doesn't have to go via its own API), I think you could even do it with `mknod` and friends (as long as you manage to do so without reading e.g. /dev/random)?

They can also be recreated, and have to be on boot, since they are typically on a tmpfs (a "devtmpfs").

The question is if there is anything that's *not* one of those, e.g. a symlink to an actual drive, which `rm -r` would gleefully follow (since `--one-file-system` isn't default)?

@codesections @faho No clue. I'm assuming if it worked on a VM it would work bare metal, but I've never had the pleasure of finding myself in that situation, luckily.

@codesections @faho @mike /dev is normally a pseudo fs or ramdisk; the ramdisk is populated at boot by udev and friends. Of course your challenge is to repopulate it without a reboot using mkdev or udev.
(And why does my phone keyboard convert ramdisk into tandoori)

@codesections Glad you could restore at least, cause I have no idea how you'd go about fixing that otherwise.

@codesections there was an edlug talk by Claudio Calvelli that covered that very circumstance and how to get your data back.

Sign in to participate in the conversation
Fosstodon

Fosstodon is a Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.