files in /dev deleted - autorepair?

[lockenlollo]

Hi all,

I accidentally deleted some files on our server in the /dev directory, the permissions of which were obviously set to o+rwx. After that, I wasn't able to connect to the server via ftp (e.g. with filezilla). After running start_udev, this was fixed. However, I am afraid that some entries for some devices still might be gone, and the next reboot will fail. I have two questions:

1) Did this happen to anyone else and is there any advice what and how to fix before the next reboot?

2) Is there any "built in" repair / restore / recovery funtion in Fedora, that can be run without reboot?

Many thanks in advance!

[george_toolan]

Try https://admin.fedoraproject.org/pkgdb/acls/name/MAKEDEV

[Skull One]

Could you please report your fedora and kernel versions ?

Nowadays, /dev is mounted and populated during boot. It is an empty directory when the system is down.
Therefore, if you did not delete udev rules, you just need to reboot to get everything back.
Please report the output of:

uname -a
df

for checking.

By the way, I guess the shutdown could hang if some device nodes are missing, and will need to be forced.

[stevea]

Originally Posted by lockenlollo

Hi all,

I accidentally deleted some files on our server in the /dev directory, the permissions of which were obviously set to o+rwx.

Why is that obvious ? The file permissions have nothing to do with your ability to delete. That is dependent on the directory permissions and file ownership.

For a long long now /dev has been at least partly a pseudo file system, now wholly ....

devtmpfs on /dev type devtmpfs (rw,nosuid,size=3946136k,nr_inodes=986534,mode=755 )
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode =000)

which is instantiated at boot time and driver discovery time via udev.

Years ago your deletions would be a headache to repair. Today your /dev/ should be reconstructed at reboot. No tools necessary.

Here is the 'dev' from my old F14 rootfs when not used as '/' ....

[root@hypoxylon mnt]# mount /dev/sda1 /mnt/oldroot
[root@hypoxylon mnt]# cat /mnt/oldroot/etc/redhat-release 
Fedora release 14 (Laughlin)
[root@hypoxylon mnt]# ls -laR /mnt/oldroot/dev
/mnt/oldroot/dev:
total 8
drwxr-xr-x.  2 root   root   4096 Nov 22  2010 .
dr-xr-xr-x. 35 stevea stevea 4096 May 28 21:40 ..
[root@hypoxylon mnt]#

You'll note the /dev directory has ZERO static content. It's all constructed at run time.

[lockenlollo]

Hi george_toolan,

Originally Posted by george_toolan

Try https://admin.fedoraproject.org/pkgdb/acls/name/MAKEDEV

I already came across MAKEDEV upon my google search on the internet, however I was unsure whether it will "repair" the /dev directory without reboot (which was my first intention). I am no LINUX guru and was afraid to destroy even more upon installing new software. Now then, I will have a closer look at MAKEDEV. Thanks for your advice!

---------- Post added at 05:39 PM ---------- Previous post was at 05:28 PM ----------

Hi Skull One,

Originally Posted by Skull One

Could you please report your fedora and kernel versions ?

Nowadays, /dev is mounted and populated during boot. It is an empty directory when the system is down.
Therefore, if you did not delete udev rules, you just need to reboot to get everything back.
Please report the output of:

uname -a
df

for checking.

By the way, I guess the shutdown could hang if some device nodes are missing, and will need to be forced.

uname -a says:

[jana@doro ~]$ uname -a
Linux doro 2.6.35.14-96.fc14.x86_64 #1 SMP Thu Sep 1 11:59:56 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

and df:
[jana@doro ~]$ df
Dateisystem 1K‐Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_doro-lv_root
51606140 5899988 45181996 12% /
tmpfs 37185660 676 37184984 1% /dev/shm
/dev/sda1 495844 67944 402300 15% /boot
/dev/mapper/vg_doro-lv_opt
1023929592 363959028 607957920 38% /opt
tmpfs 1024000 162604 861396 16% /ram

It looks like Fedora Core 14 (fc14) and the kernel information is as follows:
[jana@doro ~]$ rpm -qa | grep 'kernel'
kernel-2.6.35.14-96.fc14.x86_64
kernel-2.6.35.6-45.fc14.x86_64
kernel-2.6.35.14-106.fc14.x86_64
kernel-headers-2.6.35.14-106.fc14.x86_64

I hope that I did not delete udev rules (how could I check that - and what if I did?). Nevertheless, I am now a bit calmer, since several people here told me, that /dev will be restored upon booting. Thanks for your help and also thanks for the valuable comment on hanging shutdown.

---------- Post added at 05:51 PM ---------- Previous post was at 05:39 PM ----------

Hi Stevea,

Originally Posted by stevea

Why is that obvious ? The file permissions have nothing to do with your ability to delete. That is dependent on the directory permissions and file ownership.

Oh, you are of course right! I wrote "obviously" because I was unsure how exactly permissions and file ownership looked like - the files were gone, I could not check.

Originally Posted by stevea

For a long long now /dev has been at least partly a pseudo file system, now wholly ....

which is instantiated at boot time and driver discovery time via udev.

That's again good to hear.

Originally Posted by stevea

Years ago your deletions would be a headache to repair. Today your /dev/ should be reconstructed at reboot. No tools necessary.

And again good news :-)

Originally Posted by stevea

Here is the 'dev' from my old F14 rootfs when not used as '/' ....

[root@hypoxylon mnt]# mount /dev/sda1 /mnt/oldroot
[root@hypoxylon mnt]# cat /mnt/oldroot/etc/redhat-release 
Fedora release 14 (Laughlin)
[root@hypoxylon mnt]# ls -laR /mnt/oldroot/dev
/mnt/oldroot/dev:
total 8
drwxr-xr-x.  2 root   root   4096 Nov 22  2010 .
dr-xr-xr-x. 35 stevea stevea 4096 May 28 21:40 ..
[root@hypoxylon mnt]#

You'll note the /dev directory has ZERO static content. It's all constructed at run time.

I understand! That was a nice demonstration of how empty dev is when it's not mounted on /, I fully understand. Thanks very much for your reply and your explanations. I will talk to my colleague and hope that everything will go smooth when we reboot the server.

[Skull One]

OK, your system is not too old, a reboot should fix everything.