Bug#581704: [Pkg-sysvinit-devel] Bug#581704: sysvinit
[Tanker Jedi] I have similar problems. It seems that / is read-only beacuse i get similar errors like Josh Triplet in message 3. Today i have upgraded the sysvinit packages but i did not help. Did you also upgrade the sysvinit-utils and sysv-rc packages? The fix is in the sysv-rc package, and the startpar program is in the sysvinit-utils package. Can you provide the output from /usr/share/insserv/make-testsuite? Is there anything special about your environment I could use to replicate this 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
Bug#581704: [Pkg-sysvinit-devel] Bug#581704: sysvinit
Of course, i have upgraded them. tankerj...@napsugar:~$ apt-cache policy sysv-rc sysv-rc: Telepítve: 2.88dsf-8 Jelölt: 2.88dsf-8 tankerj...@napsugar:~$ apt-cache policy sysvinit-utils sysvinit-utils: Telepítve: 2.88dsf-8 Jelölt: 2.88dsf-8 I do not know it is problem that i do not have /etc/insserv.conf file. I use my own kernel, thats all special in my system. Thanks, TJ testsuite.log Description: Binary data
Bug#581704: [Pkg-sysvinit-devel] Bug#581704: sysvinit
[Tanker Jedi] Of course, i have upgraded them. Good. I do not know it is problem that i do not have /etc/insserv.conf file. Missing /etc/insserv.conf is definitely a problem if you use dependency based boot sequencing. Any idea why it is missing? The output from the make-testsuite script would be nice. Also, the output from /usr/share/insserv/check-initd-order might be useful. 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
Bug#581704: [Pkg-sysvinit-devel] Bug#581704: sysvinit: Failing to run init script (or ordering problem) after upgrade from startpar to makefile
[Josh Triplett] I already used CONCURRENCY=startpar on my system, and it worked quite well, but I didn't use CONCURRENCY=makefile because it actually boots slower on my system. Interesting. I assume there are bugs in some combination of init.d scripts on your system. I use CONCURRENCY=makefile on several systems, and it work for me. :) After upgrading, when I rebooted to test the new mechanism, it seems that some key init scripts (such as mounting the root filesystem read-write and setting the hostname) either didn't run or didn't run soon enough; I got a pile of errors about failures to write due to a read-only filesystem, and the system stopped at some point and never finished booting. To recover, I had to boot into single-user mode, remount the filesystem read-write, and set CONCURRENCY=none in /etc/default/rcS. I've attached pictures taken of the messages shown when booting with CONCURRENCY=startpar. Can you provide the output from /usr/share/insserv/make-testsuite, and also the content of /var/log/boot after editing /etc/default/bootlogd to enable bootlogd and rebooting once to record all errors? Also, please provide the output from 'ls /etc/rc?.d'. 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
