Debian removed multi-init support from the latest shipped grub

Prowler_Gr · 2025-06-19 00:27:49

It looks like Debian has taken a step further to discourage the usage of alternative inits in their Trixie grub package.

This feature was implemented in the sysvinit days (when they were exploring systemD & upstart), and was removed recently although it is perfectly working code, with no bugs against it.

Refer to my signature to see how I've been using this on my spins

I have posted to the maintainers in their official Gitlab repo for those who wish to follow (bottom section of following link):

https://salsa.debian.org/grub-team/grub … 7bf55ba59d

yurimodin · 2025-06-19 18:44:32

makes me want to run a non-systemD distro just out of pure protest.

golinux · 2025-06-19 18:55:50

@yurimodin . . . You are a little late to the party but at least you finally figured it out! systemd is a ball and chain of servitude and blind obedience . . .

Devarch · 2025-06-19 20:45:00

Debian removed multi-init support from the latest shipped grub

This explains why I was unsuccessful in converting Trixie to Excalibur by eliminating systemd (the process was challenging as well).

delgado · 2025-06-19 21:29:57

@Prowler_Gr Thanks for the head up.

First reading this made me clone my debian-trixie-VM-with-sysvinit-enabled before trying apt-get udate; apt-get upgrade.
grub still boots /sbin/init as PID 1, so no harm done.

I'm not exactly sure what the removed part of code does - assumtion is the code enables a way to have sysvinit, systemd and upstart installed in parallel and select init via grub.

Last edited by delgado (2025-06-19 21:30:27)

Prowler_Gr · 2025-06-19 23:13:55

assumtion is the code enables a way to have sysvinit, systemd and upstart installed in parallel and select init via grub.

Any other init really (not just upstart or systemd).
To be clear, people would still be able to boot with the init of their choice, they will just lose the ability to install alternative inits alongside their system's main init

Some history:

Back in the day when Debian only had full support sysvinit & they were looking to explore alternatives Michael Biebl wrote this patch for grub to be able to boot debian with newer inits such as systemd & upstart without loosing the ability to fallback to good old sysvinit.
Now Michael Biebl (who btw is the maintainer of systemD in Debian) requested and achieved to have this part of his code removed in the upcoming Trixie release of grub.
Technically this not a big deal, as the removed code can easily be (with minor adjustments) repackaged & added to grub by any derivative that wishes to do so.
Politically though IMO it is quite a big deal as it directly violates the outcome of the 2019 GR which states

Proposal B
Choice 2: B: Systemd but we support exploring alternatives
Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus.
The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.
Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.

So in a summary:
- Debian deliberately removed (perfectly working) code from GRUB that enables exploring alternatives & using multiple init systems, code that derivatives (such as MX & antiX) have been relying on to provide more than a single init on their systems.

Screenshots below show how you can have multiple inits in a single installation (refer to my signature & my other posts if you want to test them out)

devuan-init-diversity

golinux · 2025-06-19 23:37:40

Anecdote: Over a decade ago and before systemd made its formal entrance on Debian, I went several rounds with Michael Biebl (and others) on the debian-user mail list and nearly got banned. Shortly thereafter, I surrendered to the immovable reality and never posted there again . . .

dzz · 2025-06-20 01:28:50

Thanks Prowler_Gr for exposing a clearly political move, during Trixie "hard freeze" mode (and yes it's in today's Excalibur updates).

Who do these people work for? The changelog doesn't tell us much unless you dig deeper:

grub2 (2.12-8) unstable; urgency=medium
[ Mate Kukri ]
* d/default/grub: Always get distributor string from `/etc/os-release`
* Avoid adding extra GNU/Linux suffix to menu entries (Closes: #1076723)
-- Felix Zielcke <fzielcke@z-51.de> Wed, 11 Jun 2025 17:42:34 +0200

Thanks also Prowler_Gr for your great work with AntiX and MX, much respect to both and many fond memories from the days of sidux where anticapitalista was a superb contributor. Although I never (yet) got to understand that unique live-boot process..

steve_v · 2025-06-20 03:22:46

Oh, the huge manatee
This was a minor addition to the grub-mkconfig scripts to autodetect installed init systems and make alternate entries with 'init=foo' on the kernel command line. Nothing more.
It was not some involved patch to GRUB itself (which doesn't care about init at all, starting PID1 is the kernels job), it's not required for GRUB to work with sysvinit (or anything else for that matter), and it's trivial to reintroduce. It was simply a convenience feature that the original author no longer wants to maintain.

The ongoing trend of raging against the machine and devolving into politics continues, rather than learning how things actually work and *shock* configuring your stuff directly or *horror* doing some entry-level shell scripting.

greenjeans · 2025-06-20 11:55:07

The ongoing trend of raging against the machine and devolving into politics continues, rather than learning how things actually work and *shock* configuring your stuff directly or *horror* doing some entry-level shell scripting.

Amen.

I do love solving problems with small shell-scripts, they may be small but they are powerful as hell.

trinidad · 2025-06-20 12:13:37

The ongoing trend of raging against the machine and devolving into politics continues, rather than learning how things actually work and *shock* configuring your stuff directly or *horror* doing some entry-level shell scripting.

I do love solving problems with small shell-scripts, they may be small but they are powerful as hell.

thumbs++++++++
TC

The officially official Devuan Forum!

#1 2025-06-19 00:27:49

Debian removed multi-init support from the latest shipped grub

#2 2025-06-19 18:44:32

Re: Debian removed multi-init support from the latest shipped grub

#3 2025-06-19 18:55:50

Re: Debian removed multi-init support from the latest shipped grub

#4 2025-06-19 20:45:00

Re: Debian removed multi-init support from the latest shipped grub

#5 2025-06-19 21:29:57

Re: Debian removed multi-init support from the latest shipped grub

#6 2025-06-19 23:13:55

Re: Debian removed multi-init support from the latest shipped grub

#7 2025-06-19 23:37:40

Re: Debian removed multi-init support from the latest shipped grub

#8 2025-06-20 01:28:50

Re: Debian removed multi-init support from the latest shipped grub

#9 2025-06-20 03:22:46

Re: Debian removed multi-init support from the latest shipped grub

#10 2025-06-20 11:55:07

Re: Debian removed multi-init support from the latest shipped grub

#11 2025-06-20 12:13:37

Re: Debian removed multi-init support from the latest shipped grub

Board footer