Author: Olaf Meeuwissen Date: To: Rainer Weikusat CC: dng Subject: Re: [DNG] Did debian just remove multi-init support from the latest
shipped grub?
Hi,
Rainer Weikusat via Dng <dng@???> writes:
> Steve Litt <slitt@???> writes:
>> Ralph Ronnquist via Dng said on Thu, 19 Jun 2025 10:19:21 +1000
>>
>>>What is supposed to be in /lib/sysvinit/init ? That's not a realised
>>>pathname on my setup, and that is not where the init binary of
>>>sysvinit-core is installed. Perhaps there was some attempt at som
>>>point to have sysvinit's init installed there?
>>>
>>>From memory, the kernel looks for "/init", "/sbin/init" or "/bin/init"
>>>(in order) to tbe the initial process, and the pathname may be a
>>>symbolic link to an actual file which may be a binary or a "#!"
>>>script.
>>
>> I think you're right, and that's great because you can change the init
>> system for your next boot by copying PID1 from sysvinit or runit or s6
>> or Epoch or (gulp) OpenRC to /sbin and making it executable.
>
> JFTR: It's also possible to pass init=/some/program as parameter on the
> kernel command-line to specify which program the kernel should start as
> init. In particular, init=/bin/sh or init=/bin/bash can be used to get a
> usable shell without running anything else.
That is exactly how that patch told the kernel what init to use :-)
It is also exactly why I password protect all but the default grub menu
entry. This needs some patching of the packaged /etc/grub.d/* files as
they only support password protecting *all* menu entries :-(
I also muck around with BIOS setting to prevent booting from anything
but the internal disk(s) as best as the BIOS allows.