LinuxMCE Forums

General => Installation issues => Topic started by: krys on January 26, 2009, 05:55:19 pm

Title: Kernel Panic, round 2
Post by: krys on January 26, 2009, 05:55:19 pm
okay so I am back on this topic again, here is the recap.
I have a dell pc that uses this NIC : Intel(R) 82562V-2 10/100
I ran this PC as my core for a few weeks, and now I want to use it as an MD, problem is when I try to Pxe boot all i get is:
ipconfig: no devices to configure
/init: .: Can't open /tmp/net-eth0.conf
Kernel panic - not syncing: Attempting to kill init!

Now, I went back and looked at the LMCE install (its still on this pc's hard drive) and it looks like it was using the e1000 module, so I followed the wiki and added this module to the list, recreated the init ramdisk, still nothing. I googled this NIC and found some info saying that there was a new source available and that I should rebuild the module from this source and it would work. So i download the source, build the module, add to list recreated init ramdisk, reboot, SAME ERROR. I tried the e1000e module, SAME ERROR..... I want to run this thing over with my truck at this point.

Does anyone have a clue as to what I need to do to get this thing to boot? Or any suggestions as to what I could do to make sure of what my problem really is? I would think that if this NIC worked for the core that surely it is compatible and I can get it to Pxe boot. There are plenty of threads on the net about people getting this exact NIC to pxe boot (none with LMCE, but a few with other versions of Linux)

Help!
-Krys
Title: Re: Kernel Panic, round 2
Post by: hari on January 26, 2009, 06:46:29 pm
make sure that the exact module you used on the core ends up being included in the initrd for the MD.

br, Hari
Title: Re: Kernel Panic, round 2
Post by: krys on January 26, 2009, 09:54:02 pm
I booted LMCE on the unit in question and ran dmesg|grep eth and it said e1000, which is what I tried to use. when this didnt work I downloaded a few new sources and built new modules tried them and had no luck either.... I think I am going to scrap this board and get an MSI. I am done wasting my time just to get the same result!!!!!!!!!!
Title: Re: Kernel Panic, round 2
Post by: krys on January 26, 2009, 10:22:38 pm
crap, it doesnt look like anyone carries that MSI Live MB anymore, so now I dont know what I want to do, I cant believe that I cant get this damn thing to boot.
Title: Re: Kernel Panic, round 2
Post by: colinjones on January 26, 2009, 10:45:30 pm
You are making sure you don't get mixed up where you are putting the drivers and executing the commands aren't you?

Because the unit won't boot, typically you have to download/compile the driver to your core first (even modprobe it to make sure it loads and everything).

Then copying it to the /usr/pluto/diskless/# tree into the correct location, and using chroot to execute commands as if they were on the MD. Also, depmod is important before recreating the initramfs.

Finally, be conscious that there are 2 locations that the drivers need to be integrated into an initramfs type image. The default image and the actual boot image (both are detailed in the wiki articles that you are probably following already)

The default image is the initramfs image that is loaded the very first time a new MD boots and the core knows nothing about it. This image/boot is the one that coordinates detecting and setting up a new MD and creating the unique diskless image for it to boot from. On the next boot, it will boot from the actual boot image in this newly created diskless image.

So the question is, is it still on the first boot and failing before it finalises the setup for the second boot. Or is it on the second boot? This will tell you which initramfs to update/focus on. Obviously, you can only update the second boot initramfs image once the first boot is successfully completely because prior to that the diskless image that contains the second initramfs doesn't even exist!
Title: Re: Kernel Panic, round 2
Post by: krys on January 26, 2009, 11:10:26 pm
Collin,
all of that makes sense and seems to be what I have been doing for most of the day. I still have had no success, I am still on the first boot, I have not made it to the point where it announces itself to the router.

I also tried to created the image manually from the webadmin like the bottom part of the wiki for the r8169 and go that route, but had no luck either
Title: Re: Kernel Panic, round 2
Post by: colinjones on January 26, 2009, 11:24:27 pm
If you have edited the config files, depmod'd and recreated the initramfs after copying the driver in, and the initramfs in default is definitely updated (check the time/date stamp) then it sounds like the driver isn't working for that NIC.

Perhaps do a modinfo e1000 on the machine when booted as a core and note the details, like:

linuxmce@dcerouter:/lib/modules/2.6.22-14-generic$ modinfo r8168
filename:       /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko
version:        8.008.00-NAPI
license:        GPL
description:    RealTek RTL-8168 Gigabit Ethernet driver
author:         Realtek and the Linux r8168 crew <netdev@vger.kernel.org>
srcversion:     2E2189C8B2FEE22CF89C4B1
alias:          pci:v000010ECd00008168sv*sd*bc*sc*i*
depends:
vermagic:       2.6.22-14-generic SMP mod_unload 586
parm:           speed:force phy operation. Deprecated by ethtool (8). (array of int)
parm:           duplex:force phy operation. Deprecated by ethtool (8). (array of int)
parm:           autoneg:force phy operation. Deprecated by ethtool (8). (array of int)
parm:           rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm:           use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm:           debug:Debug verbosity level (0=none, ..., 16=all) (int)
Title: Re: Kernel Panic, round 2
Post by: krys on January 27, 2009, 08:44:13 pm
ok, here is the info you requested

Filename: /lib/modules/2.6.22-14-generic/kernel/drivers/net/e1000/e1000.ko
version: 7.3.20-k2-NAPI
license: GPL
description: Intel (R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>
srcversion: 6DB39DFE385628913292FF9
alias pci:v00008086d000010C5sv*sd*bc*sc*i*
(lots of alias here, didnt want to waste space unless you need to see them)
depends:
vermagic: 2.6.22-14-generic SMP mod_unload 586
(lots of parms, do you need to see those?)


As you stated lets just focus on one thing at a time, lets just try to get me to the first boot
Title: Re: Kernel Panic, round 2
Post by: colinjones on January 27, 2009, 09:44:59 pm
Now, on the new core, where you have compiled the new driver - modprobe it into the kernel, then modinfo it as well and compare the versions etc with above... esp the bits I highlighted in bold
Title: Re: Kernel Panic, round 2
Post by: krys on January 27, 2009, 09:51:12 pm
Now, on the new core, where you have compiled the new driver - modprobe it into the kernel, then modinfo it as well and compare the versions etc with above... esp the bits I highlighted in bold

I am not 100% sure how to do this.

** nevermind I think i did it,
modprobe e1000
modinfo e1000
Title: Re: Kernel Panic, round 2
Post by: krys on January 27, 2009, 09:58:42 pm
ok its different, but that is because i used the latest source as recommended by a few posts on google (after I tried the e1000 that came with LMCE and had no success)

version: 8.0.9-NAPI
srcversion: 0227095D6783D86D736D413
alias: pco:v00008086d00001085sv*sd*bc*sc*i*



on a side note 8.0.9 was the latest release from dell for this NIC that was supposed to incorporate e1000 and e1000e
Title: Re: Kernel Panic, round 2
Post by: colinjones on January 27, 2009, 10:05:18 pm
But the principle we are working on, is it not, is that the original driver worked perfectly with this machine when it was running as a core? If so, then get that driver and integrate it instead - then you will know if it is a driver issue or just the process you are using..
Title: Re: Kernel Panic, round 2
Post by: krys on January 27, 2009, 10:52:46 pm
how do I know for sure that this is the module it is trying to use when it boots as an MD? I know I added it to the list and recreated the initrd, but is there a way I can check to make sure i did that correctly? I will have to try and find that original module somewhere, I think I overwrote it with the new one. will post results
Title: Re: Kernel Panic, round 2
Post by: krys on January 27, 2009, 11:08:37 pm
ok, I loaded the e1000.ko module that came with LMCE, did the modprobe, modinfo, and it matched up with what was in use when this pc is used as a core. I made sure that e1000 was on the list and used Diskless_BuildDefaultImage.sh to recreate the initrd. Then I rebooted and I get the same Kernel Panic as before.

Am i missing something?
Title: Re: Kernel Panic, round 2
Post by: krys on January 27, 2009, 11:18:44 pm
holy shit, I loaded the e1000e driver and I just got to the point where it announced to the router....
gonna reload and see if it will build

** Great, now i get past the router announcement but I keep getting "Diskless Setup Failed"
**wait, I am idiot i forgot about step 2 cuz it has taken me so long to get here... brb
Title: Re: Kernel Panic, round 2
Post by: krys on January 28, 2009, 12:04:54 am
well i tried the second step and now I am back to getting kernel panics and I am too worn out from today to mess with it, will try again tomorrow.

I do however get a new line before the kernel panic

ipconfig: eth0: SIOCGIFINDEX: No such device
Title: Re: Kernel Panic, round 2
Post by: krys on January 28, 2009, 08:01:33 pm
ok here is the update, there are a few details that I left out yesterday since I was in a hurry.
When I changed the module to e1000e, I finally got to the point where the MD announced itself to the router and then failed the Diskless Setup. The new MD was listed under the webadmin site, but it was listed as AMD64. At this point I was going to finish off the 2nd part of the wiki where you add the module under /usr/pluto/diskless/MD ID... unfortunately this MD was not listed in that directory. Not knowing what else to do I changed the arch to i386 and rebuilt the image using the webadmin, after that the folder for this MD appeared and I tried the 2nd half of the wiki. I rebooted and it didnt announce itself to the router, i just got the good old kernel panic again.

so, why is this MD not creating a folder when it is listed on the web admin? I have a feeling that when I changed to i386 and clicked rebuild that it wiped out the e1000e module and took me back to square 1.
Title: Re: Kernel Panic, round 2
Post by: krys on January 28, 2009, 08:25:24 pm
i just went through the whole process again to verify that I didnt make anymistakes. Everthing went just as it did the first time and i still get the kernel panic. So why would the module work on the default image, but not during the Diskless build? Is it because I am having to switch to i386 and rebuild?
Title: Re: Kernel Panic, round 2
Post by: hari on January 28, 2009, 08:27:31 pm
are you trying to load a 32bit kernel module on a 64bit MD?
Title: Re: Kernel Panic, round 2
Post by: krys on January 28, 2009, 08:49:21 pm
no, I am pretty sure that this is 32 bit
** just checked with dell and confirmed that it is 32bit, dont know why it defaults to amd64 in the webadmin
Title: Re: Kernel Panic, round 2
Post by: colinjones on January 28, 2009, 10:09:54 pm
The only thing I can add here is the 64bit thing can make it tricky. First, as 64 bit you will not be able to complete the instructions after chroot because it will be attempting to use 32bit things like depmod on a 64bit image and will fail. So you do need to rebuild the image as i386. But when you do this, any changes you made like copying drivers, mod'ing configs, recreating initramfs will be lost. Only for the "second boot" the initial boot from "default" in the /boot folder is uneffected, so the question is, did that bit work? If so then the driver and basic principles are correct....
Title: Re: Kernel Panic, round 2
Post by: krys on January 28, 2009, 10:22:03 pm
The only thing I can add here is the 64bit thing can make it tricky. First, as 64 bit you will not be able to complete the instructions after chroot because it will be attempting to use 32bit things like depmod on a 64bit image and will fail. So you do need to rebuild the image as i386. But when you do this, any changes you made like copying drivers, mod'ing configs, recreating initramfs will be lost. Only for the "second boot" the initial boot from "default" in the /boot folder is uneffected, so the question is, did that bit work? If so then the driver and basic principles are correct....

I am not sure if I am completely following you here, but after I switch to i386 the folder for the MD shows up. I then go into that folder and make all the changes and created the initrd. So the rebuild wipes it out, but when I go back afterwards and edit and create the initrd everything should be correct I would think...
Title: Re: Kernel Panic, round 2
Post by: colinjones on January 28, 2009, 10:40:28 pm
Yes, if you make the changes after the rebuild then you should be good.
Title: Re: Kernel Panic, round 2
Post by: krys on January 28, 2009, 10:58:24 pm
Man this is frustrating. After I follow the 2nd part of the wiki to the "T", I can go in and look at the initrd.img and see the modified stamp shows that it was just modified... so it must have been recreated by my command, is there anything I can do to check the initrd to see where the problem might lie?
Title: Re: Kernel Panic, round 2
Post by: colinjones on January 28, 2009, 11:14:03 pm
Can't help you with that - all I can say is that it took me ages to get mine working.. trial and error and I don't know exactly what was wrong in the end... I just kept going back to the beginning and trying again with slight variations... problem is it is very easy to get mixed up in that process and often one step done slightly wrong will mean you need to go back to the beginning! persevere
Title: Re: Kernel Panic, round 2
Post by: hari on January 28, 2009, 11:22:08 pm
as I told you on irc you can de-gzip the initrd and mount it with -o loop.

br, Hari
Title: Re: Kernel Panic, round 2
Post by: krys on January 28, 2009, 11:35:52 pm
Hari:
Is there a chance that you could explain that process to me again, I tried that day on IRC but I could not get the file to de-gzip.
the initrd.img file I was trying was in /usr/pluto/diskless/76/boot folder, what is the command to de-gzip,