Kernel Panic, round 2

[krys]

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

[krys]

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.

[krys]

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?

[hari]

are you trying to load a 32bit kernel module on a 64bit MD?

[krys]

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

[colinjones]

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....

[krys]

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...

[colinjones]

Yes, if you make the changes after the rebuild then you should be good.

[krys]

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?

[colinjones]

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

[hari]

as I told you on irc you can de-gzip the initrd and mount it with -o loop.

br, Hari

[krys]

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,