Roger Leigh <rleigh@codelibre.net> writes:

> On Wed, Apr 11, 2012 at 12:13:09PM +0200, Goswin von Brederlow wrote:
>> Roger Leigh <rleigh@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877gxdpge6.fsf@frosties.localnet">http://lists.debian.org/877gxdpge6.fsf@frosties.localnet

Petter Reinholdtsen <pere@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 873981pg8f.fsf@frosties.localnet">http://lists.debian.org/873981pg8f.fsf@frosties.localnet

Raphael Geissert <geissert@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87y5pto1it.fsf@frosties.localnet">http://lists.debian.org/87y5pto1it.fsf@frosties.localnet

On Wed, Apr 18, 2012 at 11:00:00AM +0200, Goswin von Brederlow wrote:
> Petter Reinholdtsen <pere@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 Kern Debian Developer
: :' : http://philkern.de Stable Release Manager
`. `' xmpphil@0x539.de Wanna-Build Admin
`- finger pkern/key@db.debian.org

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 <pere@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/Linux http://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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120418173005.GC28734@codelibre.net">http://lists.debian.org/20120418173005.GC28734@codelibre.net

[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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2flsjg06w7w.fsf@login2.uio.no">http://lists.debian.org/2flsjg06w7w.fsf@login2.uio.no

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/Linux http://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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120419085407.GE28734@codelibre.net">http://lists.debian.org/20120419085407.GE28734@codelibre.net

]] 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877gxcvvrs.fsf@qurzaw.varnish-software.com">http://lists.debian.org/877gxcvvrs.fsf@qurzaw.varnish-software.com

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/Linux http://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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120419132641.GF28734@codelibre.net">http://lists.debian.org/20120419132641.GF28734@codelibre.net

]] 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pqb3v79v.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87pqb3v79v.fsf@qurzaw.varnish-software.com