Difference between revisions of "Unrecognized NIC"

From LinuxMCE
Jump to: navigation, search
m (Modify the media director initial ramdisk)
 
(9 intermediate revisions by 7 users not shown)
Line 1: Line 1:
[[Category: Hardware]]
+
{{versioninfo}}
[[Category: Networking]]
+
[[Category: Networking|NIC]]
 +
[[Category:Network Adapters|*]]
 
[[Category: Troubleshooting]]
 
[[Category: Troubleshooting]]
[[Category: Tutorials]]
+
 
  
 
'''Note''' If you have a r8168 NIC, see the [[r8168]] page first.
 
'''Note''' If you have a r8168 NIC, see the [[r8168]] page first.
Line 14: Line 15:
 
Or for the Marvell Yukon 88E8055 chip for example add;
 
Or for the Marvell Yukon 88E8055 chip for example add;
 
  sky2
 
  sky2
 +
Or for a foxconn nt330i / Aleutia H1 you'll need to download the linux drivers from Atheros http://partner.atheros.com/Drivers.aspx (or follow instructions and download drivers from http://joefleming.net/2010/05/26/atheros-ar8131-and-linux/ if that link is dead) and install them, then place the module in the modules file
 +
atl1e
 +
 
After adding the above line (and saving the change of course ;-) ), you have to recreate the initial ramdisk. For 0704 do;
 
After adding the above line (and saving the change of course ;-) ), you have to recreate the initial ramdisk. For 0704 do;
 
  /usr/pluto/bin/Diskless_BuildDefaultImage.sh
 
  /usr/pluto/bin/Diskless_BuildDefaultImage.sh
Line 46: Line 50:
  
 
Now reboot your media director. Everything should come up, the way it is meant to.
 
Now reboot your media director. Everything should come up, the way it is meant to.
 +
 +
== Troubleshooting ==
 +
 +
First, you need to understand what initramfs and vmlinuz are and how they are used for network booting. Vmlinuz is the first piece of code loaded (via TFTP) on PXE boot, and its entire job is to create a RAM disk, TFTP down the initramfs file, decompress it into the RAM disk, then hand control over to that code to continue. Initramfs contains a small Linux micro kernel and basic hardware drivers necessary to start networking, and mount a remote NFS share locally as the system "disk", then hand control over to that full kernel to start running normally.
 +
 +
The full kernel on 0810 (and probably 0710) will likely have the correct network driver for your NIC, however that is no use if the initramfs micro kernel doesn't have the driver, as it will not be able to start networking and mount the NFS share to get to the full kernel... catch 22! It would seem (I am deducing, I don't know for sure) that the NIC "driver" in vmlinuz is so basic that it will pretty much work on any NIC, so that doesn't need to be updated, and obviously the NIC "driver" used by the PXE firmware is able to drive your NIC because it came with the computer!
 +
 +
So the issue is usually initramfs. But you need to understand that there are 2 different initramfs's involved... the first is the "default" one used for _new_ MDs - ie MDs that have never been seen before my LinuxMCE. The instructions for that are at the top of that article. These are the easy ones to follow. The second is for after LinuxMCE has run the initial discovery on _first_ boot of your MD and assigned a device number, rebooted the MD, etc. The instructions for this one is the second part of that article and can be more difficult to follow what is going on because of the chroot bits...
 +
 +
Note that the first one is here /tftp/default/initrd and the second one is here /usr/pluto/diskless/##/boot/initrd... (which is then symlinked into /tftp/## ie different from the "default" location)
 +
 +
It is highly likely that you have successfully modified the default initramfs, so the first part of setting up an MD has gone through, and you will see it as a device in the device tree of web admin. But haven't successfully modified the second initramfs, which is used for all subsequent reboots.
 +
 +
The error message you are getting means that the driver module for your NIC is not loading and so the eth0 interface name doesn't get set up... ie no networking, and without that, you cannot mount the system "disk" over the network, so the kernel panics, as it cannot continue.
 +
 +
Note that the first uses /etc/initramfs-tools-interactor/modules the second /usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools/modules
 +
 +
You must edit BOTH /usr/pluto/diskless/<mediadirector-id>/etc/modules AND /usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools/modules before you chroot into the MD's files. And you must depmod before recreating the initramfs, as this is what reads those config files and tells the initramfs to load that module on start up. It can also be relevant if you modprobed the module into the kernel on the core before even creating the MD image.
 +
 +
One thing is certain though, once you make one stuff up, you can go back and try to fix it up but more often than not you end up in knots! It is usually better to go right back to the beginning and completely delete the MD from the device tree (and allow it to delete all the files - that's why deleting an MD is so slow) and starting again, being concious that the new MD will have a new device number, and that often it will detect it as AMD64 rather than i386, and if your core is i386 (which it should be) the chroot won't work...
 +
 +
BIOS boot firmware -> PXE boot firmware -> vmlinuz RAM disk bootstrap software -> initramfs Linux micro kernel boot software -> Linux full kernel
 +
 +
--colinjones
  
 
== Caveat ==
 
== Caveat ==
 
Whenever you click Regenerate this media director, you have to redo the step for the initial ramdisk of the media director.
 
Whenever you click Regenerate this media director, you have to redo the step for the initial ramdisk of the media director.
The above steps do not work, if the media director and the core utilize two different CPU architectures,ie. one is using AMD64 the other i386 (chroot won't work).
+
The above steps do not work, if the media director and the core utilize two different CPU architectures,ie. one is using AMD64 the other i386 (chroot won't work). Note - AMD64 does not necessarily imply an AMD CPU, it just means the CPU is in 64 bit mode. An Intel CPU can just as easily be AMD64, and vice versa for i386, it can be an AMD CPU, just in 32 bit mode. i386=32bit mode; AMD64=64bit mode, it says nothing about the CPU manufacturer.

Latest revision as of 00:40, 15 October 2012

Version Status Date Updated Updated By
710 Unknown N/A N/A
810 Unknown N/A N/A
1004 Unknown N/A N/A
1204 Unknown N/A N/A
1404 Unknown N/A N/A
Usage Information


Note If you have a r8168 NIC, see the r8168 page first.

Every now and then, people come along with NICs that are not directly supported by LinuxMCE. Typically when this happens you will see a 'Kernel Panic' during the initial PXE boot process. The following information should help to get even those NICs to work. As an example, the ASUS P5K is used, which is using the Attansic L1 NIC. You may have another chipset used in your NIC which will mean that you need to find out what the chipset is and importantly what kernel module is used to add support for it. Googling the chipset name and the words 'kernel module' will normally throw up some links to help you get the module name. Once you have that information you are ready to follow the simple steps outlined below;

Modify modules on core

To get a NIC to work, you have to modify a file;

sudo <editor-of-choice> /etc/initramfs-tools-interactor/modules

and add a single line for your NICs kernel module. In the above case the name of the module is

atl1

Or for the Marvell Yukon 88E8055 chip for example add;

sky2

Or for a foxconn nt330i / Aleutia H1 you'll need to download the linux drivers from Atheros http://partner.atheros.com/Drivers.aspx (or follow instructions and download drivers from http://joefleming.net/2010/05/26/atheros-ar8131-and-linux/ if that link is dead) and install them, then place the module in the modules file

atl1e

After adding the above line (and saving the change of course ;-) ), you have to recreate the initial ramdisk. For 0704 do;

/usr/pluto/bin/Diskless_BuildDefaultImage.sh

or maybe

mkinitramfs -d /etc/initramfs-tools-interactor/ -o /tftpboot/default/initrd

is enough.

This will create a new initial ramdisk for the first boot of new MDs containing the atl1 module (or in your case for whichever module you have added). Now, the first boot of the diskless MD will succeed and a new diskless media director will be created.

Modify the media director initial ramdisk

Note: If your MD is 64 bit capable, but your core is running 32 bit mode LMCE, when the initial MD diskless image is built, it will automatically build a 64 bit image. A 64 bit MD image and 32 bit core is incompatible with running the "chroot" command below. If this your situation, you will need to go to the Wizard->Devices->Media Directors in web admin, before continuing, and edit the Architecture field in the applicable Media Director to say i386 instead of AMD64, hit Update and then Rebuild Image. This will delete the 64 bit image and rebuild the MD's image as 32 bit. This takes a good few minutes to complete

Note: If you had to follow the R8168 NIC driver article before this article (or had to build/make any other NIC driver before coming here to assign it to your MD), note that the diskless images are created from a compressed archive, not from your core's files. Thus any changes you made, like adding a new <nicdriver>.ko to your /lib/modules/2.6.22-14-generic/kernel/drivers/net will not be present in your new MD image. So you will need to copy these files/changes from your live core image to your new MD image in the same locations, eg...

sudo cp /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko /usr/pluto/diskless/<MD#>/lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko and

sudo cp /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8169.ko /usr/pluto/diskless/<MD#>/lib/modules/2.6.22-14-generic/kernel/drivers/net/r8169.ko

To boot this diskless MD later on, the configuration for this new device has to be modified to include the above line as well. Look in the directory structure under /usr/pluto/diskless. Each media director has a directory named with the ID of the director in here. Go into the /usr/pluto/diskless/<mediadirector-id>/etc and edit the file modules to also contain

atl1

Also, go into /usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools and put the line into a file called modules. After this, chroot into the directory of the media directory, and re-create the initial ramdisk.

To create a new initial ram disk the command is

cd /usr/pluto/diskless/
chroot <mediadirector-id>
depmod
cd /boot
mkinitramfs -o initrd.img-`uname -r` `uname -r`
exit

Now reboot your media director. Everything should come up, the way it is meant to.

Troubleshooting

First, you need to understand what initramfs and vmlinuz are and how they are used for network booting. Vmlinuz is the first piece of code loaded (via TFTP) on PXE boot, and its entire job is to create a RAM disk, TFTP down the initramfs file, decompress it into the RAM disk, then hand control over to that code to continue. Initramfs contains a small Linux micro kernel and basic hardware drivers necessary to start networking, and mount a remote NFS share locally as the system "disk", then hand control over to that full kernel to start running normally.

The full kernel on 0810 (and probably 0710) will likely have the correct network driver for your NIC, however that is no use if the initramfs micro kernel doesn't have the driver, as it will not be able to start networking and mount the NFS share to get to the full kernel... catch 22! It would seem (I am deducing, I don't know for sure) that the NIC "driver" in vmlinuz is so basic that it will pretty much work on any NIC, so that doesn't need to be updated, and obviously the NIC "driver" used by the PXE firmware is able to drive your NIC because it came with the computer!

So the issue is usually initramfs. But you need to understand that there are 2 different initramfs's involved... the first is the "default" one used for _new_ MDs - ie MDs that have never been seen before my LinuxMCE. The instructions for that are at the top of that article. These are the easy ones to follow. The second is for after LinuxMCE has run the initial discovery on _first_ boot of your MD and assigned a device number, rebooted the MD, etc. The instructions for this one is the second part of that article and can be more difficult to follow what is going on because of the chroot bits...

Note that the first one is here /tftp/default/initrd and the second one is here /usr/pluto/diskless/##/boot/initrd... (which is then symlinked into /tftp/## ie different from the "default" location)

It is highly likely that you have successfully modified the default initramfs, so the first part of setting up an MD has gone through, and you will see it as a device in the device tree of web admin. But haven't successfully modified the second initramfs, which is used for all subsequent reboots.

The error message you are getting means that the driver module for your NIC is not loading and so the eth0 interface name doesn't get set up... ie no networking, and without that, you cannot mount the system "disk" over the network, so the kernel panics, as it cannot continue.

Note that the first uses /etc/initramfs-tools-interactor/modules the second /usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools/modules

You must edit BOTH /usr/pluto/diskless/<mediadirector-id>/etc/modules AND /usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools/modules before you chroot into the MD's files. And you must depmod before recreating the initramfs, as this is what reads those config files and tells the initramfs to load that module on start up. It can also be relevant if you modprobed the module into the kernel on the core before even creating the MD image.

One thing is certain though, once you make one stuff up, you can go back and try to fix it up but more often than not you end up in knots! It is usually better to go right back to the beginning and completely delete the MD from the device tree (and allow it to delete all the files - that's why deleting an MD is so slow) and starting again, being concious that the new MD will have a new device number, and that often it will detect it as AMD64 rather than i386, and if your core is i386 (which it should be) the chroot won't work...

BIOS boot firmware -> PXE boot firmware -> vmlinuz RAM disk bootstrap software -> initramfs Linux micro kernel boot software -> Linux full kernel

--colinjones

Caveat

Whenever you click Regenerate this media director, you have to redo the step for the initial ramdisk of the media director. The above steps do not work, if the media director and the core utilize two different CPU architectures,ie. one is using AMD64 the other i386 (chroot won't work). Note - AMD64 does not necessarily imply an AMD CPU, it just means the CPU is in 64 bit mode. An Intel CPU can just as easily be AMD64, and vice versa for i386, it can be an AMD CPU, just in 32 bit mode. i386=32bit mode; AMD64=64bit mode, it says nothing about the CPU manufacturer.