[Martin-Éric Racine] > Therefore, it seems that your affirmation about someone not having > read the documentation is purely gratuitous at best and downright > insulting at worst.
I must have misread the initial report, as I read that you had checked the boot order before you ran insserv, and not after you run it. > I maintain my position that this should have gone to Experimental, > not Unstable, and that it should have a priority of "Extra" not > "Optional". Well, I disagree. It is a powerfull sysadmin tool, and have in my tests with LTSP speeded up the boot process by 62%, so it is already useful today. As all powerfull tools, it can do damage, and do good. > As for you affirmations that the package assumes nothing, this is > wrong. Upstream's README and the manual page clearly state what > they expect to see in any init script to determine the boot > dependencies. Yes, the override feature is very new, and not yet documented in upstreams README nor the manual page. This should be fixed. > Most Debian packages' init don't provide the information required, > which therefore means that a lot of override files must be created > and that without the overrides a system can and in this case indeed > did go into a state where it was not bootable. That is correct. At the moment 138 override files are created. There might be mistakes in some of them, but it was able to get my test machines booting with the packages installed on them, both with 2.4 and 2.6 kernels. > After some manual fiddling with the boot order, I eventually got > something bootable again. My rcS is currently as follow: There must be something wrong with your installation. mountvirtfs is missing. It is the init.d script taking care of mounting /proc. On my system, it is part of initscripts version 2.86.ds1-1.1. Without it, I suspect it would get mounted in mountall.sh, which is way to late. > This leaves a lot to be desired, though, as things like hwclockfirst > complain that some procfs bits are not available (which makes sense, > since procfs is taken care of much later). There are still a few > other error messages from various daemons as well. Please let me know more on the problems you see, and which dependencies are wrong, so they can be fixed. Did insserv report of any dependency loops? I've seen that give strange results for the boot sequence. > Another issue (of severity "normal") is that Debian boot scripts are > not quite expected to cleanly run in parallel yet, which results in > boot messages overlapping each other into an unreadable garbage, > with one script's "Launching daemon NAME..." showing up in between > another script's message and its "done." statement, etc. Yes. I believe this package is not the correct place to fix the parallel booting. As you say, it need to serialize the outptu from scripts. I see at least two solutions to this, (1) port the startpar program from SuSe or (2) rewrite rc and rcS to cache the output from scripts and print them in sequence. > Petter, don't get me wrong: I see a lot of potential in this > package, but I really do believe that it should have gone into > Experimental first, just like any other package that messes with > other applications' boot order should, and be thoroughly tested > there until everyone is satisfied that this is safe to upload into > unstable. Well, I fint that it is not possible to satisfy everyone, and that this powerfull tool is already useful as it is (with a lot of potential for improvement for sure), and see no reason not to make it available for those that want to use and test it. Yes, it will take a while before all init.d scripts in debian are covered or have dependency info in the header, and it will take even longer before all the dependencies are correct, but those two issues do not need to be solved completely for this tool to do useful work. As I said, it already do useful work. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
