If the initramfs root filesystem contains /sbin/hotplug, the kernel
starts calling it very early in the kernel boot process, well before
/init has been called. In my case this resulted in lots of hotplug
segfault messages as the kernel boots, followed by a thoroughly unhappy
hotplug+udev once /init actually gets control.
To solve this, I deleted /sbin/hotplug from the initramfs archive and
modified /init to reinstate it once it gets control. This works fine,
but seems inelegant. Is there a better solution? Should sbin/hotplug be
called at all before the kernel has passed control to /init?
Andrew Walrond
On Jan 15 2007 14:16, Andrew Walrond wrote:
>
> If the initramfs root filesystem contains /sbin/hotplug, the kernel
> starts calling it very early in the kernel boot process, well before
> /init has been called. In my case this resulted in lots of hotplug
> segfault messages as the kernel boots, followed by a thoroughly
> unhappy hotplug+udev once /init actually gets control.
Could this be a case of http://lkml.org/lkml/2006/12/3/19 ?
-`J'
--
On Mon, Jan 15, Andrew Walrond wrote:
> To solve this, I deleted /sbin/hotplug from the initramfs archive and
> modified /init to reinstate it once it gets control. This works fine,
> but seems inelegant. Is there a better solution? Should sbin/hotplug be
> called at all before the kernel has passed control to /init?
Yes, it should be called.
/sbin/hotplug and /init are two very different and unrelated things.
Olaf Hering wrote:
> On Mon, Jan 15, Andrew Walrond wrote:
>
>> To solve this, I deleted /sbin/hotplug from the initramfs archive and
>> modified /init to reinstate it once it gets control. This works fine,
>> but seems inelegant. Is there a better solution? Should sbin/hotplug be
>> called at all before the kernel has passed control to /init?
>
> Yes, it should be called.
Ok
> /sbin/hotplug and /init are two very different and unrelated things.
Well, of course. But looking at the thread provided by Jan, it seems the
kernel might not be in any fit state to service the (userspace) hotplug
infrastructure when it makes the calls (Ie can't create pipes yet).
The kernel wouldn't call /init (or /sbin/init) before it was fully ready
to handle userspace processes, so why should it feel able to call the
hotplug userspace?
Andrew Walrond
On Mon, Jan 15, Andrew Walrond wrote:
> >/sbin/hotplug and /init are two very different and unrelated things.
>
> Well, of course. But looking at the thread provided by Jan, it seems the
> kernel might not be in any fit state to service the (userspace) hotplug
> infrastructure when it makes the calls (Ie can't create pipes yet).
Thats because noone really fixed the init call order. Its going back and
forth since /init was added in 2.6.6.
Ideally, there could be some /earlyinit that could prepare the
enviroment for hotplug calls.
Why do you need /sbin/hotplug anyway, just for firmware loading for a
non-modular kernel?
Andrew Walrond wrote:
> Olaf Hering wrote:
>> On Mon, Jan 15, Andrew Walrond wrote:
>>
>>> To solve this, I deleted /sbin/hotplug from the initramfs archive and
>>> modified /init to reinstate it once it gets control. This works fine,
>>> but seems inelegant. Is there a better solution? Should sbin/hotplug
>>> be called at all before the kernel has passed control to /init?
>>
>> Yes, it should be called.
>
> Ok
>
>> /sbin/hotplug and /init are two very different and unrelated things.
>
> Well, of course. But looking at the thread provided by Jan, it seems the
> kernel might not be in any fit state to service the (userspace) hotplug
> infrastructure when it makes the calls (Ie can't create pipes yet).
>
> The kernel wouldn't call /init (or /sbin/init) before it was fully ready
> to handle userspace processes, so why should it feel able to call the
> hotplug userspace?
>
I could speculate in case it needs to hotplug something to complete
boot, but it could just be a thinko.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Olaf Hering wrote:
>
> Why do you need /sbin/hotplug anyway, just for firmware loading for a
> non-modular kernel?
I guess this is unusual, but FWIW...
I have a custom distro and I was just looking for the easiest way to
create a bootable rescue pen-drive. So I just took a working distro,
added an init->sbin/init symlink, cpio'ed it into an initramfs, and
booted it up. Works a treat, except for the early hotplug calls.
Andrew
On Jan 15, 2007, at 1:54 PM, Andrew Walrond wrote:
> Olaf Hering wrote:
>> Why do you need /sbin/hotplug anyway, just for firmware loading for a
>> non-modular kernel?
>
> I guess this is unusual, but FWIW...
>
> I have a custom distro and I was just looking for the easiest way
> to create a bootable rescue pen-drive. So I just took a working
> distro, added an init->sbin/init symlink, cpio'ed it into an
> initramfs, and booted it up. Works a treat, except for the early
> hotplug calls.
I have a kernel that needs to have early hotplug calls to load
firmware. I just rolled my own simple hotplug scripts to only address
that issue and have not had a problem since. The mdev in busybox that
is in the gentoo initramfs didn't seem to be able to handle it, so I
just made my own scripts. In my case I needed QLogic firmware so root
could be on FC.
FWIW, it is a real PITA to not be able to build a monolithic kernel
that can bring up root on its own. I will stipulate that I am an old-
school guy that likes monolithic kernels, but I do feel that
something has been lost. Yes, I am aware of the reasons for the
change, else I would have written something when I was fighting the
battle, but I still don't have to like it.
--
Mark Rustad, [email protected]