[arch-general] Problems with mkinitcpio

Thomas Bächler thomas at archlinux.org
Fri Mar 5 23:56:05 CET 2010


Am 05.03.2010 23:45, schrieb Ihad:
>> Some rules with respect to IDE devices were in fact removed in a
>> previous udev version. In fact, almost nobody still uses the IDE
>> subsystem, most(!) drivers work better with the ATA subsystem these days.
>>
>> However, these "standard" nodes should still be created, there should be
>> no special udev rules required for them. I am a bit unsure how to debug
>> this. Are the device nodes created when root is mounted and Arch is
>> booted? Are they created when you boot with the break=y option and wait
>> for a while?
> 
> I didn't try break=y, but they definitely aren't created by udev, no matter 
> what I do. I have a custom kernel (2.6.30) with the ide drivers compiled in, 
> and even then I don't get the device nodes. I have to create them manually and 
> then mount the needed devices to get a working system.
> 
> The custom kernel has RAID autodetect compiled in, so I get my root fs, and I 
> also have md0 and md1 but nothing more. No hd[a-f][0-2]. On top of the RAID is 
> LVM, so after:
> # lvm
>> vgmknodes
>> quit
> Then I can mount /var to recreate the initrd and reinstall the kernel and 
> regenerate the initrd.

I'm confused, really, I see no reason why the devices shouldn't be
there. Maybe after some sleep.

> What does break=y do, btw? I'm too lazy too look it up myself :)

It interrupts the initramfs before root is mounted and drops you into a
shell. A good way to poke around if you want to.

>> I am wondering if we can somehow monitor the uevents at this early stage
>> of the boot process to see what goes wrong.
> 
> Hmm, I don't really have an idea about that, except looking at the source...

There is udevadm monitor - we could start that very early and redirect
the output into a file inside rootfs. Then, we kill it and look at the
file. Not sure if that will work well, haven't tried it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20100305/49a6a077/attachment.bin>


More information about the arch-general mailing list