Initramfs and /sbin/hotplug fun

Initramfs and /sbin/hotplug fun

[Andrew Walrond]

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

Re: Initramfs and /sbin/hotplug fun

[Jan Engelhardt]

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'
-- 

Re: Initramfs and /sbin/hotplug fun

[Olaf Hering]

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.

Re: Initramfs and /sbin/hotplug fun

[Andrew Walrond]

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

Re: Initramfs and /sbin/hotplug fun

[Olaf Hering]

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?

Re: Initramfs and /sbin/hotplug fun

[Andrew Walrond]

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

Re: Initramfs and /sbin/hotplug fun

[Mark Rustad]

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, MRustad@mac.com

Re: Initramfs and /sbin/hotplug fun

[Bill Davidsen]

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 <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979