On Mon, 2010-05-24 at 15:33 +0200, Petter Reinholdtsen wrote:
> [Chanoch (Ken) Bloom]
> > I'm seeing this bug too. I upgraded a about a week ago with the command
> > $ sudo aptitude install sysv-rc
>
> Thank you for the feedback. I believe I understand what is going on
> here. file-rc fail to flag that it is using the legacy boot ordering,
> and as the system was convereted from sysv-rc to file-rc before
> sysv-rc created /etc/init.d/.legacy-bootordering before the system was
> switched to file-rc, the boot ordering end up wrong.
>
> I suspect the proper fix for this is for file-rc to create
> /etc/init.d/.legacy-bootordering when it is in use. This way sysv-rc
> will know what to do when switching from file-rc to sysv-rc.
>
> Another approach would be for sysv-rc to look for start symlinks in
> rc0.d or rc6.d, and assume legacy boot ordering is in effect if such
> symlinks are found. If this approach is used, we can probably also
> get rid of the /etc/init.d/.legacy-bootordering flag file.
>
> I welcome input on the approaches. Not sure which is best.
There's a third option, now that I look more in detail at your other
maintainer scripts. sysv-rc.preinst
touches /etc/init.d/.legacy-bootordering on upgrade (under certain
circumstances), but doesn't create it on install. You add tests to
create the /etc/init.d/.legacy-bootordering file on install too, based
on appropriate circumstances.
The second approach sounds best to me. It has the least corner cases,
and sounds the least fragile.
* In all of the other approaches, you have to think about exactly
which versions of which init systems need the reordering, and
exactly how to detect them correctly. There are potentially four
init systems now -- sysv-rc/insserv, file-rc, upstart and
systemd (in the near future) -- so that's going to be a lot of
work in the long run.
* The only case in which the second approach fails is if there's
some legitimate reason to start some service in runlevel 0 or 6,
and you expect to support people who customize their init
subsystems to specifically undo the change. I think this is
unlikely.
* It automatically fixes any system that is already broken by a
botched file-rc to sysv-rc switch, even if file-rc is no longer
installed. (None of the other techniques does that.)
> Btw, note that because file-rc fail to remove runlevel.conf when
> switching from file-rc to sysv-rc, it is not safe to switch back to
> file-rc. Any changes to the symlinks in /etc/rc?.d/ done after
> switching to sysv-rc will be lost.
That would be strictly a file-rc issue. It can be resolved by purging
file-rc, or by rewriting file-rc's update script to do something more
intelligent in this situation.
Actually the bigger question is whether file-rc still makes sense in the
bootup picture as it stands now. Will file-rc continue to exist as we
develop all of these fancy new boot systems?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
