江湖急救!rcconf中取消了一些自启动程序,重启后文件系统只能只读了

asert

系统启动打印如下:
。。。。
Init:Entering runlevel:2
Starting system log daemon
<这阶段要等待5分钟以上才会打印下面的内容>
mkdir:cannot create directory '/lib/init/rw/sendsigs.omit.d: Readonly file system
IN:creating symbolic link '/lib/init/rw/sendsigs.omit.d/sysklogd': No such file or directory
Starting kernel log daemon... failed

(none)login:
Linux debian 2.6.32-trunk-686

当时我是看到kde桌面环境的程序运行有些问题，所以看了一下rcconf,发现有很多自启动程序感觉不爽，而且公司用的redhat5中也是有很多自启动程序，我在setup设置里都把自己不清楚用途的自启动程序全部取消后redhat没有任何问题；所以胆子变大在rcconf里把很多不清楚用途的自启动程序也给取消了，差不多只留下了下面几个我比较眼熟的:
acipd alsa-utils hal sysklogd udev dbus dirmngr

请问能让系统恢复吗?
事后感觉自己真是傻X，都过年了还没事找事做。。。

zeyata

Post by asert;2068883
系统启动打印如下:
。。。。
Init:Entering runlevel:2

这说明你进入多用户模式后开始出错。你可以尝试在启动时进入单用户模式然后恢复必要的init脚本。

Post by asert;2068883

请问能让系统恢复吗?
事后感觉自己真是傻X，都过年了还没事找事做。。。

Debian/testing系统使用的是sysvinit，/etc目录下有以下几个目录:
init.d rc0.d  rc1.d  rc2.d  rc3.d  rc4.d  rc5.d  rc6.d  rcS.d
/etc/init.d目录下的脚本是后台daemon的实际控制脚本。rc开头的几个目录下是一些链接，链接到/etc/init.d目录下相应文件。当系统进入特定的runlevel时会按字典顺序调用相应目录下的脚本文件。比如在我的系统里，当进入runlevel 2时会按字典顺序调用/etc/rc2.d目录下的脚本。其中K开头的以stop参数调用，S开头的以start参数调用。

2. zeyata@miahiu:/etc$ ls -l rc2.d/
3. 总计 4
4. -rw-r--r-- 1 root root 677 10-26 04:54 README
5. lrwxrwxrwx 1 root root  24 01-30 20:29 S01binfmt-support -> ../init.d/binfmt-support
6. lrwxrwxrwx 1 root root  19 01-29 23:39 S01fetchmail -> ../init.d/fetchmail
7. lrwxrwxrwx 1 root root  21 01-30 20:29 S01loadcpufreq -> ../init.d/loadcpufreq
8. lrwxrwxrwx 1 root root  17 01-29 17:23 S01rsyslog -> ../init.d/rsyslog
9. lrwxrwxrwx 1 root root  14 01-29 18:06 S01sudo -> ../init.d/sudo
10. lrwxrwxrwx 1 root root  15 01-29 17:23 S02acpid -> ../init.d/acpid
11. lrwxrwxrwx 1 root root  13 01-30 03:55 S02atd -> ../init.d/atd
12. lrwxrwxrwx 1 root root  22 01-30 20:29 S02cpufrequtils -> ../init.d/cpufrequtils
13. lrwxrwxrwx 1 root root  14 01-29 17:23 S02cron -> ../init.d/cron
14. lrwxrwxrwx 1 root root  14 01-29 20:59 S02dbus -> ../init.d/dbus
15. lrwxrwxrwx 1 root root  15 01-29 20:27 S02dictd -> ../init.d/dictd
16. lrwxrwxrwx 1 root root  17 01-30 23:02 S02dnsmasq -> ../init.d/dnsmasq
17. lrwxrwxrwx 1 root root  13 01-29 21:29 S02gpm -> ../init.d/gpm
18. lrwxrwxrwx 1 root root  13 01-30 08:19 S02ntp -> ../init.d/ntp
19. lrwxrwxrwx 1 root root  13 01-29 17:58 S02xfs -> ../init.d/xfs
20. lrwxrwxrwx 1 root root  22 01-30 20:29 S03avahi-daemon -> ../init.d/avahi-daemon
21. lrwxrwxrwx 1 root root  19 01-30 20:29 S03bluetooth -> ../init.d/bluetooth
22. lrwxrwxrwx 1 root root  15 01-30 23:02 S03exim4 -> ../init.d/exim4
23. lrwxrwxrwx 1 root root  13 01-30 20:31 S03hal -> ../init.d/hal
24. lrwxrwxrwx 1 root root  25 02-08 07:29 S03network-manager -> ../init.d/network-manager
25. lrwxrwxrwx 1 root root  15 01-30 23:02 S03rsync -> ../init.d/rsync
26. lrwxrwxrwx 1 root root  14 01-30 20:29 S04cups -> ../init.d/cups
27. lrwxrwxrwx 1 root root  13 02-08 07:29 S04gdm -> ../init.d/gdm
28. lrwxrwxrwx 1 root root  15 01-30 20:33 S04saned -> ../init.d/saned
29. lrwxrwxrwx 1 root root  18 02-08 07:29 S05bootlogs -> ../init.d/bootlogs
30. lrwxrwxrwx 1 root root  18 02-08 07:29 S06rc.local -> ../init.d/rc.local
31. lrwxrwxrwx 1 root root  19 02-08 07:29 S06rmnologin -> ../init.d/rmnologin
32. lrwxrwxrwx 1 root root  23 02-08 07:29 S06stop-bootlogd -> ../init.d/stop-bootlogd

复制代码

系统的各服务之间有一定的依赖关系，启动时需要按照仔细规划号的先后顺序启动。如果某个服务的启动脚本被你移除了，依赖于这个服务的其他服务就可能不能正常启动。

我建议你先保证自己能正常进入单用户模式，然后根据你的系统的实际情况逐步恢复系统init脚本和各runlevel相关的链接。
你可以阅读/etc/inittab文件以确认你的系统启动后会进入哪些runlevel以及init相关的目录结构。

zeyata

我在1楼废话多了点，既然你是用rcconf配置的，那就应该可以在单用户模式下用rcconf恢复。

blue_stone

update-rc.d <service name> defaults
可以将服务恢复为默认值, 你可以试着将所有的服务恢复到默认看看

BTW, 如果root分区是只读, 可以用mount -o remount,rw /
将root分区挂载到可读写状态

asert

谢谢两位，现在我通过进入单用户模式后用update-rc.d <service name> defaults把所有服务都恢复成默认，然后重启为多用户模式发现
在提示Starting system log daemon之前0文件系统仍然是只读的，导致很多自启动程序创建文件不成功，Starting system log daemon阶段也会假死几分钟，之后文件系统就可以读写了，不清楚什么原因。。。

blue_stone

/ 的挂载由checkroot.sh完成, 请检查一下/etc/rcS.d中checkroot.sh在什么时候执行的.

asert

谢谢楼上的帮助，现在基本解决了，可是还有两个问题想要请教你

1.dbus无法自启动,只能在登录后手动启动，不清楚什么未启动还是启动失败,而且因为hal依赖dbus,这也导致了hal无法自启动，以下是dbus的自启动文件存放位置
debian:~# find /etc/ -iname *dbus*
/etc/default/dbus
/etc/init.d/dbus
/etc/rc1.d/K88dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus
/etc/rcS.d/S12dbus
/etc/X11/Xsession.d/75dbus_dbus-launch
/etc/dbus-1
/etc/dbus-1/system.d/avahi-dbus.conf


2.我现在知道/etc/rc.0是关机运行脚本,/etc/rc.1是单用户运行脚本，/etc/rc.2到/etc/rc.5是d多用户运行脚本，/etc/rc.6是重启运行脚本.
那/etc/rc.S目录下的脚本又是起到什么样的作用呢?

blue_stone

Debian中, /etc/rcS.d包含了系统必须的启动脚本, 在系统init进程启动后, /etc/rcS.d中的脚本首先执行, 然后才会执行rc<n>.d中的脚本.

asert

Debian中, /etc/rcS.d包含了系统必须的启动脚本, 在系统init进程启动后, /etc/rcS.d中的脚本首先执行, 然后才会执行rc<n>.d中的脚本.
--------------------------------------
既然这样，那么是不是如果/etc/rcS.d有dbus启动脚本，那么rc1.d到rc5.d就不需要再有dbus启动脚本了吧，不然不就启动了两次了嘛

blue_stone

我的系统里, 只有rcS.d中有udev
find /etc |grep udev
/etc/rcS.d/S02udev
/etc/rcS.d/S14udev-mtab
/etc/init.d/udev-mtab
/etc/init.d/udev
可以考虑update-rc.d udev remove, 再检查一下/etc/rc?.d下有没有udev的链接, 有则删除之,
然后运行update-rc.d udev defaults, 将udev设置为在默认运行级别启动