Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev

[shirish शिरीष]

Package: insserv
Version: 1.18.0-2
Severity: important

Dear Maintainer,

Got the following somewhat scary message when updating -

Setting up udev (240-6) ...
update-initramfs: deferring update (trigger activated)
insserv: FATAL: service mountkernfs has to be enabled to use service udev

maybe it just needs mountkernfs to be added in the interactive bit at
the bottom or somewhere else ?

$ cat /etc/insserv.conf
#
# All local filesystems are mounted (done during boot phase)
#
$local_fs +mountall +mountall-bootclean +mountoverflowtmp +umountfs

#
# Low level networking (ethernet card)
#
$network +networking +ifupdown

#
# Named is operational
#
$named +named +dnsmasq +lwresd +bind9 +unbound $network

#
# All remote filesystems are mounted (note in some cases /usr may
# be remote. Most applications that care will probably require
# both $local_fs and $remote_fs)
#
$remote_fs $local_fs +mountnfs +mountnfs-bootclean +umountnfs +sendsigs

#
# System logger is operational
#
$syslog +rsyslog +sysklogd +syslog-ng +dsyslog +inetutils-syslogd

#
# The system time has been set correctly
#
$time +hwclock

#
# Services which need to be interactive
#
<interactive> glibc udev console-screen keymap keyboard-setup
console-setup cryptdisks cryptdisks-early checkfs-loop

-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages insserv depends on:
ii libc6 2.28-7

insserv recommends no packages.

Versions of packages insserv suggests:
ii bootchart2 0.14.4-3+b1

-- no debconf information

--
Regards,
Shirish Agarwal शिरीष अग्रवाल
My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8

[Dmitry Bogatov]

[2019-02-21 05:09] shirish शिरीष <shiri...@gmail.com>

> Package: insserv
> Version: 1.18.0-2
> Severity: important
>
> Dear Maintainer,
>
> Got the following somewhat scary message when updating -
>
> Setting up udev (240-6) ...
> update-initramfs: deferring update (trigger activated)
> insserv: FATAL: service mountkernfs has to be enabled to use service udev
>
> maybe it just needs mountkernfs to be added in the interactive bit at
> the bottom or somewhere else ?

Maybe. But I updated recently, and I did not encountered this problem.
Please test my wild guess:

$ find /etc/rcS.d|grep mountkernfs

--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--

[shirish शिरीष]

Reply at bottom :-

Dear Dmitry,

The output is empty or zero -

shirish@debian:~$ find /etc/rcS.d|grep mountkernfs
shirish@debian:~$

[Dmitry Bogatov]

[2019-02-22 15:30] shirish शिरीष <shiri...@gmail.com>

> > >
> > > Setting up udev (240-6) ...
> > > update-initramfs: deferring update (trigger activated)
> > > insserv: FATAL: service mountkernfs has to be enabled to use service udev
> > >
> > > maybe it just needs mountkernfs to be added in the interactive bit at
> > > the bottom or somewhere else ?

> > [Dmitry Bogatov]

> > Maybe. But I updated recently, and I did not encountered this problem.
> > Please test my wild guess:
> >
> > $ find /etc/rcS.d|grep mountkernfs
> >

> Dear Dmitry,
>
> The output is empty or zero -
>
> shirish@debian:~$ find /etc/rcS.d|grep mountkernfs
> shirish@debian:~$

Interesting, you seems somehow got mountkernfs.sh script removed from
runlevel S.

Can you please invoke as root

# update-rc.d mountkernfs.sh enable S

and then retry your upgrade.

[shirish शिरीष]

Reply at bottom :-

On 24/02/2019, Dmitry Bogatov <KAc...@debian.org> wrote:

<snipped>

> Interesting, you seems somehow got mountkernfs.sh script removed from
> runlevel S.
>
> Can you please invoke as root
>
> # update-rc.d mountkernfs.sh enable S
>
> and then retry your upgrade.

When I try the command you shared, it says -

root@debian:~# update-rc.d mountkernfs.sh enable S
update-rc.d: error: cannot find a LSB script for mountkernfs.sh

> --
> Note, that I send and fetch email in batch, once every 24 hours.
> If matter is urgent, try https://t.me/kaction
>
> --
>

[Dmitry Bogatov]

[2019-02-25 05:45] shirish शिरीष <shiri...@gmail.com>

> On 24/02/2019, Dmitry Bogatov <KAc...@debian.org> wrote:
>
> <snipped>
>
> > Interesting, you seems somehow got mountkernfs.sh script removed from
> > runlevel S.
> >
> > Can you please invoke as root
> >
> > # update-rc.d mountkernfs.sh enable S
> >
> > and then retry your upgrade.
>
> When I try the command you shared, it says -
>
> root@debian:~# update-rc.d mountkernfs.sh enable S
> update-rc.d: error: cannot find a LSB script for mountkernfs.sh

Seems there is no /etc/init.d/mountkernfs.sh on your system.

Since your init system is systemd, I question, why do you need insserv
in first place. Do you have bin:initscripts installed?

My guess is that update-initramfs invokes insserv /if/ it is available,
and since you have insserv installed, but no initscripts, we get this
bug.

Adding initramfs-tools maintainer into loop. If my guess is correct,
this issue should be resolved on initramfs side, since making insserv
depending on initscripts is not nice to user.

[shirish शिरीष]

at bottom :-

On 27/02/2019, Dmitry Bogatov <KAc...@debian.org> wrote:
>

<snipped>

>

> Seems there is no /etc/init.d/mountkernfs.sh on your system.
>
> Since your init system is systemd, I question, why do you need insserv
> in first place. Do you have bin:initscripts installed?
>
> My guess is that update-initramfs invokes insserv /if/ it is available,
> and since you have insserv installed, but no initscripts, we get this
> bug.
>
> Adding initramfs-tools maintainer into loop. If my guess is correct,
> this issue should be resolved on initramfs side, since making insserv
> depending on initscripts is not nice to user.
> --
> Note, that I send and fetch email in batch, once every 24 hours.
> If matter is urgent, try https://t.me/kaction
>
> --
>

Dear Dimity,

You are right on both counts. Indeed systemd is pid 0 on my system.

In answer to your query, I attempted -

$ aptitude why insserv
i rcconf Depends sysv-rc
i A sysv-rc Depends insserv (> 1.12.0-10)

Does this answer the question ?

[Ben Hutchings]

On Wed, 2019-02-27 at 03:01 +0000, Dmitry Bogatov wrote:
> [2019-02-25 05:45] shirish शिरीष <shiri...@gmail.com>
> > On 24/02/2019, Dmitry Bogatov <KAc...@debian.org> wrote:
> >
> > <snipped>
> >
> > > Interesting, you seems somehow got mountkernfs.sh script removed from
> > > runlevel S.
> > >
> > > Can you please invoke as root
> > >
> > > # update-rc.d mountkernfs.sh enable S
> > >
> > > and then retry your upgrade.
> >
> > When I try the command you shared, it says -
> >
> > root@debian:~# update-rc.d mountkernfs.sh enable S
> > update-rc.d: error: cannot find a LSB script for mountkernfs.sh
>
> Seems there is no /etc/init.d/mountkernfs.sh on your system.
>
> Since your init system is systemd, I question, why do you need insserv
> in first place. Do you have bin:initscripts installed?
>
> My guess is that update-initramfs invokes insserv /if/ it is available,
> and since you have insserv installed, but no initscripts, we get this
> bug.

It does not.

Ben.

> Adding initramfs-tools maintainer into loop. If my guess is correct,
> this issue should be resolved on initramfs side, since making insserv
> depending on initscripts is not nice to user.
--

Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill Gates

[Dmitry Bogatov]

control: reassign -1 udev

[2019-02-27 08:00] shirish शिरीष <shiri...@gmail.com>

> > Seems there is no /etc/init.d/mountkernfs.sh on your system.
> >
> > Since your init system is systemd, I question, why do you need insserv
> > in first place. Do you have bin:initscripts installed?
> >
> > My guess is that update-initramfs invokes insserv /if/ it is available,
> > and since you have insserv installed, but no initscripts, we get this
> > bug.
> >
> > Adding initramfs-tools maintainer into loop. If my guess is correct,
> > this issue should be resolved on initramfs side, since making insserv
> > depending on initscripts is not nice to user.
> > --
> > Note, that I send and fetch email in batch, once every 24 hours.
> > If matter is urgent, try https://t.me/kaction
> >
> > --
> >
>
> Dear Dimity,
>
> You are right on both counts. Indeed systemd is pid 0 on my system.
>
> In answer to your query, I attempted -
>
> $ aptitude why insserv
> i rcconf Depends sysv-rc
> i A sysv-rc Depends insserv (> 1.12.0-10)
>
> Does this answer the question?

Well, it does answer how to workaround problem -- either install
initscripts or remove insserv. But in general, you are in your right
to have this combination of packages on your system.

Since initramfs-maintainer says, that initramfs-tools do not invoke
insserv, another guess is udev/init-system-helpers. Reassigning for
udev.

[Felipe Sateler]

On Thu, Feb 28, 2019 at 6:50 PM Michael Biebl <bi...@debian.org> wrote:
>
> Am 28.02.19 um 14:08 schrieb Michael Biebl:

>
> >> Since initramfs-maintainer says, that initramfs-tools do not invoke
> >> insserv, another guess is udev/init-system-helpers. Reassigning for
> >> udev.
> >

> > Dmitry, since you reassigned this to udev without further explanation,
> > what would you suggest should the udev package do about this?
>
> Adding a "initscripts" dependency to the udev package is clearly a bad
> idea, since udev does not depend on the initscripts package.
>
> There are couple of different solutions:
> 1) Ignore the issue. It's a warning only after all.
> 2) Add Conflicts: insserv to systemd-sysv, so the package is kicked out
> on upgrades (and maybe add sysv-rc, startpar, initscripts to that list).
> This would ensure that users of systemd don't end up with those packages
> installed.
> 3) Add a initscripts dependency to insserv. If you are using insserv,
> you probably want the facilities provided by initscripts.
>
>

I think insserv should depend on initscripts. It requires that to
actually do anything.

Adding Conflicts will likely make switching inits much more difficult.


--

Saludos,
Felipe Sateler

[Michael Biebl]

Control: reassign -1 insserv

On Thu, 28 Feb 2019 19:13:31 -0300 Felipe Sateler <fsat...@debian.org>
wrote:

Nod, reassigning back to insserv.

Regards,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Dmitry Bogatov]

[2019-03-05 23:41] Michael Biebl <bi...@debian.org>
> Control: reassign -1 insserv

> > I think insserv should depend on initscripts. It requires that to
> > actually do anything.
> >
> > Adding Conflicts will likely make switching inits much more difficult.
>
> Nod, reassigning back to insserv.

Bug is in incorrect usage of insserv, not within insserv. You may want to
add check, that /etc/init.d/mountkernfs.sh exists.

If it will help you, I can add 'Recommends' (not Depends) on
bin:initscripts into insserv.

If if you disagree, please close + wontfix this bug.

[Dmitry Bogatov]

control: tags -1 +moreinfo
control: user KAc...@debian.org
control: usertags -1 +objections

[2019-03-07 14:45] Dmitry Bogatov <KAc...@debian.org>

> [2019-03-05 23:41] Michael Biebl <bi...@debian.org>
> > Control: reassign -1 insserv
> > > I think insserv should depend on initscripts. It requires that to
> > > actually do anything.
> > >
> > > Adding Conflicts will likely make switching inits much more difficult.
> >
> > Nod, reassigning back to insserv.
>
> Bug is in incorrect usage of insserv, not within insserv. You may want to
> add check, that /etc/init.d/mountkernfs.sh exists.
>
> If it will help you, I can add 'Recommends' (not Depends) on
> bin:initscripts into insserv.
>
> If if you disagree, please close + wontfix this bug.

On second thought, maybe it is okay to add dependency of insserv on
initscripts? After all, we already have initscripts installed, and
systemd users are unlikely to complain about bloat...

Opinions?
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

[Thomas Uhle]

On Sat, 13 Jul 2019, Dmitry Bogatov wrote:

> control: tags -1 +moreinfo
> control: user KAc...@debian.org
> control: usertags -1 +objections
>
> [2019-03-07 14:45] Dmitry Bogatov <KAc...@debian.org>
> > [2019-03-05 23:41] Michael Biebl <bi...@debian.org>
> > > Control: reassign -1 insserv
> > > > I think insserv should depend on initscripts. It requires that to
> > > > actually do anything.
> > > >
> > > > Adding Conflicts will likely make switching inits much more difficult.
> > >
> > > Nod, reassigning back to insserv.
> >
> > Bug is in incorrect usage of insserv, not within insserv. You may want to
> > add check, that /etc/init.d/mountkernfs.sh exists.
> >
> > If it will help you, I can add 'Recommends' (not Depends) on
> > bin:initscripts into insserv.
> >
> > If if you disagree, please close + wontfix this bug.
>
> On second thought, maybe it is okay to add dependency of insserv on
> initscripts? After all, we already have initscripts installed, and
> systemd users are unlikely to complain about bloat...
>
> Opinions?
>

It might be a bit late but I had encountered the same situation after
dist-upgrading from an older Debian release. So maybe I can somehow shed
some additional light on this issue.
The actual culprit is rcconf which is marked as manually installed and
depends on sysv-rc which in turn depends on insserv and startpar; and so
all these packages remain installed after the migration to systemd. At the
same time sysvinit-core (which depends on initscripts) is removed and so
is initscripts because the package systemd-sysv has corresponding entries
for 'Conflicts:' and 'Replaces:'.
But if you manually remove rcconf, the other three packages can be
automatically removed afterwards as none of them is needed by systemd.

So I think both would make sense, add 'Recommends: initscripts' to insserv
because initscripts is somehow needed for insserv as well as adding
'Conflicts: sysv-rc' to systemd-sysv to help migrating to systemd. Anyway,
systemd-sysv already conflicts with file-rc and openrc, so additionally
conflicting with sysv-rc shouldn't really make things worse.

Best regards,

Thomas Uhle

[Kurt Fitzner]

I just tried to install rcconf on a Debian testing sytem. Since rcconf
requires insserv, it was installed first. During the insserv install I
got:

insserv: FATAL: service mountkernfs has to exist for service udev
insserv: FATAL: service urandom has to exist for service networking

I am curious, what is the current state of this bug? There is talk
about first installing initscripts as a workaround for this. But the
initscripts package also depends on insserv, so I still get the above
errors. The only way I seem to be able to avoid the above fatal error
messages is if I install initscripts (which tries to install insserv),
and then reinstall insserv.

This seems rather circular.

[Thorsten Glaser]

On Tue, 4 May 2021, Kurt Fitzner wrote:

> I just tried to install rcconf on a Debian testing sytem. Since rcconf

How is rcconf even useful on a nōn-sysvinit+sysv-rc system?

Maybe rcconf should depend on that or conflict with all others?

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*************************************************

[Kurt Fitzner]

Installing rcconf also installs sysv-rc, insserv, and startpar.  Installing initscripts also installs sysv-rc, insserv, and startpar .  If neither of those scenarios make sense without sysvinit installed, then yes, it clearly should be dependency somewhere.  If insserv is not relevant on a systemd system, then please put in a conflicts.

 

As far as how it is even useful, honestly, I am not an expert on systemd (who is?).  I had previously understood that rcconf on modern Debian systems interfaced with systemd through some sort of compatibility layer.  The way that "sudo service lighttpd start" and "sudo systemctl start lighttpd" both do the same thing.  This seems not to be the case.  I don't know what all is involved under the hood for rcconf or Debian's init systems, nor should I have to.  I should know what tools are available and expect that they will work.  And if tool A is not compatible with initsystem B, then it's not unreasonable to expect that trying to install A when B is there will run into a conflict somewhere.

 

So yes, if this is a nonsensical combination, please do put in the dependencies and conflicts that will enforce that for whatever packages you maintain.

 

Thank-you.

[Thorsten Glaser]

On Wed, 5 May 2021, Kurt Fitzner wrote:

> So yes, if this is a nonsensical combination, please do put in the
> dependencies and conflicts that will enforce that for whatever packages
> you maintain.

I don’t maintain *any* of these packages. I just learnt that
such a thing as rcconf exists at all and wondered about its
description. Why don’t you ask the rcconf maintainer about this?

bye,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)

[Thomas Deutschmann]

Hi,

I saw that message today while upgrading bookworm RC3 to RC4:

> [...]
> Setting up console-setup-linux (1.221) ...
> insserv: FATAL: service mountkernfs has to be enabled to use service keyboard-setup.sh
> [...]

Note: The system was recently upgraded from Debian 8 (without systemd)
to Debian 9 (where I switched to systemd) to Debian 12.

In my case it looks like insserv was a leftover of

> $ aptitude why insserv
> i chkconfig Recommends insserv

I purged both packages.


--
Regards,
Thomas

[Thorsten Glaser]

On Sun, 28 May 2023, Thomas Deutschmann wrote:

> Note: The system was recently upgraded from Debian 8 (without systemd) to
> Debian 9 (where I switched to systemd) to Debian 12.

You did upgrade to Debian 10, then Debian 11, in the middle, right?

Otherwise your system is now completely unsupportable and you will
have to clean up the resulting mess yourself. Skipping releases in
an upgrade was *never* supported, and it’s documented in basically
every place…

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

[Thomas Deutschmann]

On 2023-06-13 17:45, Thorsten Glaser wrote:
> On Sun, 28 May 2023, Thomas Deutschmann wrote:
>
>> Note: The system was recently upgraded from Debian 8 (without systemd) to
>> Debian 9 (where I switched to systemd) to Debian 12.
>
> You did upgrade to Debian 10, then Debian 11, in the middle, right?

Yes, of course.

And upgrade was done using basically

apt-get upgrade
apt-get full-upgrade

commands.

After each upgrade, configuration files which couldn't be automatically
updated were manually upgraded.

Once we booted into the upgraded OS for the first time, we removed old
packages via

apt-get autoremove

command.

What we forgot was to remove still installed debian8 packages, when
system was fully upgraded to Debian 9. Removing debian9 packages when
system was fully upgraded to Debian 10 and so on.

For example the system pulled in ffmpeg from dmo repo in the past.

We recently noticed on bookworm that every application using gnuTLS
(like git or gdb trying to fetch symbols from
https://debuginfod.debian.net) was unable to establish a TLS connection:


https://0x0.st/Hb6z.log

strace showed that the application was always hanging in getrandom calls:

https://0x0.st/HbEG.log

When we tried to reinstall all deps of libcurl3-gnutls package we run
into a problem because librtmp1 was installed from dmo but no longer
available.

After removing that package we were able to reinstall all deps of
libcurl3-gnutls which resolved the gnuTLS problem in the end.

Now the system is really in a clean state with only debian12 packages
installed.

But from my understanding this is unrelated to the seen
console-setup-linux and insserv issue because both packages were from
debian12 and up-to-date when we got the message.


--
Regards,
Thomas

[Thorsten Glaser]

On Tue, 13 Jun 2023, Thomas Deutschmann wrote:

>> You did upgrade to Debian 10, then Debian 11, in the middle, right?
>
> Yes, of course.

OK.

> apt-get upgrade
> apt-get full-upgrade

I personally tend to use:
apt-get --purge dist-upgrade

This takes care of purging the configuration files of packages
that get removed (take care, of course, to not let it remove
things you still need, like the old PostgreSQL version until
the cluster(s) have migrated).

> apt-get autoremove

Again, add --purge here and take care (though etckeeper helps).

> Now the system is really in a clean state with only debian12 packages
> installed.

Is it? Remember that apt doesn’t know about leftover conffiles.

Try: dpkg -l | grep -v ^ii | cut -c 1-$COLUMNS

This ought to show only the header and perhaps “held” packages
(first column “hi”); if it also shows “rc” in the first column
then you have leftover conffiles, which indeed can cause trouble;
run “dpkg --purge pkgname pkgname…” to clean them up.

[Thomas Deutschmann]

On 2023-06-13 20:10, Thorsten Glaser wrote:
> I personally tend to use:
> apt-get --purge dist-upgrade
>
> This takes care of purging the configuration files of packages
> that get removed (take care, of course, to not let it remove
> things you still need, like the old PostgreSQL version until
> the cluster(s) have migrated).

Thank you, I didn't know about mixing "dist-upgrade" command with "purge"!

>> Now the system is really in a clean state with only debian12 packages
>> installed.
>
> Is it? Remember that apt doesn’t know about leftover conffiles.
>
> Try: dpkg -l | grep -v ^ii | cut -c 1-$COLUMNS

Yes, it is :)

I run similar commands during the cleanup when we noticed the gnutls
problem. All non debian12 packages are now purged. Just to be sure that
there really isn't any leftover or manually added file which could
interfere in some unexpected ways I even feeded all files through dpkg.


--
Regards,
Thomas