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 files changed, 91 insertions(+), 9 deletions(-)
rename rc0.d/{K02avahi-daemon => K01avahi-daemon} (100%)
rename rc1.d/{K02avahi-daemon => K01avahi-daemon} (100%)
rename rc6.d/{K02avahi-daemon => K01avahi-daemon} (100%)
Basically, avahi-daemon toggles between K01 and K02 every time.
This is annoying and a waste of git space.
Jesse, I can't see where/how this is happening in insserv. Can you identify the cause? Thanks Mark
Hi Mark, 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? (Or does it switch back and force every time insserv is run?) On my system it is set as K01 and this looks to be correct. 2. Is there a service on the system that is getting added/removed/changed during the apt upgrade process that is affecting the order in which avahi-daemin is getting shutdown? I'm suggesting it's likely insserv is making the change, I'm just not sure if it's a bug without knowing what else is changing on the system. Jesse
Jesse, I think Thorsten's point is that it is switched back and forth each time and that change (presumably stat mtime or similar) is detected by etckeeper and forces a commit. Thorsten's original report[1] suggests it happens on every upgrade. Thanks for your help/ Mark [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989284#5
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 commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: rc0.d/K02avahi-daemon
deleted: rc1.d/K02avahi-daemon
deleted: rc6.d/K02avahi-daemon
Untracked files:
(use "git add <file>..." to include in what will be committed)
rc0.d/K01avahi-daemon
rc1.d/K01avahi-daemon
rc6.d/K01avahi-daemon
no changes added to commit (use "git add" and/or "git commit -a")
root@tglase:/etc # insserv
root@tglase:/etc # git status
On branch master
nothing to commit, working tree clean
So it happens on every insserv call.
||/ Name Version Architecture Description
+++-==============-============-============-===================================================================>
ii insserv 1.21.0-1.1 amd64 boot sequence organizer using LSB init.d script dependency informat>
(used to be x32 but I changed all sid systems to bullseye
to avoid UsrMove)
bye,
//mirabilos
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 it is run, even if no "apt upgrade" happens. Assuming I'm reading that report correctly that means insserv is giving different output from the same input every time. I've tried this on my own machine with avahi-daemon installed and I'm not seeing the same thing, in my case it always gets assigned to K01avahi-daemon. 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. It might also be useful to have the LSB header from the avahi-daemon service file in /etc/init.d/ Jesse
Attached. root@tglase:/etc # head -15 /etc/init.d/avahi-daemon #!/bin/sh ### BEGIN INIT INFO # Provides: avahi avahi-daemon # Required-Start: $remote_fs dbus # Required-Stop: $remote_fs dbus # Should-Start: $syslog # Should-Stop: $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Avahi mDNS/DNS-SD Daemon # Description: Zeroconf daemon for configuring your network # automatically ### END INIT INFO PATH=/sbin:/bin:/usr/sbin:/usr/bin 🐈, //mirabilos
Dixi quod… … erm, welp, now. Mraw, //mirabilos
Thanks, Thorseten, this is very helpful. So if I understand correctly if you do the "apt upgrade" process now (or a regular insserv call) avahi-daemon will get set to K01. Which looks right to me. But then if you run insserv a second time it toggles back to K02? Could you try this for me? Send me the same style of recored output you did last time. This time please run" # insserv -v -s This should set avahi-daemon to K01. Then run # insserv -v -s -n This should tell us whether insserv wants to toggle avahi-daemon back to K02, but without actually making any changes. And hopefully it will give a clue as to why this is happening.Thank you. - Jesse
Erm, well, it doesn’t. Apparently, the presence of -s prevents this. Maybe the attached will still suffice as clue? bye, //mirabilos
You're right, that's my mistake. I forgot the "-s" flag will show what insserv plans to do, but not actually update the symlinks. Based on the output you shared it does indeed look like that whenever avahi-daemon is set to K02, insserv wants to switch it back to K01. But then when insserv is run again, without the -s or -n flags indicating a dry run, it tries to switch things back from K01 to K02. This is indeed strange. I've tried this again on my own machine and cannot reproduce the 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 other dependency trouble when I tested with insserv 1.21.0 which I believe is the version being used when the bug is triggered? Thorsten, I wonder if you could give the latest version of insserv a try (version 1.23.0) which can be downloaded here: https://download.savannah.nongnu.org/releases/sysvinit/insserv-1.23.0.tar.xz Perhaps this is related to a previous dependency issue we already fixed in 1.21.0. Or, if you're still experiencing the problem with insserv 1.23.0 then we've got a bigger mystery. - Jesse
This is Debian 11 so 1.21.0-1.1 (including Debian patches). No, this is a remote machine where I prefer to not risk bootability. Sorry, //mirabilos
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
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. I ran insserv versions 1.18.0, 1.21.0, and 1.23.0 against the init.d scripts provided in the "etc-stripped" directory Thorsten uploaded. 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 of the three versions of insserv suggested switching avahi-daemon back to K02. ie On my system insserv does not perform the "toggle" action when given the uploaded init scripts. Which means when any recent version of insserv is run against just the init.d scripts provided it sets avahi-daemon to be K01 and leaves it that way, future runs don't toggle the symlink back. At least that's been my finding. Can anyone else confirm that running "insserv -p etc-stripped/init.d" on the uploaded scripts always sets avahi-daemon to K01, or do you get the "toggle" behaviour in the bug report? If others see the same behaviour I do, then I'm guessing there is something else on the reporting system with the error which causes a conflict. But if other people are seeing the "toggle" between K01 and K02 on the provided scripts then I'm guessing things are just working correctly for me due to an oversight or quirk of my system. Any feedback on confirming or disputing my findings is appreciated. - Jesse
This seems to be broken: tglase@tglase:~ $ insserv -p etc-stripped insserv: fopen(/etc/init.d/.depend.boot): Permission denied (Having extracted the tarball as regular user so there are no permission issues.) Do you want strace(1)s or so? bye, //mirabilos
Hmm, that's interesting. What happens if you run "insserv -n -p etc-stripped"? And then, if it suggests changing the symlinks from K02 to K01, doing that manually? eg "mv etc-stripped/rc0.d/K02avahi-daemon etc-stripped/rc0.d/K01avahi-daemon" and then re-running insserv? Not yet, let's see what the above tests reveals first and go from there.
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. Jesse
Jesse,
Not quite.
Testing both versions 1.18.0-2 and 1.23.0-1 (with the same results), I find that
initially insserv made no changes, leaving the links at K02. If the links are
deleted they are recreated as K01.
I can't reproduce any toggle behaviour. However, if I change
rc0.d/K01avahi-daemon to rc0.d/K02avahi-daemon, insserv changes the links in
rc{1,6}.d to K02. That surprised me as I rather expected the link in rc0.d to be
changed back to K01.
This also happens in reverse if all the links are K02 and rc0.d is changed to
K01, the next insserv invocation changes all the links to K01.
So it seems as if insserv chooses K01 by default, but doesn't change K02 to
K01. Furthermore, higher numbers are reduced to K02, but never K01.
Thorsten, I am wondering if you have anything in /etc/insserv/overrides or
changes to /etc/insserv.conf*?
Mark
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 root 4096 Nov 23 2012 /etc/insserv/overrides 2102322 4 -rw-r--r-- 1 root root 874 Jul 14 2019 /etc/insserv.conf 2097289 4 drwxr-xr-x 2 root root 4096 Jul 15 20:50 /etc/insserv.conf.d 2099611 4 -rw-r--r-- 1 root root 30 Jan 25 2017 /etc/insserv.conf.d/postfix 2107331 4 -rw-r--r-- 1 root root 36 Nov 7 2014 /etc/insserv.conf.d/kdm I wouldn’t know, but I don’t think so. But look for yourself: tglase@tglase:~ $ cat /etc/insserv.conf.d/kdm $x-display-manager kdm tglase@tglase:~ $ cat /etc/insserv.conf.d/postfix $mail-transport-agent postfix tglase@tglase:~ $ sed '/^#/d' /etc/insserv.conf | cat -s $local_fs +mountall +mountall-bootclean +mountoverflowtmp +umountfs $network +networking +ifupdown $named +named +dnsmasq +lwresd +bind9 +unbound +pdns-recursor $network $remote_fs $local_fs +mountnfs +mountnfs-bootclean +umountnfs +sendsigs $syslog +rsyslog +sysklogd +syslog-ng +dsyslog +inetutils-syslogd $time +hwclock <interactive> glibc udev console-screen keymap keyboard-setup console-setup cryptdisks cryptdisks-early checkfs-loop bye, //mirabilos
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 tglase@tglase:~ $ cp -a etc-stripped etc-stripped2 tglase@tglase:~ $ insserv -p etc-stripped/init.d -i etc-stripped/init.d tglase@tglase:~ $ cp -a etc-stripped etc-stripped3 etc-stripped1 is the same as etc-stripped3, and in etc-stripped2, the K links changed as did .depend.stop. //mirabilos
Thorsten, 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 am going to tag this unreproducible until we can work out what is different on the system that is causing problems. Any insight or suggestions from you would be most welcome. Thanks Mark
I don’t understand this: on another bullseye system (my laptop),
this is not even just reproducible but introduces even more diff:
tglase@tglase-nb:~ $ cdiff --stat etc-stripped{1,2}
{etc-stripped1 => etc-stripped2}/init.d/.depend.boot | 26 +++++++++++-----------
{etc-stripped1 => etc-stripped2}/init.d/.depend.start | 40 +++++++++++++++++-----------------
{etc-stripped1 => etc-stripped2}/init.d/.depend.stop | 14 ++++++------
.../rc0.d/K02avahi-daemon => etc-stripped2/rc0.d/K01avahi-daemon | 0
.../rc1.d/K02avahi-daemon => etc-stripped2/rc1.d/K01avahi-daemon | 0
etc-stripped1/rc2.d/S04apache2 => etc-stripped2/rc2.d/S03apache2 | 0
etc-stripped1/rc2.d/S03openvpn => etc-stripped2/rc2.d/S04openvpn | 0
etc-stripped1/rc3.d/S04apache2 => etc-stripped2/rc3.d/S03apache2 | 0
etc-stripped1/rc3.d/S03openvpn => etc-stripped2/rc3.d/S04openvpn | 0
etc-stripped1/rc4.d/S04apache2 => etc-stripped2/rc4.d/S03apache2 | 0
etc-stripped1/rc4.d/S03openvpn => etc-stripped2/rc4.d/S04openvpn | 0
etc-stripped1/rc5.d/S04apache2 => etc-stripped2/rc5.d/S03apache2 | 0
etc-stripped1/rc5.d/S03openvpn => etc-stripped2/rc5.d/S04openvpn | 0
.../rc6.d/K02avahi-daemon => etc-stripped2/rc6.d/K01avahi-daemon | 0
14 files changed, 40 insertions(+), 40 deletions(-)
1|tglase@tglase-nb:~ $ cdiff --stat etc-stripped{2,}
{etc-stripped2 => etc-stripped}/init.d/.depend.start | 4 ++--
{etc-stripped2 => etc-stripped}/init.d/.depend.stop | 12 ++++++------
etc-stripped2/rc0.d/K01avahi-daemon => etc-stripped/rc0.d/K02avahi-daemon | 0
etc-stripped2/rc1.d/K01avahi-daemon => etc-stripped/rc1.d/K02avahi-daemon | 0
etc-stripped2/rc6.d/K01avahi-daemon => etc-stripped/rc6.d/K02avahi-daemon | 0
5 files changed, 8 insertions(+), 8 deletions(-)
1|tglase@tglase-nb:~ $ cdiff --stat etc-stripped{1,}
{etc-stripped1 => etc-stripped}/init.d/.depend.boot | 26 +++++++++++++-------------
{etc-stripped1 => etc-stripped}/init.d/.depend.start | 38 +++++++++++++++++++-------------------
{etc-stripped1 => etc-stripped}/init.d/.depend.stop | 12 ++++++------
etc-stripped1/rc2.d/S04apache2 => etc-stripped/rc2.d/S03apache2 | 0
etc-stripped1/rc2.d/S03openvpn => etc-stripped/rc2.d/S04openvpn | 0
etc-stripped1/rc3.d/S04apache2 => etc-stripped/rc3.d/S03apache2 | 0
etc-stripped1/rc3.d/S03openvpn => etc-stripped/rc3.d/S04openvpn | 0
etc-stripped1/rc4.d/S04apache2 => etc-stripped/rc4.d/S03apache2 | 0
etc-stripped1/rc4.d/S03openvpn => etc-stripped/rc4.d/S04openvpn | 0
etc-stripped1/rc5.d/S04apache2 => etc-stripped/rc5.d/S03apache2 | 0
etc-stripped1/rc5.d/S03openvpn => etc-stripped/rc5.d/S04openvpn | 0
11 files changed, 38 insertions(+), 38 deletions(-)
bye,
//mirabilos
(back to the desktop in question) I’ve attached straces:
tglase@tglase:~ $ strace -f -o run1 insserv -p etc-stripped/init.d -i etc-stripped/init.d
tglase@tglase:~ $ strace -f -o run2 insserv -p etc-stripped/init.d -i etc-stripped/init.d
tglase@tglase:~ $ strace -f -o run3 insserv -p etc-stripped/init.d -i etc-stripped/init.d
tglase@tglase:~ $ strace -f -o run4 -e file insserv -p etc-stripped/init.d -i etc-stripped/init.d
From the run4 (file accesses only), after grepping out ENOENT
and grepping for /etc (/usr was only the README), these remain:
3768 openat(AT_FDCWD, "/etc/insserv.conf", O_RDONLY) = 3
3768 openat(AT_FDCWD, "/etc/insserv.conf.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
3768 stat("/etc/insserv.conf.d/postfix", {st_mode=S_IFREG|0644, st_size=30, ...}) = 0
3768 openat(AT_FDCWD, "/etc/insserv.conf.d/postfix", O_RDONLY) = 3
3768 stat("/etc/insserv.conf.d/kdm", {st_mode=S_IFREG|0644, st_size=36, ...}) = 0
3768 openat(AT_FDCWD, "/etc/insserv.conf.d/kdm", O_RDONLY) = 3
So apparently insserv still accesses system-global configuration,
maybe that’s it? Attaching all three files.
bye,
//mirabilos
Thorsten Glaser writes ("Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade"):
I've looked through the bug logs here and it is obvious we are all
missing something.
Thorsten, can you provide a formal Steps To Reproduce that start with
something like "in a chroot", and which you have verified ? Ie,
something that you think would allow me (say) to reproduce it in a way
that has minimal dependencies on our respective normal environments ?
Ian.
Right, I just did that and was just going to post this when your mail
came ;)
I’ve got a cowbuilder chroot with bullseye/amd64 and have just updated
it to get the latest updates installed. Then I did cowbuilder --login,
waited until the chroot is there, and copied the etc-stripped.tgz from
the previous eMail into its /tmp.
Then follows:
(pbuild11683-bullseye/amd64)root@tglase:/tmp# tar xaf etc-stripped.tgz
(pbuild11683-bullseye/amd64)root@tglase:/tmp# cp -a etc-stripped etc-stripped1
(pbuild11683-bullseye/amd64)root@tglase:/tmp# insserv -p etc-stripped/init.d -i etc-stripped/init.d
(pbuild11683-bullseye/amd64)root@tglase:/tmp# cp -a etc-stripped etc-stripped2
(pbuild11683-bullseye/amd64)root@tglase:/tmp# insserv -p etc-stripped/init.d -i etc-stripped/init.d
(pbuild11683-bullseye/amd64)root@tglase:/tmp# cp -a etc-stripped etc-stripped3
(pbuild11683-bullseye/amd64)root@tglase:/tmp# insserv -p etc-stripped/init.d -i etc-stripped/init.d
(pbuild11683-bullseye/amd64)root@tglase:/tmp# cp -a etc-stripped etc-stripped4
I did the verification outside of the chroot:
tglase@tglase:...ar/cache/pbuilder/build/cow.11662/tmp $ cdiff --stat etc-stripped{1,3}
tglase@tglase:...ar/cache/pbuilder/build/cow.11662/tmp $ cdiff --stat etc-stripped{2,4}
tglase@tglase:...ar/cache/pbuilder/build/cow.11662/tmp $ cdiff --stat etc-stripped{1,2}
{etc-stripped1 => etc-stripped2}/init.d/.depend.stop | 12 ++++++------
etc-stripped1/rc0.d/K02avahi-daemon => etc-stripped2/rc0.d/K01avahi-daemon | 0
etc-stripped1/rc1.d/K02avahi-daemon => etc-stripped2/rc1.d/K01avahi-daemon | 0
etc-stripped1/rc6.d/K02avahi-daemon => etc-stripped2/rc6.d/K01avahi-daemon | 0
4 files changed, 6 insertions(+), 6 deletions(-)
1|tglase@tglase:...ar/cache/pbuilder/build/cow.11662/tmp $ cdiff --stat etc-stripped{2,3}
{etc-stripped2 => etc-stripped3}/init.d/.depend.stop | 12 ++++++------
etc-stripped2/rc0.d/K01avahi-daemon => etc-stripped3/rc0.d/K02avahi-daemon | 0
etc-stripped2/rc1.d/K01avahi-daemon => etc-stripped3/rc1.d/K02avahi-daemon | 0
etc-stripped2/rc6.d/K01avahi-daemon => etc-stripped3/rc6.d/K02avahi-daemon | 0
4 files changed, 6 insertions(+), 6 deletions(-)
You’ll need this alias first:
alias cdiff='git diff --color=always --no-index --no-prefix'
So I can verify this behaviour in an otherwise clean chroot.
(pbuild11683-bullseye/amd64)root@tglase:/tmp# dpkg -l | cut -c 1-72
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tri
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
+++-=========================-============================-============-
ii adduser 3.118 all
ii apt 2.2.4 amd64
ii base-files 11.1 amd64
ii base-passwd 3.5.51 amd64
ii bash 5.1-2+b3 amd64
ii binutils 2.35.2-2 amd64
ii binutils-common:amd64 2.35.2-2 amd64
ii binutils-x86-64-linux-gnu 2.35.2-2 amd64
ii bsdutils 1:2.36.1-8 amd64
ii build-essential 12.9 amd64
ii bzip2 1.0.8-4 amd64
ii coreutils 8.32-4+b1 amd64
ii cowbuilder 0.89 amd64
ii cowdancer 0.89 amd64
ii cpp 4:10.2.1-1 amd64
ii cpp-10 10.2.1-6 amd64
ii cpp-8 8.4.0-6 amd64
ii dash 0.5.11+git20200708+dd9ef66-5 amd64
ii debconf 1.5.77 all
ii debian-archive-keyring 2021.1.1 all
ii debianutils 4.11.2 amd64
ii debootstrap 1.0.123 all
ii diffutils 1:3.7-5 amd64
ii dirmngr 2.2.27-2 amd64
ii dpkg 1.20.9 amd64
ii dpkg-dev 1.20.9 all
ii e2fslibs:amd64 1.45.6-1 amd64
ii e2fsprogs 1.46.2-2 amd64
ii eatmydata 105-9 all
ii fakeroot 1.25.3-1.1 amd64
ii findutils 4.8.0-1 amd64
ii g++ 4:10.2.1-1 amd64
ii g++-10 10.2.1-6 amd64
ii gcc 4:10.2.1-1 amd64
ii gcc-10 10.2.1-6 amd64
ii gcc-10-base:amd64 10.2.1-6 amd64
ii gcc-8 8.4.0-6 amd64
ii gcc-8-base:amd64 8.4.0-6 amd64
ii gcc-9-base:amd64 9.3.0-22 amd64
ii gnupg 2.2.27-2 all
ii gnupg-l10n 2.2.27-2 all
ii gnupg-utils 2.2.27-2 amd64
ii gpg 2.2.27-2 amd64
ii gpg-agent 2.2.27-2 amd64
ii gpg-wks-client 2.2.27-2 amd64
ii gpg-wks-server 2.2.27-2 amd64
ii gpgconf 2.2.27-2 amd64
ii gpgsm 2.2.27-2 amd64
ii gpgv 2.2.27-2 amd64
ii grep 3.6-1 amd64
ii gzip 1.10-4 amd64
ii hostname 3.23 amd64
ii init 1.60 amd64
ii init-system-helpers 1.60 all
ii initscripts 2.96-7 all
ii insserv 1.21.0-1.1 amd64
ii libacl1:amd64 2.2.53-10 amd64
ii libapt-pkg6.0:amd64 2.2.4 amd64
ii libasan5:amd64 9.3.0-22 amd64
ii libasan6:amd64 10.2.1-6 amd64
ii libassuan0:amd64 2.5.3-7.1 amd64
ii libatomic1:amd64 10.2.1-6 amd64
ii libattr1:amd64 1:2.4.48-6 amd64
ii libaudit-common 1:3.0-2 all
ii libaudit1:amd64 1:3.0-2 amd64
ii libbinutils:amd64 2.35.2-2 amd64
ii libblkid1:amd64 2.36.1-8 amd64
ii libbz2-1.0:amd64 1.0.8-4 amd64
ii libc-bin 2.31-13 amd64
ii libc-dev-bin 2.31-13 amd64
ii libc6:amd64 2.31-13 amd64
ii libc6-dev:amd64 2.31-13 amd64
ii libcap-ng0:amd64 0.7.9-2.2+b1 amd64
ii libcc1-0:amd64 10.2.1-6 amd64
ii libcom-err2:amd64 1.46.2-2 amd64
ii libcomerr2:amd64 1.45.6-1 amd64
ii libcrypt-dev:amd64 1:4.4.18-4 amd64
ii libcrypt1:amd64 1:4.4.18-4 amd64
ii libctf-nobfd0:amd64 2.35.2-2 amd64
ii libctf0:amd64 2.35.2-2 amd64
ii libdb5.3:amd64 5.3.28+dfsg1-0.8 amd64
ii libdebconfclient0:amd64 0.260 amd64
ii libdpkg-perl 1.20.9 all
ii libeatmydata1:amd64 105-9 amd64
ii libext2fs2:amd64 1.46.2-2 amd64
ii libfakeroot:amd64 1.25.3-1.1 amd64
ii libffi7:amd64 3.3-6 amd64
ii libfile-fcntllock-perl 0.22-3+b7 amd64
ii libgcc-10-dev:amd64 10.2.1-6 amd64
ii libgcc-8-dev:amd64 8.4.0-6 amd64
ii libgcc-s1:amd64 10.2.1-6 amd64
ii libgcrypt20:amd64 1.8.7-6 amd64
ii libgdbm-compat4:amd64 1.19-2 amd64
ii libgdbm6:amd64 1.19-2 amd64
ii libgmp10:amd64 2:6.2.1+dfsg-1 amd64
ii libgmpxx4ldbl:amd64 2:6.2.1+dfsg-1 amd64
ii libgnutls30:amd64 3.7.1-5 amd64
ii libgomp1:amd64 10.2.1-6 amd64
ii libgpg-error0:amd64 1.38-2 amd64
ii libgssapi-krb5-2:amd64 1.18.3-6 amd64
ii libhogweed6:amd64 3.7.3-1 amd64
ii libidn11:amd64 1.33-3 amd64
ii libidn2-0:amd64 2.3.0-5 amd64
ii libisl23:amd64 0.23-1 amd64
ii libitm1:amd64 10.2.1-6 amd64
ii libk5crypto3:amd64 1.18.3-6 amd64
ii libkeyutils1:amd64 1.6.1-2 amd64
ii libkrb5-3:amd64 1.18.3-6 amd64
ii libkrb5support0:amd64 1.18.3-6 amd64
ii libksba8:amd64 1.5.0-3 amd64
ii libldap-2.4-2:amd64 2.4.57+dfsg-3 amd64
ii libldap-common 2.4.57+dfsg-3 all
ii liblocale-gettext-perl 1.07-4+b1 amd64
ii liblsan0:amd64 10.2.1-6 amd64
ii liblz4-1:amd64 1.9.3-2 amd64
ii liblzma5:amd64 5.2.5-2 amd64
ii libmount1:amd64 2.36.1-8 amd64
ii libmpc3:amd64 1.2.0-1 amd64
ii libmpfr6:amd64 4.1.0-3 amd64
ii libmpx2:amd64 8.4.0-6 amd64
ii libncursesw6:amd64 6.2+20201114-2 amd64
ii libnettle8:amd64 3.7.3-1 amd64
ii libnpth0:amd64 1.6-3 amd64
ii libnsl-dev:amd64 1.3.0-2 amd64
ii libnsl2:amd64 1.3.0-2 amd64
ii libp11-kit0:amd64 0.23.22-1 amd64
ii libpam-modules:amd64 1.4.0-9 amd64
ii libpam-modules-bin 1.4.0-9 amd64
ii libpam-runtime 1.4.0-9 all
ii libpam0g:amd64 1.4.0-9 amd64
ii libpcre2-8-0:amd64 10.36-2 amd64
ii libpcre3:amd64 2:8.39-13 amd64
ii libperl5.32:amd64 5.32.1-4+deb11u1 amd64
ii libpsl5:amd64 0.21.0-1.2 amd64
ii libquadmath0:amd64 10.2.1-6 amd64
ii libreadline8:amd64 8.1-1 amd64
ii libsasl2-2:amd64 2.1.27+dfsg-2.1 amd64
ii libsasl2-modules-db:amd64 2.1.27+dfsg-2.1 amd64
ii libseccomp2:amd64 2.5.1-1 amd64
ii libselinux1:amd64 3.1-3 amd64
ii libsemanage-common 3.1-1 all
ii libsemanage1:amd64 3.1-1+b2 amd64
ii libsepol1:amd64 3.1-1 amd64
ii libslang2:amd64 2.3.2-5 amd64
ii libsmartcols1:amd64 2.36.1-8 amd64
ii libsqlite3-0:amd64 3.34.1-3 amd64
ii libss2:amd64 1.46.2-2 amd64
ii libssl1.0.0:amd64 1.0.2d-1 amd64
ii libssl1.1:amd64 1.1.1k-1+deb11u1 amd64
ii libstdc++-10-dev:amd64 10.2.1-6 amd64
ii libstdc++6:amd64 10.2.1-6 amd64
ii libsystemd0:amd64 247.3-6 amd64
ii libtasn1-6:amd64 4.16.0-2 amd64
ii libtext-charwidth-perl 0.04-10+b1 amd64
ii libtext-iconv-perl 1.7-7+b1 amd64
ii libtext-wrapi18n-perl 0.06-9 all
ii libtimedate-perl 2.3300-2 all
ii libtinfo6:amd64 6.2+20201114-2 amd64
ii libtirpc-common 1.3.1-1 all
ii libtirpc-dev:amd64 1.3.1-1 amd64
ii libtirpc3:amd64 1.3.1-1 amd64
ii libtsan0:amd64 10.2.1-6 amd64
ii libubsan1:amd64 10.2.1-6 amd64
ii libudev1:amd64 247.3-6 amd64
ii libunistring2:amd64 0.9.10-4 amd64
ii libusb-0.1-4:amd64 2:0.1.12-32 amd64
ii libuuid1:amd64 2.36.1-8 amd64
ii libxxhash0:amd64 0.8.0-2 amd64
ii libzstd1:amd64 1.4.8+dfsg-2.1 amd64
ii linux-libc-dev:amd64 5.10.46-5 amd64
ii login 1:4.8.1-1 amd64
ii logsave 1.46.2-2 amd64
ii lsb-base 11.1.0 all
ii make 4.3-4.1 amd64
ii mawk 1.3.4.20200120-2 amd64
ii mount 2.36.1-8 amd64
ii multiarch-support 2.28-10 amd64
ii ncurses-base 6.2+20201114-2 all
ii ncurses-bin 6.2+20201114-2 amd64
ii passwd 1:4.8.1-1 amd64
ii patch 2.7.6-7 amd64
ii pbuilder 0.231 all
ii perl 5.32.1-4+deb11u1 amd64
ii perl-base 5.32.1-4+deb11u1 amd64
ii perl-modules-5.32 5.32.1-4+deb11u1 all
ii pinentry-curses 1.1.0-4 amd64
ii readline-common 8.1-1 all
ii sed 4.7-1 amd64
ii sensible-utils 0.0.14 all
ii startpar 0.64-3 amd64
ii sysv-rc 2.96-7 all
ii sysvinit 2.88dsf-59.2 amd64
ii sysvinit-core 2.96-7 amd64
ii sysvinit-utils 2.96-7 amd64
ii tar 1.34+dfsg-1 amd64
ii tzdata 2021a-1 all
ii util-linux 2.36.1-8 amd64
ii wget 1.21-1+b1 amd64
ii xz-utils 5.2.5-2 amd64
ii zlib1g:amd64 1:1.2.11.dfsg-2 amd64
Ahem, okay, so clean but not minimal, but cpp-8 shouldn’t be the
one to disturb this, and it’s certainly not installed on the main
system. (This chroot has been around for some time. This, perhaps
importantly, means it does not implement UsrMove.)
So this doesn’t really depend on the insserv configs I sent after
all, I guess?
(pbuild11683-bullseye/amd64)root@tglase:/tmp# find /etc/ins\* -ls
find: '/etc/ins*': No such file or directory
bye,
//mirabilos
And https://mops.tarent.de/.tmp/base.cow-bullseye-amd64.tar.xz is the chroot, just in case it is something about that as well. bye, //mirabilos
Thorsten,
Thanks for this and sorry for taking some time to actually get round to trying
it.
I am afraid I am still unable to reproduce this behaviour in my own or your
supplied chroot.
The only thing that happens is a reordering of the .depend* files on the first
insserv invocation. After that, there are no changes on subsequent runs.
mark@apollo:/var/cache/pbuilder% sudo tar xJf ~/Downloads/base.cow-bullseye-amd64.tar.xz
mark@apollo:~% sudo cp /tmp/etc-stripped.tgz /var/cache/pbuilder/build/cow.23212/tmp/
mark@apollo:~% cdiff --stat /var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{,1}
.../init.d/.depend.boot | 20 ++++++++---------
.../init.d/.depend.start | 26 +++++++++++-----------
.../init.d/.depend.stop | 14 ++++++------
3 files changed, 30 insertions(+), 30 deletions(-)
mark@apollo:~% cdiff --stat /var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{1,2}
.../init.d/.depend.boot | 20 ++++++++---------
.../init.d/.depend.start | 26 +++++++++++-----------
.../init.d/.depend.stop | 14 ++++++------
3 files changed, 30 insertions(+), 30 deletions(-)
mark@apollo:~% cdiff --stat /var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{1,3}
.../init.d/.depend.boot | 20 ++++++++---------
.../init.d/.depend.start | 26 +++++++++++-----------
.../init.d/.depend.stop | 14 ++++++------
3 files changed, 30 insertions(+), 30 deletions(-)
mark@apollo:~% cdiff --stat /var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{1,4}
.../init.d/.depend.boot | 20 ++++++++---------
.../init.d/.depend.start | 26 +++++++++++-----------
.../init.d/.depend.stop | 14 ++++++------
3 files changed, 30 insertions(+), 30 deletions(-)
mark@apollo:~% cdiff --stat /var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{2,3}
mark@apollo:~% cdiff --stat /var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{2,4}
mark@apollo:~% cdiff --stat -u /var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{1,2}
.../init.d/.depend.boot | 20 ++++++++---------
.../init.d/.depend.start | 26 +++++++++++-----------
.../init.d/.depend.stop | 14 ++++++------
3 files changed, 30 insertions(+), 30 deletions(-)
diff --git var/cache/pbuilder/build/cow.23212/tmp/etc-stripped1/init.d/.depend.boot var/cache/pbuilder/build/cow.23212/tmp/etc-stripped2/i
nit.d/.depend.boot
index 3fc1825..54d3471 100644
--- var/cache/pbuilder/build/cow.23212/tmp/etc-stripped1/init.d/.depend.boot
+++ var/cache/pbuilder/build/cow.23212/tmp/etc-stripped2/init.d/.depend.boot
@@ -1,4 +1,4 @@
-TARGETS = mountkernfs.sh udev mountdevsubfs.sh keyboard-setup.sh bootlogd hwclock.sh hostname.sh checkroot.sh cryptdisks-early cryptdisks
networking mountnfs.sh mountnfs-bootclean.sh mountall.sh mountall-bootclean.sh lvm2 x11-common early-rng-init-tools urandom brightness al
sa-utils checkfs.sh checkroot-bootclean.sh screen-cleanup stop-bootlogd-single bootmisc.sh mount-configfs kmod procps lm-sensors
+TARGETS = mountkernfs.sh udev mountdevsubfs.sh keyboard-setup.sh bootlogd hwclock.sh hostname.sh checkroot.sh cryptdisks-early cryptdisks
mountnfs.sh mountnfs-bootclean.sh mountall.sh mountall-bootclean.sh brightness networking lvm2 checkfs.sh urandom x11-common early-rng-in
it-tools alsa-utils mount-configfs kmod bootmisc.sh procps screen-cleanup stop-bootlogd-single lm-sensors checkroot-bootclean.sh
INTERACTIVE = udev keyboard-setup.sh checkroot.sh cryptdisks-early cryptdisks checkfs.sh
udev: mountkernfs.sh
mountdevsubfs.sh: udev
@@ -9,23 +9,23 @@ hostname.sh: bootlogd
checkroot.sh: hostname.sh keyboard-setup.sh
cryptdisks-early: checkroot.sh udev
cryptdisks: cryptdisks-early lvm2
-networking: mountkernfs.sh mountall.sh mountall-bootclean.sh urandom procps
mountnfs.sh: mountall.sh mountall-bootclean.sh networking
mountnfs-bootclean.sh: mountall.sh mountall-bootclean.sh mountnfs.sh
-mountall.sh: checkfs.sh checkroot-bootclean.sh
+mountall.sh: lvm2 checkfs.sh checkroot-bootclean.sh
mountall-bootclean.sh: mountall.sh
+brightness: mountall.sh mountall-bootclean.sh
+networking: mountkernfs.sh mountall.sh mountall-bootclean.sh urandom procps
lvm2: cryptdisks-early bootlogd
+checkfs.sh: checkroot.sh cryptdisks lvm2
+urandom: hwclock.sh mountall.sh mountall-bootclean.sh
x11-common: mountnfs.sh mountnfs-bootclean.sh
early-rng-init-tools: hwclock.sh mountall.sh mountall-bootclean.sh
-urandom: hwclock.sh mountall.sh mountall-bootclean.sh
-brightness: mountall.sh mountall-bootclean.sh
alsa-utils: mountall.sh mountall-bootclean.sh mountnfs.sh mountnfs-bootclean.sh
-checkfs.sh: checkroot.sh cryptdisks lvm2
-checkroot-bootclean.sh: checkroot.sh
-screen-cleanup: mountnfs.sh mountnfs-bootclean.sh
-stop-bootlogd-single: mountall.sh mountall-bootclean.sh
-bootmisc.sh: udev checkroot-bootclean.sh mountnfs-bootclean.sh mountall-bootclean.sh mountnfs.sh mountall.sh
I am unclear as to the significance of the reordering of .depends.* that
happens on the first run. Jesse, is that expected. Does it point to something?
As Ian said previously, we are clearly still missing something here. I am pretty much in
the dark and clutching at straws. But what filesystem are you using? My
/var/cache/pbuilder is ext3.
Sorry not to have a more helpful response at this stage.
Best wishes
Mark
Mine is on: /dev/mapper/vg--tglase-lv--tglase on / type ext4 (rw,relatime) Also not with my supplied chroot‽ So it’s nothing about differences in the chroot either… good to know, but puzzling for this issue. bye, //mirabilos
I suspect the initial reordering probably indicates one of two things: 1. There is something about the host system that is causing insserv to toggle ordering back and forth which we haven't been able to reproduce. This would result in insserv switching things back to "normal" when run on another system, and then leave it be. 2. Something on the host system changed init script dependencies, resulting in a reshuffling. This isn't necessarily a bad thing, it can happen when a script is added or removed from /etc/init.d, possibly by the package manager. It usually just indicated something changed since the last time insserv was run. Jesse
But what, given I can reproduce this in a chroot and on my laptop? bye, //mirabilos
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. I realise this may be clutching at straws, but is there any chance the x32 arch is the trigger for this? I don't see any other discrepancies. Mark
Mark Hindley dixit: 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 different architecture, when copying these files over, as well as in a clean chroot. bye, //mirabilos
That's an interesting idea. Given everything else we've tried I'm open to the possibility. I didn't realize until you mentioned it that Debian even supported x32 builds these days.