Re: The future of non-dependency-based boot
PR == Petter Reinholdtsen p...@hungry.com writes: PR You do not have to edit the init.d files themselves to override PR their dependencies, and risk them going away during upgrades. I PR created the possibility for the system administrator to insert PR overrides in /etc/insserv/overrides/ for just this use case. Good to know, Thanks. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3pqam7k7e@carbon.jhcloos.org
Re: The future of non-dependency-based boot
[Roger Leigh] I can't see why not at first glance--it's done its job, so should no longer be needed. It is still needed in two use cases. 1) Machine upgraded from Lenny where the migration was not done. Either because it could not be done, or because the user choose not to do it. 2) Machines switching to/from file-rc. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flsjg06w7w@login2.uio.no
Re: The future of non-dependency-based boot
On Thu, Apr 19, 2012 at 09:01:55AM +0200, Petter Reinholdtsen wrote: [Roger Leigh] I can't see why not at first glance--it's done its job, so should no longer be needed. It is still needed in two use cases. 1) Machine upgraded from Lenny where the migration was not done. Either because it could not be done, or because the user choose not to do it. 2) Machines switching to/from file-rc. Sure, I can appreciate that we still need the upgrade logic. But, do we need the debconf question? Surely we can just migrate unconditionally (or attempt to, at least). (I don't know if you saw my mail regarding having done this provisionally in git; I mentioned it on the pkg-sysvinit-devel list and in #545976. I was wanting to additionally ask you how safe it would be to remove the is_unsafe_to_activate check and just run insserv anyway, and rely on insserv to fail if problems are found.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120419085407.ge28...@codelibre.net
Re: The future of non-dependency-based boot
]] Roger Leigh (I don't know if you saw my mail regarding having done this provisionally in git; I mentioned it on the pkg-sysvinit-devel list and in #545976. I was wanting to additionally ask you how safe it would be to remove the is_unsafe_to_activate check and just run insserv anyway, and rely on insserv to fail if problems are found.) Not having sysv-rc complain when it can't wrap its head around the init scripts on the system would be very much appreciated. I'm kinda tired of it trying to convert my system on each upgrade and then failing. (And this machine has never even used sysvinit.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gxcvvrs@qurzaw.varnish-software.com
Re: The future of non-dependency-based boot
On Thu, Apr 19, 2012 at 12:52:23PM +0200, Tollef Fog Heen wrote: ]] Roger Leigh (I don't know if you saw my mail regarding having done this provisionally in git; I mentioned it on the pkg-sysvinit-devel list and in #545976. I was wanting to additionally ask you how safe it would be to remove the is_unsafe_to_activate check and just run insserv anyway, and rely on insserv to fail if problems are found.) Not having sysv-rc complain when it can't wrap its head around the init scripts on the system would be very much appreciated. I'm kinda tired of it trying to convert my system on each upgrade and then failing. (And this machine has never even used sysvinit.) Could you provide examples please? If there are init scripts which it can't handle, that's a bug. Either in insserv or (more likely) the scripts. This has been partly discussed in #594917, but you haven't followed up there in response to the last comment. Based on this bug, I think it's perfectly reasonable for sysv-rc to manage the links; whether sysvinit is or is not running is not part of the question here, IMO. Given that systemd users are for the most part going to be users migrating from a sysvinit/sysv-rc/ insserv configuration, it's not unexpected that insserv will be managing the links. systemd should be able to cope with insserv managing the links shouldn't it? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120419132641.gf28...@codelibre.net
Re: The future of non-dependency-based boot
]] Roger Leigh Could you provide examples please? If there are init scripts which it can't handle, that's a bug. Either in insserv or (more likely) the scripts. It fails to handle the case where something provides a virtual facility, at least. It also seems to think that /etc/init.d/../rc2.d/S30gdm3 on my system is «corrupt or invalid», without further information. (It's for some reason a normal file rather than a symlink, but I don't see why that should matter.) This has been partly discussed in #594917, but you haven't followed up there in response to the last comment. Based on this bug, I think it's perfectly reasonable for sysv-rc to manage the links; whether sysvinit is or is not running is not part of the question here, IMO. Given that systemd users are for the most part going to be users migrating from a sysvinit/sysv-rc/ insserv configuration, it's not unexpected that insserv will be managing the links. systemd should be able to cope with insserv managing the links shouldn't it? systemd is perfectly able to cope. It doesn't care about the numbering, but uses the dependency information from the header of the script instead and only uses S/K to determine whether a service should be running or not. What I'm complaining about is it's continued insistence on trying to convert to another way of ordering the links when it's unable to do so, especially when said complaining is in the form of a debconf error on each and every upgrade of the package. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqb3v79v@qurzaw.varnish-software.com
Re: The future of non-dependency-based boot
Roger Leigh rle...@codelibre.net writes: On Wed, Apr 11, 2012 at 12:13:09PM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: As a side note I have a use case at work where static order seems to be needed. We build boot images for network boot of clusters. During boot additional files can be copied from NFS into the system including boot scripts. When using dependency based boot order the numbers for boot scripts change a lot depending on the boot image (include support for lustre, ha, slurm, ... and each gets a different order). That makes it impossible (or at least a lot harder) to copy in the same generic boot scripts from NFS into different images since the name needs to be different for each case. The boot scripts would have to be reordered during boot. So do your boot scripts declare the correct dependency information in the LSB header? With dependency based boot, the numbers are meaningless other than for ordering. The fact that they change is to be expected. Are you running insserv to update the ordering? I'm not running insserv at boot. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gxdpge6.fsf@frosties.localnet
Re: The future of non-dependency-based boot
Petter Reinholdtsen p...@hungry.com writes: [Sven Joachim] I beg to disagree, it is already unsupportable because the only way to test it is to set up a lenny system, create some local init script without LSB headers to prevent migration to dependency based boot, and then upgrade all the way to squeeze and wheezy. You can also install file-rc. It only handle the static script ordering, and when switching the static ordering is activated. :) Or seed the debconf value and override file for legacy bootordering before (c)debootstrap: F=$CHROOT_DIR/var/cache/debconf/config.dat # Enforce legacy bootordering mkdir -p $CHROOT_DIR/etc/init.d touch $CHROOT_DIR/etc/init.d/.legacy-bootordering mkdir -p $CHROOT_DIR/var/cache/debconf echo $F Name: sysv-rc/convert-legacy echo $F Template: sysv-rc/convert-legacy echo $F Value: false echo $F Owners: sysv-rc MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/873981pg8f.fsf@frosties.localnet
Re: The future of non-dependency-based boot
Raphael Geissert geiss...@debian.org writes: Goswin von Brederlow wrote: 3) Aborting the upgrade because dependency boot ordering fails will be a major issue for users. You already mentioned 2 issues and on my system at home I get an error about a dependency loop. Dependency based boot doesn't seem to be universally working enough yet. If it is caused by a package: file a bug, otherwise fix it. Most commonly left over scripts cause this problem and isn't a bug in the package. As a side note I have a use case at work where static order seems to be needed. We build boot images for network boot of clusters. During boot additional files can be copied from NFS into the system including boot scripts. When using dependency based boot order the numbers for boot scripts change a lot depending on the boot image (include support for lustre, ha, slurm, ... and each gets a different order). That makes it impossible (or at least a lot harder) to copy in the same generic boot scripts from NFS into different images since the name needs to be different for each case. The boot scripts would have to be reordered during boot. Sounds very much like you want to configure those other boot scripts in a different runlevel to then switch to it. If you do it all by hand you need to: copy them, create the symlinks, run insserv, telinit. Yeah, something that will have to be done in the future. I'm still hoping to keep the existing legacy way till we switch to e.g. systemd and have to rewrite it all anyway. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5pto1it.fsf@frosties.localnet
Re: The future of non-dependency-based boot
On Wed, Apr 18, 2012 at 11:00:00AM +0200, Goswin von Brederlow wrote: Petter Reinholdtsen p...@hungry.com writes: [Sven Joachim] I beg to disagree, it is already unsupportable because the only way to test it is to set up a lenny system, create some local init script without LSB headers to prevent migration to dependency based boot, and then upgrade all the way to squeeze and wheezy. You can also install file-rc. It only handle the static script ordering, and when switching the static ordering is activated. :) Or seed the debconf value and override file for legacy bootordering before (c)debootstrap: [...] echo $F Name: sysv-rc/convert-legacy echo $F Template: sysv-rc/convert-legacy echo $F Value: false echo $F Owners: sysv-rc Given that skipping a release isn't supported and as this has been in squeeze, can it be dropped from sysv-rc, please? Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: The future of non-dependency-based boot
On Wed, Apr 18, 2012 at 07:15:48PM +0200, Philipp Kern wrote: On Wed, Apr 18, 2012 at 11:00:00AM +0200, Goswin von Brederlow wrote: Petter Reinholdtsen p...@hungry.com writes: [Sven Joachim] I beg to disagree, it is already unsupportable because the only way to test it is to set up a lenny system, create some local init script without LSB headers to prevent migration to dependency based boot, and then upgrade all the way to squeeze and wheezy. You can also install file-rc. It only handle the static script ordering, and when switching the static ordering is activated. :) Or seed the debconf value and override file for legacy bootordering before (c)debootstrap: [...] echo $F Name: sysv-rc/convert-legacy echo $F Template: sysv-rc/convert-legacy echo $F Value: false echo $F Owners: sysv-rc Given that skipping a release isn't supported and as this has been in squeeze, can it be dropped from sysv-rc, please? I can't see why not at first glance--it's done its job, so should no longer be needed. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120418173005.gc28...@codelibre.net
Re: The future of non-dependency-based boot
Three notes: Manually choosing the order remains a reasonable choice for many servers. The upstream dependencies are not always sufficiently detailed and edits to the init files can be lost when upgrading. Such servers generally start only a few services and hand-tuning the order is easy and obvious. They also typically restart less often than once per year. Systems which have had various packaged added and removed can retain legacy init scripts which prevent conversion to the new setup even where it is not unwanted. I have one long-time server on which apt-get upgrade displays a full (96x66) page dialog filled with init script which block the automated switch to dependency-based boot order. On a server which did update to dep-based I see that there are serveral S files in the default run level which shouldn't be there. They had been removed but reappeared. (Just because something is installed doesn't mean one wants it always to run.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3hawlwf3v@carbon.jhcloos.org
Re: The future of non-dependency-based boot
[James Cloos] Manually choosing the order remains a reasonable choice for many servers. The upstream dependencies are not always sufficiently detailed and edits to the init files can be lost when upgrading. Your assumptions are wrong. You do not have to edit the init.d files themselves to override their dependencies, and risk them going away during upgrades. I created the possibility for the system administrator to insert overrides in /etc/insserv/overrides/ for just this use case. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flbomtibjh@login2.uio.no
config files, ucf and dpkg (was: Re: The future of non-dependency-based boot)
Le 15/04/2012 11:34, Petter Reinholdtsen a écrit : [James Cloos] Manually choosing the order remains a reasonable choice for many servers. The upstream dependencies are not always sufficiently detailed and edits to the init files can be lost when upgrading. Your assumptions are wrong. You do not have to edit the init.d files themselves to override their dependencies, and risk them going away during upgrades. I created the possibility for the system administrator to insert overrides in /etc/insserv/overrides/ for just this use case. And then, if the maintainer fix some problem in dependencies, you will not notice there is two conflicting or complementary modifications at the same place. I'm aware of this possibility but I always modify the init.d files in order to be notified (and to be able to check my modifications are still right) when the init.d files are modified during an upgrade. However, I would be more than pleased if maintainers use ucf with the --three-way flags (often modifications are done in unrelated places and a three-way merge would work perfectly). One problem here is that, with ucf, there are no config files any more but only configuration files (ie dpkg -S will not find them, dpkg does not remove them automatically on purge, ...) So I would be even more pleased if the three-way merge possibility would be offered by dpkg itself. Dpkg would have to store a copy of the original config file elsewhere in this case, but for me cost of the disk space is largely outperformed by the feature. Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8abac1.30...@free.fr
Re: The future of non-dependency-based boot
Goswin von Brederlow wrote: 3) Aborting the upgrade because dependency boot ordering fails will be a major issue for users. You already mentioned 2 issues and on my system at home I get an error about a dependency loop. Dependency based boot doesn't seem to be universally working enough yet. If it is caused by a package: file a bug, otherwise fix it. As a side note I have a use case at work where static order seems to be needed. We build boot images for network boot of clusters. During boot additional files can be copied from NFS into the system including boot scripts. When using dependency based boot order the numbers for boot scripts change a lot depending on the boot image (include support for lustre, ha, slurm, ... and each gets a different order). That makes it impossible (or at least a lot harder) to copy in the same generic boot scripts from NFS into different images since the name needs to be different for each case. The boot scripts would have to be reordered during boot. Sounds very much like you want to configure those other boot scripts in a different runlevel to then switch to it. If you do it all by hand you need to: copy them, create the symlinks, run insserv, telinit. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jmcsoc$hoa$1...@dough.gmane.org
Re: The future of non-dependency-based boot
On Wed, 11 Apr 2012, Brian May wrote:
On 10 April 2012 16:06, Yves-Alexis Perez cor...@debian.org wrote:
dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
That's a pretty dangerous line. People (sometimes) don't purge packages
for a reason, you might lose data here.
Under some circumstances it can delete configuration files that are in
use by active packages.
e.g. package b replaces package a, however uses the same set of
configuration files - purge package a and it will delete the
configuration
files now in use by package b.
Err, no. At least dpkg shouldn't do that. If you can reproduce it, please
file a bug.
(Make sure it's not some postrm that is badly behaving)
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120411061929.gf8...@rivendell.home.ouaza.com
Re: The future of non-dependency-based boot
On 04/11/2012 06:12 AM, Chris Knadle wrote: - if the init script left behind was part of a Debian package, deleting the init script means removing part of the configuration from the Debian pacakge, yet not purging the package it belongs to. This feels like something that would volate Debian policy regarding one package not altering the configuration of another. Likewise, moving the init script means that purging the old package that had configuration left behind will no longer delete the init script file, which will thus be left behind as orphaned cruft. You do realize that we are talking about leftovers from Etch (and possibly earlier) in Wheezy, which means 4 or 5 years later, right? If you think that we can't delete them, how about moving them away in a special folder, like /etc/init.d/obsolete-scripts (feel free to propose a better name for that folder)? We could prompt the user about them, so he wont miss it, and the configuration that you are talking about will stay (even though, most likely, this is quite useless, IMO). - the upgrade may be unattended or automatic, in which case presumably the default will be chosen and the user/admin will never know that the init script was removed, so the default of 'yes' is dangerous. The default with no may be even more dangerous. If you run in a non-interactive way, then you will still have some non-LSB header scripts on the way, which may prevent you from booting. - the current administrator at the keyboard may not be the one that wrote or installed the custom-installed init script, so the upgrade may need to be completed before the question of whether the init script can be deleted has a satisfactory answer, but an answer of 'no' will presumably cause an issue for dependency-based bootup. If we move the *bad* scripts away in a specific folder, we have best of both worlds, IMO. Thoughts? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f854b7a.8010...@debian.org
Re: The future of non-dependency-based boot
Roger Leigh rle...@codelibre.net writes: Hi, When dependency-based booting was introduced, it was initially entirely optional. We later made it the default, and encouraged users to switch to dependency-based boot on upgrade. So today, pretty much everyone will be using dependency-based boot with there being a minority continuing to use the static boot ordering of yore. Probably mostly users who upgraded from etch. The reason for this mail is mainly to ask if there is any continuing need for the old static ordering to be kept, and if not, how best to migrate the remaining users. With all other init systems worth their salt requiring dependencies, should sysvinit not do the same? Now that all (?) init scripts provide LSB headers, the existing static ordering will increasingly bitrot. It was never that great to begin with, but with dependency ordering being used by the vast majority, it's going to be increasingly untested. Do we want to continue to maintain something that will be increasingly unsupportable, or complete the migration cleanly before that point? WRT actually doing this, the main issues I can see are - blocking by obsolete-but-unpurged init scripts without LSB header. We could mv them out of the way to .dpkg-old and continue, or abort and require manual intervention. - breakage of any non-LSB scripts remain after this. We could abort in the preinst and prevent upgrade until it's manually resolved, unless there's a cleaner way to handle it. Obviously, we don't want to make any systems unbootable, but doing it without any manual intervention where possible would be desirable. This can, of course, be left until wheezy+1. It's just something which needs considering before it becomes a bigger problem. Regards, Roger I think: 1) Long term the init situation will change anyway with upstream / systemd rising in popularity. But not in wheezy. So why not wait for that before dropping existing support. 2) Static order is currently supported and supporting it for wheezy doesn't incurr horrible amounts of work. It hasn't degraded enough to warrant removing it yet. 3) Aborting the upgrade because dependency boot ordering fails will be a major issue for users. You already mentioned 2 issues and on my system at home I get an error about a dependency loop. Dependency based boot doesn't seem to be universally working enough yet. Conclusion: Given the short timeframe for wheezy keep things as they are. Consider removing it in wheezy+1. As a side note I have a use case at work where static order seems to be needed. We build boot images for network boot of clusters. During boot additional files can be copied from NFS into the system including boot scripts. When using dependency based boot order the numbers for boot scripts change a lot depending on the boot image (include support for lustre, ha, slurm, ... and each gets a different order). That makes it impossible (or at least a lot harder) to copy in the same generic boot scripts from NFS into different images since the name needs to be different for each case. The boot scripts would have to be reordered during boot. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871unuefuy.fsf@frosties.localnet
Re: The future of non-dependency-based boot
On Wed, Apr 11, 2012 at 12:13:09PM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: As a side note I have a use case at work where static order seems to be needed. We build boot images for network boot of clusters. During boot additional files can be copied from NFS into the system including boot scripts. When using dependency based boot order the numbers for boot scripts change a lot depending on the boot image (include support for lustre, ha, slurm, ... and each gets a different order). That makes it impossible (or at least a lot harder) to copy in the same generic boot scripts from NFS into different images since the name needs to be different for each case. The boot scripts would have to be reordered during boot. So do your boot scripts declare the correct dependency information in the LSB header? With dependency based boot, the numbers are meaningless other than for ordering. The fact that they change is to be expected. Are you running insserv to update the ordering? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120411102751.ga...@codelibre.net
Re: The future of non-dependency-based boot
On 2012-04-11 12:13 +0200, Goswin von Brederlow wrote: 2) Static order is currently supported and supporting it for wheezy doesn't incurr horrible amounts of work. I beg to disagree, it is already unsupportable because the only way to test it is to set up a lenny system, create some local init script without LSB headers to prevent migration to dependency based boot, and then upgrade all the way to squeeze and wheezy. Cheers, Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx6iwm9f@turtle.gmx.de
Re: The future of non-dependency-based boot
On Wednesday, April 11, 2012 05:14:34, Thomas Goirand wrote: On 04/11/2012 06:12 AM, Chris Knadle wrote: - if the init script left behind was part of a Debian package, deleting the init script means removing part of the configuration from the Debian pacakge, yet not purging the package it belongs to. This feels like something that would volate Debian policy regarding one package not altering the configuration of another. Likewise, moving the init script means that purging the old package that had configuration left behind will no longer delete the init script file, which will thus be left behind as orphaned cruft. You do realize that we are talking about leftovers from Etch (and possibly earlier) in Wheezy, which means 4 or 5 years later, right? I don't disagree that the leftovers are old (whether it be from lenny or older)... but will the upgrade script check this? [Presumably the upgrade script would normally only check if the init script is dependency-based compatible, and not how old the init script is or whether it's associated with a Debian package.] If you think that we can't delete them, how about moving them away in a special folder, like /etc/init.d/obsolete-scripts (feel free to propose a better name for that folder)? We could prompt the user about them, so he wont miss it, and the configuration that you are talking about will stay (even though, most likely, this is quite useless, IMO). I think I agree with this proposition at least in spirit [I'm all for fixing the problem, afterall :-P], but I'm wondering whether this is the right thing to do or if there's maybe a better alternative. Personally, I'd rather give the user an option to purge the associated package the init script is in (if it's in one), especially if the package has been removed-but-not-purged. If that could be accomplished I think that would be a cleaner way of dealing with the problem. I think another option (which maybe could be used as a fallback) would be to leave the broken init script in place, but to 'chmod -x' the file to make it non-executable. [Would this work within the dependency-based framework?] - the upgrade may be unattended or automatic, in which case presumably the default will be chosen and the user/admin will never know that the init script was removed, so the default of 'yes' is dangerous. The default with no may be even more dangerous. If you run in a non-interactive way, then you will still have some non-LSB header scripts on the way, which may prevent you from booting. I'm trying to figure out a way this can be handled which will conform to Debian Policy section 6.3. Link for convenience: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s- controllingterminal Between us both, I think we've found that there's a problem with either default, which means this is going to be tricky to handle. :-/ - the current administrator at the keyboard may not be the one that wrote or installed the custom-installed init script, so the upgrade may need to be completed before the question of whether the init script can be deleted has a satisfactory answer, but an answer of 'no' will presumably cause an issue for dependency-based bootup. If we move the *bad* scripts away in a specific folder, we have best of both worlds, IMO. Thoughts? It's better than deletion, but I'd also like to consdier alternatives. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Re: The future of non-dependency-based boot
[Sven Joachim] I beg to disagree, it is already unsupportable because the only way to test it is to set up a lenny system, create some local init script without LSB headers to prevent migration to dependency based boot, and then upgrade all the way to squeeze and wheezy. You can also install file-rc. It only handle the static script ordering, and when switching the static ordering is activated. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flbomyqlr6@login1.uio.no
Re: The future of non-dependency-based boot
On Wed, 11 Apr 2012, Raphael Hertzog wrote:
On Wed, 11 Apr 2012, Brian May wrote:
On 10 April 2012 16:06, Yves-Alexis Perez cor...@debian.org wrote:
dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
That's a pretty dangerous line. People (sometimes) don't purge packages
for a reason, you might lose data here.
Under some circumstances it can delete configuration files that are in
use by active packages.
e.g. package b replaces package a, however uses the same set of
configuration files - purge package a and it will delete the
configuration
files now in use by package b.
Err, no. At least dpkg shouldn't do that. If you can reproduce it, please
file a bug.
AFAIK, the problem is not a conffile (dpkg-managed), but config
files/directories and runtime data files/directories that are destroyed
by the postrm script in package a when it is purged.
(Make sure it's not some postrm that is badly behaving)
That is exactly the problem. And the usual safe way to deal with it is
manually inspect every postrm script, and rm/edit it when necessary
before purguing the package. It is damn obvious why most of us prefer
to leave package a to rot in removed-but-not-purged state forever,
or at least until it causes some problem...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120411172725.ga8...@khazad-dum.debian.net
Re: The future of non-dependency-based boot
On mar., 2012-04-10 at 01:03 +0200, Marco d'Itri wrote:
Or just say in the release notes that it's a good idea to run something
like this before upgrading:
dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
That's a pretty dangerous line. People (sometimes) don't purge packages
for a reason, you might lose data here.
Regards,
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
Re: The future of non-dependency-based boot
On 04/10/2012 07:03 AM, Marco d'Itri wrote: On Apr 09, Roger Leigh rle...@codelibre.net wrote: majority, it's going to be increasingly untested. Do we want to continue to maintain something that will be increasingly unsupportable, or complete the migration cleanly before that point? Kill it. With fire. I wholeheartedly agree. I also agree that wheezy would be the correct moment to do it, and that we shouldn't wait until wheezy+1. WRT actually doing this, the main issues I can see are I say just abort the upgrade and let root deal with the issues found, it's better than risking clobbering some local change. Considering that most (if not all) scripts would be user custom-scripts, I'd say that the best way would be to, just move them away on a special folder, and execute them one by one, without any particular order, and print a huge warning at boot time, saying: HEY, we've found crap, please fix! It's there --- $whatever-obsolete-script-path Of course, that's not ideal, but I believe that'd be our best hope to not destroy *too much* old setups during upgrades. My bet is that most user-made scripts would not require any dependencies anyway. Also, doing the last upgrades of some old boxes, I've myself found that I had some rotten bind 8 init scripts, because bind 8 was removed, but not purged. That goes on the way to the user (and that annoyed me quite a bit). I believe that for packages that have been removed but not purged, it's very very likely that the remaining init.d script isn't wanted by the user. I'd be for deleting those with a small warning (or even better, a debconf message with something like: do you want to delete these antediluvian scripts that are still in your box? yes/no with yes as default). Thoughts? Am I doing too many assumptions here, and thinking too much that everyone is facing the same situation I did? Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f84032c.1040...@debian.org
Re: The future of non-dependency-based boot
On 10/04/12 10:53, Thomas Goirand wrote: I wholeheartedly agree. I also agree that wheezy would be the correct moment to do it, and that we shouldn't wait until wheezy+1. I was hesitant to suggest that investing energy into improving the current init system, if it is likely to be wholesale replaced, might not be worthwhile (when that same energy could be put into hastening the inevitable). However the release time frame issue is key here. sysvinit is not going away for wheezy; but this improvement might be possible. -- Jon Dowland signature.asc Description: OpenPGP digital signature
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 10:53 AM, Thomas Goirand z...@debian.org wrote: Considering that most (if not all) scripts would be user custom-scripts, I'd say that the best way would be to, just move them away on a special folder, and execute them one by one, without any particular order, and print a huge warning at boot time With similar intention, I wondered about the possibility of running scripts without the LSB headers after everything else. (= implied dependency on those with LSB headers) Moving the broken scripts to another folder would be easy to implement, but doesn't integrate well with the packaging system -- some of these broken scripts may be from sysadmins' local packages, as well as from ancient packages that are still installed but no longer in Debian. (Detecting that and doing diversions wouldn't work either, as if a fixed version of a local package is installed, we don't want the fixed script to be diverted away.) However it's implemented, running non-LSB scripts after everything else clearly won't work in every case, but would solve the issue of obsolete-but-unpurged scripts harmlessly, and I expect would work for the majority of local scripts from sysadmins. The local scripts which will fail could already have been broken in the old scheme by package maintainers' changes to packaged scripts that they expected to run before -- there were no guarantees against the static ordering of packaged scripts changing. -- Moray -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cahwf6zpcy6c0lgy6mnbxxcip8i1jramn+nx8m-q+oz+tdpj...@mail.gmail.com
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 11:55 AM, Jon Dowland j...@debian.org wrote: I was hesitant to suggest that investing energy into improving the current init system, if it is likely to be wholesale replaced, might not be worthwhile (when that same energy could be put into hastening the inevitable). Yes, it's a pity to invest more energy into additional work for a system that people hope to get rid of, but that argument also applies to time spent on the the sysadmin side. If we just think it's not worth fixing this cleanly, we perhaps shouldn't force sysadmins to tidy up their local scripts for it now, but just leave things until they need to modify their local setups more fundamentally for a replacement system. -- Moray -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cahwf6zpjrufb6u7waffjxursiu_03nz15r66cqdpq8fcmvi...@mail.gmail.com
Re: The future of non-dependency-based boot
[Moray Allan] With similar intention, I wondered about the possibility of running scripts without the LSB headers after everything else. (= implied dependency on those with LSB headers) The intention of the current implementation is to assume such scripts depend on $syslog and $remote_fs, and at one point in time I believe this worked just fine. But I have seen bug reports indicating that this no longer is true. As Debian should support init.d scripts as long as the Linux Software Base require it, I believe it is worth spending some time making sure init.d scripts work properly in Debian. Of the around 1000 packages with init.d scripts in Debian, I suspect at most 100 of them would need to provide upstart/systemd configuration to make the boot robust and correct, and the rest of the packages can keep using their existing init.d scripts. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl62d7pya0@login2.uio.no
Re: The future of non-dependency-based boot
On Mon, Apr 09, 2012 at 10:26:38PM +0100, Roger Leigh wrote: Hi, When dependency-based booting was introduced, it was initially entirely optional. We later made it the default, and encouraged users to switch to dependency-based boot on upgrade. So today, pretty much everyone will be using dependency-based boot with there being a minority continuing to use the static boot ordering of yore. Probably mostly users who upgraded from etch. The upgrade tool still needs some work, most of messages it produces are less than helpful. For example, it will scream about removed but not purged scripts that do have LSB headers (ie, any from lenny or squeeze), and then you have gems like this: │ Unable to migrate to dependency-based boot system │ │ Tests have determined that problems in the boot system exist which │ prevent migration to dependency-based boot sequencing: │ │ package initscripts left obsolete init.d script behind, package │ initscripts left obsolete init.d script behind, package initscripts │ left obsolete init.d script behind │ Am I supposed to fetch a copy of initscripts and manually compare scripts it ships with those on 'dpkg -L initscripts'? Or is there some other obscure way? grep -L 'BEGIN INIT INFO' `dpkg -L initscripts` doesn't show anything in /etc/init.d, at least. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120410151044.ga20...@angband.pl
Re: The future of non-dependency-based boot
[Adam Borowski]
Am I supposed to fetch a copy of initscripts and manually compare
scripts it ships with those on 'dpkg -L initscripts'? Or is there
some other obscure way?
Try this one instead:
dpkg-query -W -f='${Conffiles}\n' initscripts | grep obsolete
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2flzkajobvv@login2.uio.no
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 05:16:36PM +0200, Petter Reinholdtsen wrote:
[Adam Borowski]
Am I supposed to fetch a copy of initscripts and manually compare
scripts it ships with those on 'dpkg -L initscripts'? Or is there
some other obscure way?
Try this one instead:
dpkg-query -W -f='${Conffiles}\n' initscripts | grep obsolete
Yeah, this one helps, thanks.
Could sysv-rc show this output upon a failure to migrate? Knowing you need
to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and
/etc/init.d/stop-bootlogd would provide the user with straightforward info
of what needs to be done.
--
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120410153904.gc20...@angband.pl
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 02:27:35PM +0200, Petter Reinholdtsen wrote: As Debian should support init.d scripts as long as the Linux Software Base require it, I believe it is worth spending some time making sure init.d scripts work properly in Debian. The LSB requires support for LSB init scripts; LSB init scripts have LSB headers. No need to support non-dependency-based boot on the LSB's account. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120410174437.gd10...@virgil.dodds.net
Re: The future of non-dependency-based boot
Who said LSB requires insserv ? verify this. Um ... LSB requires everything I write too ! :) Riight???! But innserv makes a good effort to be compatible - so that end should be ok. The LSB requires support for LSB init scripts; LSB init scripts have LSB -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8474db.8040...@cox.net
Re: The future of non-dependency-based boot
On Tuesday, April 10, 2012 05:53:48 PM Thomas Goirand wrote: ... WRT actually doing this, the main issues I can see are I say just abort the upgrade and let root deal with the issues found, it's better than risking clobbering some local change. Considering that most (if not all) scripts would be user custom-scripts, I'd say that the best way would be to, just move them away on a special folder, and execute them one by one, without any particular order, and print a huge warning at boot time, saying: The main place I've seen this problem is not with custom scripts, but rather old init scripts from Debian packages due to config files left behind from packages that were 'removed' rather than 'purged'. [You apparently ran into this too with and old config file from Bind 8.] HEY, we've found crap, please fix! It's there --- $whatever-obsolete-script-path Of course, that's not ideal, but I believe that'd be our best hope to not destroy *too much* old setups during upgrades. My bet is that most user-made scripts would not require any dependencies anyway. Also, doing the last upgrades of some old boxes, I've myself found that I had some rotten bind 8 init scripts, because bind 8 was removed, but not purged. That goes on the way to the user (and that annoyed me quite a bit). I believe that for packages that have been removed but not purged, it's very very likely that the remaining init.d script isn't wanted by the user. I'd be for deleting those with a small warning (or even better, a debconf message with something like: do you want to delete these antediluvian scripts that are still in your box? yes/no with yes as default). Thoughts? What I don't like about the idea of deleting the init script by default: - if the init script left behind was part of a Debian package, deleting the init script means removing part of the configuration from the Debian pacakge, yet not purging the package it belongs to. This feels like something that would volate Debian policy regarding one package not altering the configuration of another. Likewise, moving the init script means that purging the old package that had configuration left behind will no longer delete the init script file, which will thus be left behind as orphaned cruft. - the upgrade may be unattended or automatic, in which case presumably the default will be chosen and the user/admin will never know that the init script was removed, so the default of 'yes' is dangerous. - the current administrator at the keyboard may not be the one that wrote or installed the custom-installed init script, so the upgrade may need to be completed before the question of whether the init script can be deleted has a satisfactory answer, but an answer of 'no' will presumably cause an issue for dependency-based bootup. Any thoughts on the above? -- -- Chris Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1480217.g0xx92AebP@trelane
Re: The future of non-dependency-based boot
Marco d'Itri wrote:
On Apr 09, Roger Leigh rle...@codelibre.net wrote:
majority, it's going to be increasingly untested. Do we want to
continue to maintain something that will be increasingly
unsupportable, or complete the migration cleanly before that point?
Kill it. With fire.
Yes please.
WRT actually doing this, the main issues I can see are
I say just abort the upgrade and let root deal with the issues found,
it's better than risking clobbering some local change.
To the extent root caused the problem in the first place with local
scripts. The vast majority of such cases seem like issues caused by
Debian packages, as mentioned below.
- blocking by obsolete-but-unpurged init scripts without LSB header.
We could mv them out of the way to .dpkg-old and continue, or
abort and require manual intervention.
Or just say in the release notes that it's a good idea to run something
like this before upgrading:
dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
Personally, I run into more problems by upgrading packages that drop or
rename init scripts (and other conffiles). dpkg keeps the old files
around even if unmodified, and leaves them associated with the package
despite no longer appearing in that package. (This also makes them
difficult to track down and eliminate.) I'd like to question that
particular decision of dpkg; I think it causes more pain than help.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120410184941.GA10156@leaf
Re: The future of non-dependency-based boot
]] Adam Borowski Could sysv-rc show this output upon a failure to migrate? Knowing you need to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and /etc/init.d/stop-bootlogd would provide the user with straightforward info of what needs to be done. I think this should just be fixed in initscript instead. There's no good reason for it to not clean up after itself. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcl7jozv@qurzaw.varnish-software.com
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 10:44:36PM +0200, Tollef Fog Heen wrote: ]] Adam Borowski Could sysv-rc show this output upon a failure to migrate? Knowing you need to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and /etc/init.d/stop-bootlogd would provide the user with straightforward info of what needs to be done. I think this should just be fixed in initscript instead. There's no good reason for it to not clean up after itself. Preferably, both. initscripts because this should work out of the box unless the admin has actually done a modification here. sysv-rc because there may be many more cases like this. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120410205547.ga30...@angband.pl
Re: The future of non-dependency-based boot
On 10.04.2012 22:44, Tollef Fog Heen wrote: ]] Adam Borowski Could sysv-rc show this output upon a failure to migrate? Knowing you need to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and /etc/init.d/stop-bootlogd would provide the user with straightforward info of what needs to be done. I think this should just be fixed in initscript instead. There's no good reason for it to not clean up after itself. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653050 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: The future of non-dependency-based boot
On Wed, Apr 11, 2012 at 12:31:11AM +0200, Michael Biebl wrote: On 10.04.2012 22:44, Tollef Fog Heen wrote: ]] Adam Borowski Could sysv-rc show this output upon a failure to migrate? Knowing you need to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and /etc/init.d/stop-bootlogd would provide the user with straightforward info of what needs to be done. I think this should just be fixed in initscript instead. There's no good reason for it to not clean up after itself. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653050 Yep. Started looking at this over the weekend, it's a PITA though. Hopefully should be fixed in the next upload if I have time to thoroughly test it this week (but I need to write the helper function first given that this has apparently not been needed until now). Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120410223745.gz30...@codelibre.net
Re: The future of non-dependency-based boot
On 10 April 2012 16:06, Yves-Alexis Perez cor...@debian.org wrote:
dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
That's a pretty dangerous line. People (sometimes) don't purge packages
for a reason, you might lose data here.
Under some circumstances it can delete configuration files that are in
use by active packages.
e.g. package b replaces package a, however uses the same set of
configuration files - purge package a and it will delete the
configuration
files now in use by package b.
--
Brian May br...@microcomaustralia.com.au
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAA0ZO6ByZp7tr3weApRM5OYaZCht81nrcZ=4ntcn7kdkfty...@mail.gmail.com
The future of non-dependency-based boot
Hi, When dependency-based booting was introduced, it was initially entirely optional. We later made it the default, and encouraged users to switch to dependency-based boot on upgrade. So today, pretty much everyone will be using dependency-based boot with there being a minority continuing to use the static boot ordering of yore. Probably mostly users who upgraded from etch. The reason for this mail is mainly to ask if there is any continuing need for the old static ordering to be kept, and if not, how best to migrate the remaining users. With all other init systems worth their salt requiring dependencies, should sysvinit not do the same? Now that all (?) init scripts provide LSB headers, the existing static ordering will increasingly bitrot. It was never that great to begin with, but with dependency ordering being used by the vast majority, it's going to be increasingly untested. Do we want to continue to maintain something that will be increasingly unsupportable, or complete the migration cleanly before that point? WRT actually doing this, the main issues I can see are - blocking by obsolete-but-unpurged init scripts without LSB header. We could mv them out of the way to .dpkg-old and continue, or abort and require manual intervention. - breakage of any non-LSB scripts remain after this. We could abort in the preinst and prevent upgrade until it's manually resolved, unless there's a cleaner way to handle it. Obviously, we don't want to make any systems unbootable, but doing it without any manual intervention where possible would be desirable. This can, of course, be left until wheezy+1. It's just something which needs considering before it becomes a bigger problem. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120409212638.gt30...@codelibre.net
Re: The future of non-dependency-based boot
On Apr 09, Roger Leigh rle...@codelibre.net wrote:
majority, it's going to be increasingly untested. Do we want to
continue to maintain something that will be increasingly
unsupportable, or complete the migration cleanly before that point?
Kill it. With fire.
WRT actually doing this, the main issues I can see are
I say just abort the upgrade and let root deal with the issues found,
it's better than risking clobbering some local change.
- blocking by obsolete-but-unpurged init scripts without LSB header.
We could mv them out of the way to .dpkg-old and continue, or
abort and require manual intervention.
Or just say in the release notes that it's a good idea to run something
like this before upgrading:
dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
This can, of course, be left until wheezy+1. It's just something
Why wait?
--
ciao,
Marco
signature.asc
Description: Digital signature
