Diskless MDs not PXE booting

[purps]

Hmmm. You said one of the NICs is an Intel - is that the non-onboard one? Is your onboard one a Realtek by any chance?

And you've tried all possible combinations of swapping the labels in udev and swapping the cables (either physically or in web admin)?

Could it be that both your Jetway and HP laptop both have unrecognised NICs? I'm sure you're aware that Kubuntu 810 is somewhat long in the tooth now, so you do need to sometimes fart around with more modern hardware in order to get it working.

Cheers,
Matt.

[klovell]

Something is preventing DHCP from working correctly. It's not the hardware - both nics can get DHCP IPs from my IPCop firewall.  No matter how many times I install LinuxMCE, I see the same problem.

I'm not trying to be an ass but unless there is a problem with the snapshot you downloaded this pretty much means there is a hardware problem.  Either broken, bad connection or not compatible.  Try a different snapshot to confirm, boot to an os other than linuxmce and confirm the nics actually work, then replace (not swap) cables. If all these test come back okay, check the LMCE network diagram and make sure you're connected properly.

From my experience the pxe boot, DHCP portion of LMCE just works.  I can't recall ever having a problem that swapping cables didn't fix and there is nothing to configure.  I had an issue once with one MD that had a wireless and wired card, but it was pretty far along in the boot process indicating the system did pxe boot.  I think it started booting off the wired nic but at some point tried to finish on the wireless nic which caused the system to reboot in an infinite loop.  The problem went away after I disabled the wireless card in the bios.  Are you certain the PXE boot is failing and not the boot up itself?  <--- I couldn't phrase that any better...

[m3freak]

Hmmm. You said one of the NICs is an Intel - is that the non-onboard one? Is your onboard one a Realtek by any chance?

Yes, the on-board nic is a Realtek:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
Subsystem: ASUSTeK Computer Inc. Device 8432
   Flags: bus master, fast devsel, latency 0, IRQ 220
   I/O ports at d800 [size=256]
   Memory at fdfff000 (64-bit, prefetchable) [size=4K]
   Memory at fdff8000 (64-bit, prefetchable) [size=16K]
   Capabilities: <access denied>
   Kernel driver in use: r8169
   Kernel modules: r8169

And you've tried all possible combinations of swapping the labels in udev and swapping the cables (either physically or in web admin)?

I believe so.

Could it be that both your Jetway and HP laptop both have unrecognised NICs? I'm sure you're aware that Kubuntu 810 is somewhat long in the tooth now, so you do need to sometimes fart around with more modern hardware in order to get it working.

IPCop is even older, yet it happily hands out IPs to these devices.  I know Kubuntu 8.10 is old, but IPCop runs a 2.4 kernel!  LinuxMCE loads the kernel modules for the NICs no problem - they wouldn't come up otherwise, right?  Also, I've used both NICs as the external interface - they got IPs from my external DHCP server without issue.

The PC I have LinuxMCE installed is new.  Well, 6 months old now, but still...

I really hope I'm not missing something basic.

[m3freak]

I'm not trying to be an ass but unless there is a problem with the snapshot you downloaded this pretty much means there is a hardware problem.  Either broken, bad connection or not compatible.  Try a different snapshot to confirm, boot to an os other than linuxmce and confirm the nics actually work, then replace (not swap) cables. If all these test come back okay, check the LMCE network diagram and make sure you're connected properly.

I installed Fedora 15 on the same PC a month ago when I was having problems with getting LinuxMCE to see the IDE drive (I'm using an old PATA drive for the OS).  Fedora 15 saw all the hardware without any problems. Everything works.

Are you certain the PXE boot is failing and not the boot up itself?  <--- I couldn't phrase that any better...

To be exact: the DHCP bit is failing.  That is, before the MD starts to boot off the network, it's supposed to get an IP from the DHCP server (on the core). It's the DHCP part that's failing.  Thus, the MD never starts the PXE boot.

Maybe I should try out 10.10 just to see if my hardware works with it.

[purps]

Yes, the on-board nic is a Realtek:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
Subsystem: ASUSTeK Computer Inc. Device 8432
   Flags: bus master, fast devsel, latency 0, IRQ 220
   I/O ports at d800 [size=256]
   Memory at fdfff000 (64-bit, prefetchable) [size=4K]
   Memory at fdff8000 (64-bit, prefetchable) [size=16K]
   Capabilities: <access denied>
   Kernel driver in use: r8169
   Kernel modules: r8169

I bet that's the problem. There are known issues with the r8169 module in 810. The NIC may APPEAR to be working fine i.e. you can get on the internet, see other machines, etc, but it's secretly being crap.

Blacklist the r8169 (add "blacklist r8169" to /etc/modprobe.d/blacklist) and then run...

Code:

update-initramfs -k all -u

Then remove the r8169 driver with...

Code:

rmmod r8169

Then download the r8168 driver from the Realtek website http://www.realtek.com/downloads/downloadsview.aspx?langid=1&pnid=13&pfid=5&level=5&conn=4&downtypeid=3&getdown=false, extract it, and run the script (no need to make and build and install and what not, the script does all that).

Then I would label the Realtek NIC to be eth1 in "/etc/udev/rules.d/70-persistent-net.rules", because we know that definitely supports PXE booting, make the Intel one eth0 of course, make sure that eth0 is on external and eth1 is internal (look on the advanced page on any orbiter, or in web admin, and swap interfaces if necessary), and then see how you get on.

Cheers,
Matt.

[uplink]

First, whoever said "eth0 is supposed to be external", forget that idea and beat whoever put it in your head to begin with

Next, I always hate it when the DHCPOFFER reply seems to get lost on the network. I still don't have a pattern about how to fix this when it happens. Last thing I wanted to throw into a wall because of this was a SoundBridge (their forums said it was a hardware issue, so no hope for a fix in a firmware update).

m3freak: I'm pretty sure your core is OK. The problem is when negotiating DHCP. Could be as "simple" as what purps said. Could be something else altogether. If I can run a LiveCD on a machine that exhibits DHCPOFFER-ignorance, I run a LiveCD just to make damn sure I can get DHCP with the out of the box distro. If not, I look in /var/log/syslog on both the Core and the machine in question to match them up. I even go as far as to run tcpdump on the machine that won't take DHCPOFFER as an answer to see if the message comes in (at this point I also get all kinds of ideas that there might be a "third party" on the network messing things up).

Not an easy thing debugging this. And it's annoying too.

I only skimmed over the thread, but I think the Realtek you mentioned is in your core. Try to leave the driver swap for last. See what you have in the machine you want to use as an MD.

[uplink]

One thing that did come to mind is this:

The DHCPOFFER message doesn't contain the parameters for PXE boot, so the machine is ignoring it. Not exactly sure how this could happen though.

But if you look in /etc/dhcp3/dhcpd.conf you should see a section that looks like this:

Code:

subnet 192.168.80.0 netmask 255.255.255.0 {
        next-server 192.168.80.1;
        filename "/tftpboot/pxelinux.0";
        option pxelinux.reboottime = 30;

        default-lease-time 86400;
        max-lease-time 604800;
        pool {
                 allow unknown-clients;
                 range 192.168.80.129 192.168.80.254;
        }
}

The important bit here is this:

Code:

        next-server 192.168.80.1;
        filename "/tftpboot/pxelinux.0";

If these two lines are missing, the PXE BIOS doesn't even bother to continue the negotiation and starts from the beginning. If they're not there it means someone decided to break PXE booting for some unknown reason.

[m3freak]

But if you look in /etc/dhcp3/dhcpd.conf you should see a section that looks like this:

Code:

subnet 192.168.80.0 netmask 255.255.255.0 {
        next-server 192.168.80.1;
        filename "/tftpboot/pxelinux.0";
        option pxelinux.reboottime = 30;

        default-lease-time 86400;
        max-lease-time 604800;
        pool {
                 allow unknown-clients;
                 range 192.168.80.129 192.168.80.254;
        }
}

The important bit here is this:

Code:

        next-server 192.168.80.1;
        filename "/tftpboot/pxelinux.0";

That's all there.  I've checked the dhcpd.conf file dozens of times.  I was hoping the problem was a simple misconfiguration, but as far as I could tell, it wasn't.

[purps]

What NICs are in the MDs out of interest?

Cheers,
Matt.

[m3freak]

What NICs are in the MDs out of interest?

I don't know.  I'll find out tonight.  I'll probably just boot the thing from a USB stick to get the answer quickly.

[coley]

First, whoever said "eth0 is supposed to be external", forget that idea and beat whoever put it in your head to begin with

Apologies I may have implied this - must be a hangover from early 0810 installations, eth0 was needed as internet interface for the installer script.
-Coley.

[purps]

Apologies I may have implied this - must be a hangover from early 0810 installations, eth0 was needed as internet interface for the installer script.
-Coley.

Yeah me too, I remember it used to be in the installation instructions, specifically for the Internet install I think. I believe it was just to ensure the machine had some Internet going into it, and it was assumed that eth0 would be the NIC to provide it. I also seem remember it saying something along the lines of "alternatively plug cables from your router into both NICs, just to be sure".

But we digress.

[pigdog]

Hi,

Just curios but - what happens on the MD when you are trying to PXE boot?

Do you get a kernel panic, do you get we are announced to the router, at what point does the MD fail and what is the message?

Cheers.

[uplink]

Hi,

Just curios but - what happens on the MD when you are trying to PXE boot?

Do you get a kernel panic, do you get we are announced to the router, at what point does the MD fail and what is the message?

Cheers.

He said it's not getting past the DHCPOFFER message in syslog, so I assume the MD says "Getting DHCP address" (or similar) with dots printed after it, possibly displaying a new dot once every 1-3 seconds. This is a PXE BIOS message. No Linux or boot loader has been loaded at this point.

[purps]

...possibly displaying a new dot once every 1-3 seconds. This is a PXE BIOS message. No Linux or boot loader has been loaded at this point.

What type of switch do you have, m3freak? You said you tried another switch - was it the same brand/model?