Hi Petter, [ Alastair, I've cc'd you on this one too, in the hope you have some input on where the console handling is going and what we need to do about that for squeeze ... ]
On Thu, Sep 17, 2009 at 10:02:07PM +0200, Petter Reinholdtsen wrote: > With dependency based boot sequencing, I discovered what I believe is > a bug in the init.d script. Ok, let's see, it looks like there are a few somewhat separate issues to deal with here ... > The script start in rcS.d/, yet depend on > $syslog which start in rc2.d/. This leads to an unstable boot > sequence ordering. This definitely should start in rcS, ie. be run once at boot, and not when changing runlevels. I don't see anything that explicitly requires syslog in the code though, so I'm guessing that either it was in rcS too when I first added the LSB headers to this, or I cargo-culted that one in accidentally. Either way, I agree it looks like it can go now and we don't need it. > Also, the script seem to do a similar job to > console-screen and console-setup, and because of this I believe it is > a good idea to have a well defined order to run these scripts and > propose to run console-screen first, then svgatextmode and finally > console-setup. This one looks a bit more curly. The current console-tools/kbd maintainer asked me to switch this back to kbd after etch, since console-tools was supposedly going to be removed -- that apparently hasn't happened yet, but since console-screen is from console-tools, it shouldn't even be on the same system as STM. console-setup is new, and indeed looks like it will 'conflict' with STM about setting the console font and the like. I'm not really sure if or how compatible they are with each other, and I'm not sure I even have suitable hardware here to test it with. I haven't actually run STM myself for many years now, but quite a few people still seem to love it and it is usually low maintenance enough that with their help we can keep it alive. We might need someone to do some tests for this ... > Last, I suspect the script need direct access to the > pty when concurrent booting is enabled, and because of this should be > flagged as interactive. It may echo a few things to the console, but it shouldn't prompt for input. I don't see any docs on what X-Interactive is supposed to imply. It needs direct access to the tty to read and set configuration though, since it likely resizes the console. > Also, the script used to start after mountnfs.sh, and this make me > believe it should depend on $remote_fs instead of $local_fs. The usual fontpath is in /usr/share, so that seems like a fair candidate for being a remote_fs, and this seems like a correct change indeed. > I found no code depending on the tasks done by > bootmisc.sh, and believe that dependency can be dropped. I don't recall what prompted its addition previously, but I don't see anything in there now that we depend on either, so I agree with this change too. So ... if you let me know what the deal is with X-Interactive and whether or not we do really need it, and we figure out which of the other consoleFoo tools really are going to be the default for squeeze and how they should interact with STM (or if they can at all) -- then I'll push an updated package out. I'm really not that familiar with where the current console handling is going right now, so I'm going to need some good advice on that from the people who do. Cheers, Ron > diff -ur svgatextmode-1.9/debian/svgatextmode.init > svgatextmode-1.9-pere/debian/svgatextmode.init > --- svgatextmode-1.9/debian/svgatextmode.init 2009-09-17 21:53:07.000000000 > +0200 > +++ svgatextmode-1.9-pere/debian/svgatextmode.init 2009-09-17 > 21:57:53.000000000 +0200 > @@ -2,9 +2,11 @@ > > ### BEGIN INIT INFO > # Provides: svgatextmode > -# Required-Start: > +# Required-Start: $remote_fs > # Required-Stop: > -# Should-Start: $syslog $local_fs bootmisc > +# Should-Start: console-screen > +# X-Start-Before: console-setup > +# X-Interactive: true > # Default-Start: S > # Default-Stop: > # Short-Description: Provide VGA text modes for console users -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
