On 2021-11-01 4:23 p.m., Mark Hindley wrote:
> -- System Information:
>> Debian Release: 11.0
>> APT prefers unreleased
>> APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500,
>> 'unstable'), (100, 'experimental')
>> Architecture: x32 (x86_64)
>> Foreign Architectures: i386, amd64
Mark Hindley dixit:
>I realise this may be clutching at straws, but is there any chance the
>x32 arch is the trigger for this?
As already stated… at least twice, I think, no: the system got
converted to amd64 in the meanwhile, and the same problem occurs
on my amd64 laptop that was never a
Hi,
Since nobody has been able to reproduce this issue, I have just been re-reading
Thorsten's original report to look for any possible differences.
On Mon, May 31, 2021 at 04:40:17AM +0200, Thorsten Glaser wrote:
> -- System Information:
> Debian Release: 11.0
> APT prefers unreleased
> APT
Thorsten Glaser writes ("Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon =>
K01avahi-daemon} with every upgrade"):
> On Wed, 6 Oct 2021, Mark Hindley wrote:
>
> > Thanks for this. However, neither Jesse nor I can reproduce this behaviour
> > with
> > the
On Wed, 6 Oct 2021, Mark Hindley wrote:
> Thanks for this. However, neither Jesse nor I can reproduce this behaviour
> with
> the LSB headers you provided which makes debugging what is going on difficult.
I don’t understand this: on another bullseye system (my laptop),
this is not even just
Control: tags -1 unreproducible
Thorsten,
On Mon, Sep 27, 2021 at 01:45:59PM +0200, Thorsten Glaser wrote:
> OK, that works for me, same as in the normal system:
>
> tglase@tglase:~ $ cp -a etc-stripped etc-stripped1
> tglase@tglase:~ $ insserv -p etc-stripped/init.d -i etc-stripped/init.d
>
On Sun, 26 Sep 2021, Jesse Smith wrote:
> I just realized what the problem is. On the version of insserv you are
> using, the command should be "insserv -p etc-stripped/init.d -i
> etc-stripped/init.d". The 1.21.0 version of insserv has a second flag
> for where to send dependency information.
On Mon, 27 Sep 2021, Mark Hindley wrote:
> Thorsten, I am wondering if you have anything in /etc/insserv/overrides or
Nope:
tglase@tglase:~ $ find /etc/insserv* -ls
2097290 4 drwxr-xr-x 3 root root 4096 Mär 27 2013
/etc/insserv
2098907 4 drwxr-xr-x 2 root
Jesse,
On Sun, Sep 26, 2021 at 08:45:39PM -0300, Jesse Smith wrote:
> In each case insserv detected that the avahi-daemon script should be
> marked as K01 instead of K02. Which is good, that is consistent with
> what I have on my system and it looks to be correct. Once this change
> was made none
On 2021-09-26 8:55 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> I checked out the init.d directories provided by Thorsten. One of the
>> features of insserv allows it to test init scripts in an alternative
>> directory or chroot.
> This seems to be broken:
>
>
On 2021-09-26 8:55 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> I checked out the init.d directories provided by Thorsten. One of the
>> features of insserv allows it to test init scripts in an alternative
>> directory or chroot.
> This seems to be broken:
>
>
On Sun, 26 Sep 2021, Jesse Smith wrote:
> I checked out the init.d directories provided by Thorsten. One of the
> features of insserv allows it to test init scripts in an alternative
> directory or chroot.
This seems to be broken:
tglase@tglase:~ $ insserv -p etc-stripped
insserv:
On 2021-09-26 3:25 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> behaviour. I've tried both the latest version of insserv (1.23.0) and
>> the version which shipped with Debian 10 (1.18.0). I did notice having
> This is Debian 11 so 1.21.0-1.1 (including Debian
On Sun, 26 Sep 2021, Jesse Smith wrote:
> I've tried this again on my own machine and cannot reproduce the
Does the attached file help? It’s my /etc/{init.d,rc*}/ stripped to
just reproduce the files up to the end of the LSB headers.
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions
On 2021-09-26 2:37 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> did last time. This time please run"
>>
>> # insserv -v -s
>>
>> This should set avahi-daemon to K01. Then run
> Erm, well, it doesn’t. Apparently, the presence of -s prevents this.
You're right, that's
On Sun, 26 Sep 2021, Jesse Smith wrote:
> behaviour. I've tried both the latest version of insserv (1.23.0) and
> the version which shipped with Debian 10 (1.18.0). I did notice having
This is Debian 11 so 1.21.0-1.1 (including Debian patches).
> Thorsten, I wonder if you could give the latest
On Sun, 26 Sep 2021, Jesse Smith wrote:
> did last time. This time please run"
>
> # insserv -v -s
>
> This should set avahi-daemon to K01. Then run
Erm, well, it doesn’t. Apparently, the presence of -s prevents this.
> # insserv -v -s -n
>
> This should tell us whether insserv wants to
On 2021-09-26 1:54 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> Something that might be useful here is seeing the output from "insserv
>> -v -s -n". This will show in what order insserv intends to assign each
>> service in each runlevel. No changes will be made to
Dixi quod…
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
> > Something that might be useful here is seeing the output from "insserv
> > -v -s -n". This will show in what order insserv intends to assign each
> > service in each runlevel. No changes will be made to the system when
> > insserv is run
On Sun, 26 Sep 2021, Jesse Smith wrote:
> Something that might be useful here is seeing the output from "insserv
> -v -s -n". This will show in what order insserv intends to assign each
> service in each runlevel. No changes will be made to the system when
> insserv is run with the "-n" flag.
On 2021-09-26 1:12 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Mark Hindley wrote:
>
>> Thorsten's original report[1] suggests it happens on every upgrade.
Not only every upgrade, but if I'm reading the report correctly it looks
like insserv is toggling between K01 and K02 with every time
On Sun, 26 Sep 2021, Mark Hindley wrote:
> Thorsten's original report[1] suggests it happens on every upgrade.
root@tglase:/etc # git status
On branch master
nothing to commit, working tree clean
root@tglase:/etc # insserv
root@tglase:/etc # git status
On branch master
Changes not staged for
Jesse,
On Sun, Sep 26, 2021 at 12:52:37PM -0300, Jesse Smith wrote:
> It's certainly possible insserv is renaming the shortcuts for
> avahi-daemon from K02 to K01. Though this raises a few questions, I believe:
>
> 1. Why do you think avahi-daemon should be prefixed with K02 instead of
> K01?
On 2021-09-26 7:10 a.m., Mark Hindley wrote:
> Jesse,
>
> On Mon, May 31, 2021 at 04:40:17AM +0200, Thorsten Glaser wrote:
>> Package: insserv
>> Version: 1.21.0-1.1
>> Severity: normal
>> X-Debbugs-Cc: t...@mirbsd.de
>>
>> I believe this is insserv; if not, feel free to reassign.
>>
>> With every
Jesse,
On Mon, May 31, 2021 at 04:40:17AM +0200, Thorsten Glaser wrote:
> Package: insserv
> Version: 1.21.0-1.1
> Severity: normal
> X-Debbugs-Cc: t...@mirbsd.de
>
> I believe this is insserv; if not, feel free to reassign.
>
> With every update, I have etckeeper churn:
>
> [master 8a1a489]
Package: insserv
Version: 1.21.0-1.1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I believe this is insserv; if not, feel free to reassign.
With every update, I have etckeeper churn:
[master 8a1a489] committing changes in /etc made by "apt-get --purge
dist-upgrade"
Author: mirabilos <…>
4
26 matches
Mail list logo
