Subject: Debian removed essential startup scripts

From: Klaus Ethgen <[email-masked]>
Date: Tue, 13 Jun 2023 10:25:59 +0100

Package: mdadm
Version: 4.2+20230508-2
Severity: critical

With version 4.2+20230227-1, Debian did remove all init scripts
(/etc/init.d/mdadm and /etc/init.d/mdadm-waitidle) for no needs.

This renders all systems that are using md devices unbootable!

-- Package-specific info:

IMPORTANT:
  please do not forget to include all relevant system information with this
  bug report. You could run
    /usr/share/bug/mdadm/script 3>&1
  as root and attach or include the output.

-- System Information:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 5 (daedalus/ceres)
Release:	5
Codename:	daedalus ceres
Architecture: x86_64

Kernel: Linux 6.1.12 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mdadm depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  eudev [udev]           3.2.12-1
ii  libc6                  2.36-9
ii  libeudev1 [libudev1]   3.2.12-1

Versions of packages mdadm recommends:
ii  kmod  30+20230519-1

Versions of packages mdadm suggests:
iu  exim4-daemon-light [mail-transport-agent]  4.96-16

-- Configuration Files:
/etc/logcheck/ignore.d.server/mdadm [Errno 13] Permission denied: '/etc/logcheck/ignore.d.server/mdadm'
/etc/logcheck/violations.d/mdadm [Errno 13] Permission denied: '/etc/logcheck/violations.d/mdadm'

-- debconf information:
  mdadm/initrdstart_msg_errblock:
* mdadm/autocheck: false
  mdadm/initrdstart_msg_errmd:
* mdadm/initrdstart: all
* mdadm/autoscan: true
  mdadm/initrdstart_msg_errexist:
  mdadm/initrdstart_msg_errconf:
  mdadm/autostart: true
  mdadm/initrdstart_msg_intro:
* mdadm/start_daemon: true
* mdadm/mail_to: [email-masked]
  mdadm/initrdstart_notinconf: false
Gruß
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <[email-masked]>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C

---

From: Mark Hindley <[email-masked]>
Date: Tue, 13 Jun 2023 10:36:09 +0100

Control: tags -1 debian

Klaus,

> Severity: critical

src:mdadm is not forked in Devuan and we use Debian's packages directly without
recompilation.

This is clearly a Debian issue, see the Changelog entry for 4.2+20230227-1[1]

Please report to Debian's BTS.

Thanks

Mark

[1]  https://tracker.debian.org/media/packages/m/mdadm/changelog-4.220230508-2

---

From: Klaus Ethgen <[email-masked]>
Date: Tue, 13 Jun 2023 10:41:44 +0100

Hi Mark,

> This is clearly a Debian issue, see the Changelog entry for 4.2+20230227-1[1]

Yes. But it is done by ignorance and reading from this log message, they
do not show enlightenment as in debian, that would not break anything.
(Well, except of that, who uses SysV init. But that users are cursed
anyway in debian.)

So, the package needs to be forked for devuan to prevent harm from
devuan users.

Regards
   Klaus

---

From: Mark Hindley <[email-masked]>
Date: Tue, 13 Jun 2023 10:47:54 +0100

> do not show enlightenment as in debian, that would not break anything.

So, correct this misunderstanding by pointing out the error in a kind an
constructive way.

> (Well, except of that, who uses SysV init. But that users are cursed

But they still exist. So the correct place to fix this for both Debian
non-systemd users and Devuan users is in Debian.

Mark

---

From: Klaus Ethgen <[email-masked]>
Date: Tue, 13 Jun 2023 10:58:31 +0100

Hi Mark,

> So, correct this misunderstanding by pointing out the error in a kind an

I don't think, that it is a "misunderstanding". The Debian packager
knows exactly what he does.

It is clearly not accidentally but clear knowing what they do.

It is that style that makes me frustrated about debian. I had many
discussions that mostly end with them, using their power to keep the
package in broken state. Sadly, my english is not that good to go into a
long therm battle.

Regards
   Klaus

---

From: Mark Hindley <[email-masked]>
Date: Tue, 13 Jun 2023 14:04:52 +0100

Control: forwarded -1 https://bugs.debian.org/1037496

Klaus,

I have forwarded this request on your behalf.

Best wishes

Mark

---

From: Mark Hindley <[email-masked]>
Date: Tue, 20 Jun 2023 12:17:51 +0100

Klaus,

Could you please clarify the boot failure mode caused by the initscript
removal. We are pursuing this in Debian, but lorenzo has just pointed out that

On Tue, Jun 20, 2023 at 12:18:47PM +0200, lorenzo wrote:                                                                                                   
> Can you elaborate on this? I may be wrong, but I don't understand how the
> removal of mdadm script can render the system unbootable: the script runs
> mdadm in monitor mode and starts in runlevel 2. There is no script (removed)
> in runlevel S, I suspect a fail to boot will involve a problem in the kernel
> or in udev rules (that are still there)?

I have had a quick look and agree.

Is there some other change that has caused this? Or has the initramfs
integration broken. Have you edited the runlevels of the original initscripts?

Best wishes

Mark
-- 
Mark Hindley
GPG: 506C 15A4 2B0A F5A0 A854  23EE D28A 45BF 3287 D649

---

From: Klaus Ethgen <[email-masked]>
Date: Tue, 20 Jun 2023 12:39:12 +0100

Hi Marc,

> integration broken. Have you edited the runlevels of the original initscripts?

Hmm. I have to admit that I did not had the courage to boot the system
without that init script as I am depending on working md devices.

But I have a pretty old system with no initrd and separated /usr as it
was supported long ago. So I am usual extra sensitive to such changes.

Regards
   Klaus

---

From: Mark Hindley <[email-masked]>
Date: Tue, 20 Jun 2023 13:52:33 +0100

Klaus,

> without that init script as I am depending on working md devices.

OK, thanks. We have to be really careful about this then. Claiming non-existent
boot breakage as a justification considerably weakens any case we make. If you
want to persist with the assertion, your will need to verify: maybe try a boot
without the initscripts and with a recovery USB stick, or similar, to hand?.

> was supported long ago. So I am usual extra sensitive to such changes.

Yes, now I remember. Although I know you don't like it, booting without an
initrd has not been supported for a long time.  I am finding it hard to locate
the specific release, but I *think* it was Etch first released in 2007 and EOL
in 2010. Of course you are welcome to do it if you can get it to work, but you
are going to be continually disappointed by expecting Devuan or Debian to
support it in any way now. When booting without an initrd no longer works for
you, you may just have to accept that and start using one.

I am sorry if that sounds blunt or uncaring. It isn't meant to be -- just a
statement of fact. I had an old AMD K6 system that was made obsolete by the
change to gcc -march=686 default. I completely understand your pain. However,
Devuan (and Debian) has enough issues to deal with just to keep non-systemd init
viable and working.

With best wishes

Mark