[arch-general] Problems with mkinitcpio
Hi, Maybe this is more suitable for arch-dev, but I hope that the devs also read here. Let me know if I should redirect this to arch-dev-public. I have some ancient hardware, specifically an AMD Athlon(tm) XP 2600+ with a PCI IDE Controller: $ lspci | grep Mass 00:0a.0 Mass storage controller: HighPoint Technologies, Inc. HPT366/368/370/370A/372/372N (rev 04) Also, I have IDE devices from hda to hdg, some of them connected to the aforementioned PCI IDE controller. There are 2 raid devices configured: # cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md1 : active raid5 hdb1[0] hdf1[2] hde1[1] 234436352 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU] [================>....] resync = 82.2% (96372676/117218176) finish=19.5min speed=17746K/sec md0 : active raid5 hda2[0] hdg2[2] hdd2[1] 156199808 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU] unused devices: <none> The rebuilding device has devices connected to the PCI controller. All other devices are handled by sis5513, btw. also from /lib/modules/*/ide The autodetect hook from mkinitcpio thinks that pata_hpt366 is the module of choice. But it doesn't work. It crashes the kernel after some time, unfortunately not reproducible and without a log message. The box just stops responding to anything, including a ping. So I guess this something like a kernel panic. The IDE driver (hpt366) works like a charm, but it doesn't seem to generate udev events, so the device nodes don't get created in the initrd, and I'm stuck with a busybox prompt. So I created my own hook in /lib/initcpio/hooks: # cat ide run_hook () { msg -n ":: Creating IDE device nodes" /bin/mknod "/dev/hda" b 3 0 /bin/mknod "/dev/hda1" b 3 1 /bin/mknod "/dev/hda2" b 3 2 /bin/mknod "/dev/hdb" b 3 64 /bin/mknod "/dev/hdb1" b 3 65 /bin/mknod "/dev/hdb2" b 3 66 /bin/mknod "/dev/hdc" b 22 0 [snip] /bin/mknod "/dev/hdg2" b 34 2 msg "done." } and included it into my hooks. Works like a charm. Now my question: is this expected behavior or is it a bug? If it's a bug, where should I file it? LKML or against arch/mkinitcpio? LKML is a problem, since I don't have any a trace. BTW, pata_hpt366 is marked as experimental in 2.6.30. at least. -- Regards. Ihad.
On 03/05/2010 07:12 PM, Ihad wrote:
The autodetect hook from mkinitcpio thinks that pata_hpt366 is the module of choice. But it doesn't work. It crashes the kernel after some time, unfortunately not reproducible and without a log message. The box just stops responding to anything, including a ping. So I guess this something like a kernel panic.
Note that using old ide subsystem is deprecated, and will be removed in future releases of Linux. (Some Linux distributions removed it, for example Slackware) Please report to bugzilla.kernel.org about your issue with pata_hpt366, so can be fixed, or maybe can get some tips. For the rest maybe is more aproppiate that open a bug issue in Arch Linux Bug Tracker. ;) Good Luck! -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Am 05.03.2010 23:12, schrieb Ihad:
Hi,
Maybe this is more suitable for arch-dev, but I hope that the devs also read here. Let me know if I should redirect this to arch-dev-public.
arch-dev-public is read-only for non-developers.
The rebuilding device has devices connected to the PCI controller. All other devices are handled by sis5513, btw. also from /lib/modules/*/ide
The autodetect hook from mkinitcpio thinks that pata_hpt366 is the module of choice. But it doesn't work. It crashes the kernel after some time, unfortunately not reproducible and without a log message. The box just stops responding to anything, including a ping. So I guess this something like a kernel panic.
The IDE driver (hpt366) works like a charm, but it doesn't seem to generate udev events, so the device nodes don't get created in the initrd, and I'm stuck with a busybox prompt. So I created my own hook in /lib/initcpio/hooks: # cat ide run_hook () { msg -n ":: Creating IDE device nodes" /bin/mknod "/dev/hda" b 3 0 /bin/mknod "/dev/hda1" b 3 1 /bin/mknod "/dev/hda2" b 3 2 /bin/mknod "/dev/hdb" b 3 64 /bin/mknod "/dev/hdb1" b 3 65 /bin/mknod "/dev/hdb2" b 3 66 /bin/mknod "/dev/hdc" b 22 0 [snip] /bin/mknod "/dev/hdg2" b 34 2 msg "done." } and included it into my hooks. Works like a charm.
Now my question: is this expected behavior or is it a bug? If it's a bug, where should I file it? LKML or against arch/mkinitcpio? LKML is a problem, since I don't have any a trace. BTW, pata_hpt366 is marked as experimental in 2.6.30. at least.
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 am wondering if we can somehow monitor the uevents at this early stage of the boot process to see what goes wrong.
Hi, On Friday 05 March 2010 23:31:25 Thomas Bächler wrote:
Am 05.03.2010 23:12, schrieb Ihad:
Maybe this is more suitable for arch-dev, but I hope that the devs also read here. Let me know if I should redirect this to arch-dev-public.
arch-dev-public is read-only for non-developers.
Ok, noted :) [snip]
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.
What does break=y do, btw? I'm too lazy too look it up myself :)
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... -- Regards, Ihad.
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.
Hi, On Friday 05 March 2010 23:56:05 Thomas Bächler wrote:
Am 05.03.2010 23:45, schrieb Ihad:
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.
The nodes definitely aren't there. I had the same problem after an udev update and a custom kernel, but that was another box with sata. It turned out to be PEBKAC, or at least close to it. In the end it was a non working mdassemble in /bin, which shouldn't be there. That's not the problem. though, I checked that for sure :) <german> Gute Nacht. </german>
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.
Ok, no need for that. If I boot a non-working kernel, it drops me of in a busybox, and I checked, the devices aren't there.
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.
How early? Maybe keeping the ramdisk mounted helps. This way udevadm monitor could write its results do /somewhere. I did that with images having a defined size, creating a container with an ext2 fs and then mount it rw. If it's big enough we can see the results after booting. But I don't know if it works with cpio-archives... -- Regards, Ihad.
Am 06.03.2010 00:15, schrieb Ihad:
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.
How early? Maybe keeping the ramdisk mounted helps. This way udevadm monitor could write its results do /somewhere. I did that with images having a defined size, creating a container with an ext2 fs and then mount it rw. If it's big enough we can see the results after booting. But I don't know if it works with cpio-archives...
There is no ramdisk. There is just "rootfs". See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Do...
Hi, On Saturday 06 March 2010 00:21:24 Thomas Bächler wrote:
Am 06.03.2010 00:15, schrieb Ihad:
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.
How early? Maybe keeping the ramdisk mounted helps. This way udevadm monitor could write its results do /somewhere. I did that with images having a defined size, creating a container with an ext2 fs and then mount it rw. If it's big enough we can see the results after booting. But I don't know if it works with cpio-archives...
There is no ramdisk. There is just "rootfs". See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=D ocumentation/filesystems/ramfs-rootfs-initramfs.txt;h=a8273d5fad209b4ab4393 c0667c03b549c83091c;hb=HEAD
Ok, didn't know that. works with ext[23]-images though. They're rw and stay mounted after boot, if you do a pivot_root in initrd. But it's not that important. Get some sleep :) -- Regards, Ihad.
Am 06.03.2010 00:27, schrieb Ihad:
How early? Maybe keeping the ramdisk mounted helps. This way udevadm monitor could write its results do /somewhere. I did that with images having a defined size, creating a container with an ext2 fs and then mount it rw. If it's big enough we can see the results after booting. But I don't know if it works with cpio-archives...
There is no ramdisk. There is just "rootfs". See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=D ocumentation/filesystems/ramfs-rootfs-initramfs.txt;h=a8273d5fad209b4ab4393 c0667c03b549c83091c;hb=HEAD
Ok, didn't know that. works with ext[23]-images though. They're rw and stay mounted after boot, if you do a pivot_root in initrd.
You can always write a hook that creates a ramdisk, create a filesystem on it, mount it and mount --move it into the real root before switch_root.
But it's not that important. Get some sleep :)
Not yet.
Hi, On Saturday 06 March 2010 00:35:06 Thomas Bächler wrote:
Ok, didn't know that. works with ext[23]-images though. They're rw and stay mounted after boot, if you do a pivot_root in initrd.
You can always write a hook that creates a ramdisk, create a filesystem on it, mount it and mount --move it into the real root before switch_root.
But it's not that important. Get some sleep :)
Not yet.
Ok, but let me get back to you tomorrow. I'll create a hook that records udev events Where should I include it? I guess before my ide hook. -- Regards, Ihad.
participants (3)
-
Gerardo Exequiel Pozzi
-
Ihad
-
Thomas Bächler