Starting init...

Alexander E. Patrakov patrakov at ums.usu.ru
Sat Mar 4 03:33:55 PST 2006


Jeremy Huntwork wrote:
> Alexander E. Patrakov wrote:
>> If all three points are true, this proves with 100% fidelity that the 
>> bug is not in the init, and is caused by early /sbin/hotplug processes.
>>
>> Unionfs bug, in other words. Let's act accordingly and admit that my 
>> idea with unionfs was wrong. Possible solutions:
> 
> Certainly this could be the problem. But how do we know absolutely that 
> the problem is indeed unionfs? I haven't seen that explained. Before we 
> make another decision concerning this, I'd like to see information that 
> shows without a shadow of doubt this is a unionfs bug.

Let's do a direct experiment: replace unionfs with a bind mount. This 
will, obviously, produce a non-functional (read-only) CD, where even 
udev bootscript will fail, but if unionfs was indeed the problem, init 
will at least print its version.

Justin: could you please take the 6.1.1-3 CD and rebuild only the init, 
with the attached patch? The kernel and the .root.sqfs file should stay 
the same as on the original CD.

If this prints the init version on a computer where the original 6.1.1-3 
CD locks up, this would show without any doubt that the lockup is in 
unionfs.

BTW, since we have reports about the lockup on 6.2-pre3, and because (as 
already explained in 
http://linuxfromscratch.org/pipermail/livecd/2006-February/003067.html) 
the changes were not well-reasoned, I think that r1387 should be reverted.

-- 
Alexander E. Patrakov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.diff
Type: text/x-patch
Size: 498 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/livecd/attachments/20060304/04cebd07/attachment.bin>


More information about the livecd mailing list