Repairing /dev after accidental deletion.

LauMars · 01-12-2012, 05:02 AM

I've just accidentally:
# rm -Rv /dev
(I meant to ./dev but hadn't spotted I missed the full stop until after I hit return).

Anyhow, I've run a simulation of doing the same action on a VM and the system appeared to rebuild the /dev directory upon restart. However I just wanted to make sure that this would fix everything or if there will be other outstanding issues?

OS: SLES 11.1

weibullguy · 01-12-2012, 07:29 AM

You might want to execute these commands.

Code:

mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3

These are required by the kernel at boot time and not dynamically created during boot.

David the H. · 01-12-2012, 08:33 AM

The /dev directory entries on most Linux systems are handled by udev these days, which dynamically builds the device tree from detected hardware. In fact on many distros, the /dev directory itself is now hosted on a ram-based virtual filesystem.

What weibullguy posted above could be an exception; I'm no expert there. But if so, I imagine the default init scripts or initramfs probably handle such things usually.

LauMars · 01-12-2012, 08:45 AM

Quote:

Originally Posted by weibullguy

You might want to execute these commands.

Code:

mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3

These are required by the kernel at boot time and not dynamically created during boot.

The test I performed in a VM booted fine without those commands (I tested it before you had replied). So -on SLES at least- /dev/console and /dev/null are not required to boot.

I will however check to see if they have been recreated. So I definitely appreciate the input.

LauMars · 01-12-2012, 08:48 AM

Quote:

Originally Posted by David the H.

The /dev directory entries on most Linux systems are handled by udev these days, which dynamically builds the device tree from detected hardware. In fact on many distros, the /dev directory itself is now hosted on a ram-based virtual filesystem.

This is what I suspected (or at least secretly hoped).
I'll keep testing (and reading these forums in case others have any input / advice) for now, just to be safe.

Thank you

Quote:

Originally Posted by David the H.

What weibullguy posted above could be an exception; I'm no expert there. But if so, I imagine the default init scripts or initramfs probably handle such things usually.

I see. That might explain why the VM rebooted without a problem.