LinuxMCE Forums
General => Users => Topic started by: amirul on September 18, 2008, 06:34:03 pm
-
Set it up as a diskless MD. PXE boot ok, but somewhere along after that I get
r8169: eth0: link down. Google tells me this is a common problem. Found a likely fix at link below:
http://adam.rosi-kessel.org/weblog/2008/06/21/a-much-simpler-fix-for-the-r8169-link-down-problem
Seems to suggest updating to kernel 2.6.26-rc5. What do you think?
-
Set it up as a diskless MD. PXE boot ok, but somewhere along after that I get
r8169: eth0: link down. Google tells me this is a common problem. Found a likely fix at link below:
http://adam.rosi-kessel.org/weblog/2008/06/21/a-much-simpler-fix-for-the-r8169-link-down-problem
Seems to suggest updating to kernel 2.6.26-rc5. What do you think?
See http://wiki.linuxmce.org/index.php/Realtek_8168 (http://wiki.linuxmce.org/index.php/Realtek_8168)
Andrew
-
Thanks, followed the instructions at
http://wiki.linuxmce.org/index.php/Realtek_8168
still getting link down message. Now my other diskless MD with the single core Atom board, after pxe booting, doesn't get past r8169.
Swapped back in the original r8169.ko, the single core is fine. The only difference I see between the 2 is that the dual-core has gigabit ethernet. Anywhere in the init scripts I can perhaps tell it to do only 100Mps?
Maybe I'll stick a disk with the dual-core and do a MD install to see how that goes
-
Thanks, followed the instructions at
http://wiki.linuxmce.org/index.php/Realtek_8168
still getting link down message. Now my other diskless MD with the single core Atom board, after pxe booting, doesn't get past r8169.
Swapped back in the original r8169.ko, the single core is fine. The only difference I see between the 2 is that the dual-core has gigabit ethernet. Anywhere in the init scripts I can perhaps tell it to do only 100Mps?
Maybe I'll stick a disk with the dual-core and do a MD install to see how that goes
Looks like the D945GCLF2 uses the same NIC chip as the D945GCLF so it should work... double check you did the all the steps correctly.
Andrew
-
Exactly what I thought Andrew. But the boot process didn't agree. However I've gotten further.
1. Download from Realtek source for r8168 and compile to r8168.ko
2. Rename r8169.ko to r8169.ko.old to get it out of the way
3. Add a line with r8168 into /etc/initramfs-tools-interactor/modules
4. Ran Diskless_BuildDefaultImage.sh to get new default initrd for tftboot
5. Reboot MD - and a new diskless media director is created, 96 in this case (yay!)
Then when the brand new MD is rebooted, get hit by the same r8169 showstopper. So I dig into 96/etc/initramfs-tools/modules and add line with r8168.
Do step 2 in 96/lib/modules/2.6.22-14-generic/kernel/drivers/net/
Next utter the following incantation
cd /usr/pluto/diskless/
chroot 96
cd /boot
mkinitramfs -o initrd.img-`uname -r` `uname -r`
exit
With fingers crossed, reboot
Success? No, greeted by ipconfig: eth0: SIOCGIFINDEX: No such device
I was so close....
-
Exactly what I thought Andrew. But the boot process didn't agree. However I've gotten further.
1. Download from Realtek source for r8168 and compile to r8168.ko
2. Rename r8169.ko to r8169.ko.old to get it out of the way
3. Add a line with r8168 into /etc/initramfs-tools-interactor/modules
4. Ran Diskless_BuildDefaultImage.sh to get new default initrd for tftboot
5. Reboot MD - and a new diskless media director is created, 96 in this case (yay!)
Then when the brand new MD is rebooted, get hit by the same r8169 showstopper. So I dig into 96/etc/initramfs-tools/modules and add line with r8168.
Do step 2 in 96/lib/modules/2.6.22-14-generic/kernel/drivers/net/
Next utter the following incantation
cd /usr/pluto/diskless/
chroot 96
cd /boot
mkinitramfs -o initrd.img-`uname -r` `uname -r`
exit
With fingers crossed, reboot
Success? No, greeted by ipconfig: eth0: SIOCGIFINDEX: No such device
I was so close....
Hmmm... ok give me a few hours and I'll check with one of my guys here and see if we can figure this out.
Andrew
-
Yay, I got it to fully boot! I don't know exactly what I did but it began with messing with update-initramfs -uv. The verbose output didn't seem to list r8168. So I tried depmod -a, fail. Tried depmod /lib/modules/.../net/r8168.ko then update-initramfs, it got it listed but booting still fail. Did depmod -a again, update-initramfs got it listed and boot success!! Going thru the config right now...
-
admirul... I got the same netboot problem with the D945GCLF2. Please help.
-
cyf4746,
Did you try what I did in http://forum2.linuxmce.org/index.php?topic=6253.msg37717#msg37717 ?
Good luck,
Amirul
-
Dear Admirul.
I did followed your steps:
1. Download from Realtek source for r8168 and compile to r8168.ko
2. Rename r8169.ko to r8169.ko.old to get it out of the way
3. Add a line with r8168 into /etc/initramfs-tools-interactor/modules
4. Ran Diskless_BuildDefaultImage.sh to get new default initrd for tftboot
5. Reboot MD - and a new diskless media director is created, 96 in this case (yay!)
Up to step 5, reboot MD fail. No diskless media is created.
Please help....
-
cyf4746,
At what point did the boot process fail?
Amirul
-
Dear Admirul,
The process stop at :
r8169: eth0: link down
Same as before I follow your steps.
Do I have to re-install the LMCE and start follow your steps from fresh?
Please help...
cyf4746
-
cyf4746,
Your setup is still using the r8169 network driver where it should be r8168. Maybe you can google how to build your default initrd to include r8168 not r8169. I've got another identical md to set up, I'll report how I got on with it.
Amirul
-
Thanks Admirul...
-
Amirul
I have the exact same problem with my MSI Wind PC which is based on the 945/8169/8111C chipsets
How did you go with the checking you were going to do? I'm stuck at the point where it is obviously loading the driver and that disables the link. So it doesn't even start building the MD image, it is still in the initial boot phase. I have looked at totallymaxed's wiki article but that is for the 8168 on the Asus machines.
I'm not sure I follow what you were doing in these instructions - it looks like you are compiling the 8168 driver to be used instead of the 8169. Assuming that the 8168 driver is happy to drive the 8169 chip, I don't actually see a step where you rename the 8168.ko to 8169.ko (only the part were you rename away the 8169.ko) is that not necessary, or doesn't it look at the file name?
Col.
-
Thanks Admirul...
See this wiki page we put up to explain what to do http://wiki.linuxmce.org/index.php/Realtek_8168 (http://wiki.linuxmce.org/index.php/Realtek_8168)
All the best
Andrew