RE: [gentoo-user] udev/initramfs problem
Hi, When I say that the driver structure (modular build) has changed, I mean to say that in previous encarnations only two modules were loaded (mptbase, mptscsih). Now, the transport portion is also loaded as, in this case, mptspi. Genkernel creates the initramfs. unfortunately, I am not as familiar with that process as I would like to be - working that also. Within the initramfs building process under genkernel, all required modules are specified along with the creation of klibc, busybox and ash with udevd and coldplug - (which also includes hotplug) I have also noticed that the device in question is not seen in the 2006.0 Gentoo livecd which uses kernel 2.6.15-r5. Again, the modules are loadable but the LSI hardware is not seen. And, of course no machine without the LSI chipset has this problem. You bring up and interesting question with respect to hotplug. I'm going to build a kernel the old fassioned way (without genkernel) and see where it gets me. I'm not sure, given the additional failure on the part of the 2006.0 livecd, exactly where the problem is - udev or initramfs. MEJ -Original Message- From: Hans-Werner Hilse [mailto:[EMAIL PROTECTED] Sent: Tue 4/18/2006 4:59 PM To: gentoo-user@lists.gentoo.org Cc: Subject:Re: [gentoo-user] udev/initramfs problem Hi, On Tue, 18 Apr 2006 11:25:52 -0500 Johnson, Maurice E CTR NSWCDL-K74 [EMAIL PROTECTED] wrote: # genkernel -- menuconfig --install all Hm, I don't really know genkernel. Does it create the initramfs? When in the ash shell environment, I notice that there are few static nodes in /dev. ( i.e. console, pty etc.) In this environment, I am able to load the modules manually, but still no device is visible in /dev. Then there's either no daemon that creates the devices (udev) or it isn't somehow configured correctly. I note that the MPT driver structure has changed as well for this kernel - which, I have built both modularly and strait into the kernel. Somehow I doubt that. Usually you have it either the one way or the other. But as you said you could load them, I guess they're modules. You might want to try to recompile a kernel with all drivers compiled in. I have been doing a great deeal of reading and have found that klibc may be an issue, however, building older (2.6.12-r4) kernels works without error. Also noted here is that 2.6.12-r4 still has devfs features available. That would explain it. udev would be needed in the initramfs to create devices upon module loading. The module is contained within the initramfs and loads (manually) So there's no hotplugging or similar. Try to compile the drivers directly into the kernel. - and how is the module to be loaded by the initramfs? My presumption is that the rules within 50-udev.rules provide for this. - is there a static or a dynamic /dev in the initramfs? My best discription here is dynamic with a few static nodes present. Ah, this _is_ in the initramfs? Is there a udevd spawned in initramfs? I beleive that it is at the PCI level where this failure occures, because, if the PCI interface ti the controler were properly handled, then the scsi bus it provides would be available. Is dmesg available in initramfs? It may contain hints upon module loading. But at that time those hints should be print out to console, anyway. You're shure that those are the correct drivers, aren't you? -hwh -- gentoo-user@gentoo.org mailing list winmail.dat
Re: [gentoo-user] udev/initramfs problem
Hi, On Tue, 18 Apr 2006 09:44:09 -0500 Johnson, Maurice E CTR NSWCDL-K74 [EMAIL PROTECTED] wrote: We rescently upgraded to the 2.6.15-r1 kernel and life is great on the systems that use the adaptec scsi controllers. However, LSI Logic does not appear to be seen by udev or, more likely, initramfs facilities. Consequently, no root device is found. Hm? The initramfs is in charge to load proper modules, if needed. But there shouldn't be a root device if there's an initramfs. Are you talking about the staged root which is going to be pivot'ed when the initramfs is done? I am missing something but don't know what. Below is the output of [...] How has the cited output been made? From initramfs system? My questions would be: - is the driver for the LSI controller compiled into the kernel? - if it isn't, is the module contained in the initramfs? Is it a module for the right kernel? - and how is the module to be loaded by the initramfs? - is there a static or a dynamic /dev in the initramfs? - if dynamic, how is it managed? - what are the commands the initramfs uses to stage into real root? -hwh -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] udev/initramfs problem
The current kernel build process is simply: # genkernel -- menuconfig --install all make.profile=2006.0 gcc=3.4.5-r1 When in the ash shell environment, I notice that there are few static nodes in /dev. ( i.e. console, pty etc.) In this environment, I am able to load the modules manually, but still no device is visible in /dev. I note that the MPT driver structure has changed as well for this kernel - which, I have built both modularly and strait into the kernel. I have been doing a great deeal of reading and have found that klibc may be an issue, however, building older (2.6.12-r4) kernels works without error. Also noted here is that 2.6.12-r4 still has devfs features available. So, to answer your questions: - is the driver for the LSI controller compiled into the kernel? I have built the driver both ways - if it isn't, is the module contained in the initramfs? Is it a module for the right kernel? The module is contained within the initramfs and loads (manually) - and how is the module to be loaded by the initramfs? My presumption is that the rules within 50-udev.rules provide for this. - is there a static or a dynamic /dev in the initramfs? My best discription here is dynamic with a few static nodes present. - if dynamic, how is it managed? - what are the commands the initramfs uses to stage into real root? I will look deeper for this one. Ultimately, when the time comes to pivot, the disk that would be /dev/sda is not available and, therefore, /dev/sda2 is likewise unavailable. I beleive that it is at the PCI level where this failure occures, because, if the PCI interface ti the controler were properly handled, then the scsi bus it provides would be available. Thank you for your time. MEJ -Original Message- From: Hans-Werner Hilse [mailto:[EMAIL PROTECTED] Sent: Tue 4/18/2006 11:05 AM To: gentoo-user@lists.gentoo.org Cc: Subject:Re: [gentoo-user] udev/initramfs problem Hi, On Tue, 18 Apr 2006 09:44:09 -0500 Johnson, Maurice E CTR NSWCDL-K74 [EMAIL PROTECTED] wrote: We rescently upgraded to the 2.6.15-r1 kernel and life is great on the systems that use the adaptec scsi controllers. However, LSI Logic does not appear to be seen by udev or, more likely, initramfs facilities. Consequently, no root device is found. Hm? The initramfs is in charge to load proper modules, if needed. But there shouldn't be a root device if there's an initramfs. Are you talking about the staged root which is going to be pivot'ed when the initramfs is done? I am missing something but don't know what. Below is the output of [...] How has the cited output been made? From initramfs system? My questions would be: - is the driver for the LSI controller compiled into the kernel? - if it isn't, is the module contained in the initramfs? Is it a module for the right kernel? - and how is the module to be loaded by the initramfs? - is there a static or a dynamic /dev in the initramfs? - if dynamic, how is it managed? - what are the commands the initramfs uses to stage into real root? -hwh -- gentoo-user@gentoo.org mailing list winmail.dat
Re: [gentoo-user] udev/initramfs problem
Hi, On Tue, 18 Apr 2006 11:25:52 -0500 Johnson, Maurice E CTR NSWCDL-K74 [EMAIL PROTECTED] wrote: # genkernel -- menuconfig --install all Hm, I don't really know genkernel. Does it create the initramfs? When in the ash shell environment, I notice that there are few static nodes in /dev. ( i.e. console, pty etc.) In this environment, I am able to load the modules manually, but still no device is visible in /dev. Then there's either no daemon that creates the devices (udev) or it isn't somehow configured correctly. I note that the MPT driver structure has changed as well for this kernel - which, I have built both modularly and strait into the kernel. Somehow I doubt that. Usually you have it either the one way or the other. But as you said you could load them, I guess they're modules. You might want to try to recompile a kernel with all drivers compiled in. I have been doing a great deeal of reading and have found that klibc may be an issue, however, building older (2.6.12-r4) kernels works without error. Also noted here is that 2.6.12-r4 still has devfs features available. That would explain it. udev would be needed in the initramfs to create devices upon module loading. The module is contained within the initramfs and loads (manually) So there's no hotplugging or similar. Try to compile the drivers directly into the kernel. - and how is the module to be loaded by the initramfs? My presumption is that the rules within 50-udev.rules provide for this. - is there a static or a dynamic /dev in the initramfs? My best discription here is dynamic with a few static nodes present. Ah, this _is_ in the initramfs? Is there a udevd spawned in initramfs? I beleive that it is at the PCI level where this failure occures, because, if the PCI interface ti the controler were properly handled, then the scsi bus it provides would be available. Is dmesg available in initramfs? It may contain hints upon module loading. But at that time those hints should be print out to console, anyway. You're shure that those are the correct drivers, aren't you? -hwh -- gentoo-user@gentoo.org mailing list