mountdebugfs init script missing

The Wanderer wanderer at fastmail.fm
Wed Mar 26 14:11:43 GMT 2025


I'm not sure whether this should have a bug report, because there
already *is* one, it's just proposing another solution (but has been
sitting without visible response since August of 2020).

In reading a reply today in the "Help wanted to finalise wtmp init
integration" thread, I tried to test a detection command given, and
unexpectedly got a total-failure error message:

$ /sbin/insserv -s
insserv: FATAL: service mountdebugfs has to exist for service rasdaemon
insserv: exiting now!

and, as indicated, /etc/init.d/rasdaemon exists and has mountdebugfs in
its Required-Start header.

This error was reported in August of 2020, in bug #968357, which has
seen no visible response. That bug report provides a suggested change
for rasdaemon to try to detect what is needed without relying on the
mountdebugfs init script; it also points to the bug report and package
version which led that init script to be dropped from the package which
previously provided it, which is apparently the blktrace package.

With this error in place, I apparently cannot get useful output from
'insserv -s' on my (non-systemd) system, as long as the rasdaemon init
script is installed. (I even tried removing the rasdaemon package, and
the init script was left behind. I'm not sure what's up with that yet,
I'm investigating separately.)


I could reassign bug #968357 to orphan-sysvinit-scripts with a request
that the missing init script be brought back there, but that would take
away the visible sign on the rasdaemon package that there is/was any
issue here. (I've also seen a pattern of undesirable results, in terms
of what E-mails actually get sent to me, when the BTS is trying to send
mail both to me and to this mailing list; I don't want to risk getting
into that situation, so I refrain from replying to bug reports that are
being redistributed through the mailing list, and I don't know whether
reassigning the bug report that way might get things into a state where
something similar will happen.)

I could file a separate bug against orphan-sysvinit-scripts asking for
the missing init script to be restored, but that would mean that if the
existing bug ever *is* fixed in rasdaemon, we'd be carrying a script in
orphan-sysvinit-scripts which we don't need anymore (and whoever fixed
it probably wouldn't notice to tell us that we can drop it).

Both of the above are affected by the fact that it's not clear (see
below) that there are enough users for picking up the script to be worth
the effort.

It would probably be preferable to instead get the issue fixed in
rasdaemon, though I don't know whether the fix proposed in that bug
report would be suitable (it seems to just invoke rasdaemon, ignore its
output, and check the exit code to decide whether to proceed or 'exit
0'). The lack of response to the existing bug report would seem to
suggest that the package may not have active maintainership.

Past history suggests that trying to get the init script restored to the
package which dropped it would be useless, especially at this relatively
late remove (it seems to have been dropped in 2018).

Just removing (or otherwise giving up on) the rasdaemon package should
also eliminate the error, but that seems suboptimal. Then again, I'm not
sure it even *works* in its current state, and since that state seems to
have existed since 2018 there might well not be many users for the
package.

Any opinions or preferences as to what would be best here?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20250326/a9baf07d/attachment.sig>


More information about the Debian-init-diversity mailing list