[Rik Theys] > /etc/rc2.d: Reformattet for easier reading:
S01acpi-support S01dirmngr S01joystick S01kvm S01loadcpufreq S01nvidia-glx S01nvidia-kernel S01rsyslog S01sudo S01uml-utilities S02acpid S02anacron S02apmd S02atd S02cpufrequtils S02cron S02dbus S02irqbalance S02mcelog S02mysql-ndb-mgm S02ntp S02openbsd-inetd S02openvpn S02rsync S02ssh S02stunnel4 S02sysstat S03avahi-daemon S03bluetooth S03hal S03mysql-ndb S03pulseaudio S04cups S04kdm S04libvirt-bin S04mysql S04network-manager S04saned S05bootlogs S05postfix S06laptop-mode S06rc.local S06rmnologin S06stop-bootlogd This ordering is correct as far as I know. hal starts before kdm, and nothing starting after kdm should affect its behaviour. > Looking at the X log file, the log file from the failed startup > stops where the working X log continues to process input devices > from HAL. Although hal is started before kdm. Maybe it doesn't start > fast enough? That might very well be the case. I suspect we might discover this kind of problems more when we speed up the boot, ie latent race conditions which have been hidden because the old boot was slow. Does it help to add a sleep command to the end of the hal script? For the booting to work, hal need to be fully operational before its init.d script exits, as the later scripts may expect hal to be working. I suspect this bug should be about document the requirement of enabling insserv, and that a new BTS report should be created to adressed the failing kdm issue. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
