Comment 41 for bug 430224

Revision history for this message
gyp (gyp-impulzus) wrote :

Clint, the honest answer is that I don't know :) The problem is that it's really just a bring-me-back-my-good-old-system-V-init type of hack, and any boot process that truly relies on upstart doing its more advanced things (handling dependencies, using triggers, restarting failed services etc.) would fail miserably. I could manually check and fix all the ~15 services that are started this way in my case, but I'm not sure it's what people want to do. However, the good news is that in my case, none of the initscripts had to be modified, but I was not comfortable until I've manually checked all of them.

That being said, if you took a look at what it does and as a someone having deeper knowledge of the ubuntu boot process think that it could work for others, too, I guess it could be at least something for the guys trying to run lucid in a chroot instead of the current "well, it's not working" state of things.

Regarding your question on my blog (sorry, the commenting system there's a mess, I haven't looked at it since the web guys moved it to wordpress, I tried to fix things now) about bringing it to Launchpad: of course, feel free to do that. It indeed does not have a bug tracker or anything as I did not mean it to be a proper released product but just something I could give back to the FOSS community. And I'm happy to handle bug entries and fix small issues as they come up, so you can count me as an active developer base :) There's one thing though: it relies heavily on having an additional feature in start-stop-daemon, so that'd need to be added to that, too. I've sent the patch for it in to the dpkg devs, but the guys there were a bit reluctant to include it upstream as they thought it could allow for even more nasty hacks :) That discussion can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610719