PXE boot of 2.6.35 does not see Intel Pro/1000 adapter, disk install does
 

Hello.

I'm trying to PXE boot a 2.6 kernel, but am not seeing the network card once Linux is booted.

Why? I'm trying to use the fog imaging software, and the latest release (0.32) ships with an initrd which works with this kernel.

I've tried to build an initramfs without successfully booting (uncompress initrd, mount, cd into mount, create cpio archive, gzip cpio archive). I don't really know why that doesn't boot, since the errors go by too fast. I suspect it is failing to mount the root fs.

Anyhow, back to 2.6. The kernel which is supplied with fog (an older 2.6) does not boot on our hardware. I get a green screen. I suspect this is some sort of a driver issue.

I have built 2.6.35 locally, and the necessary drivers are included. This kernel does boot! But the network is not seen. Now when I look through dmesg output I see the Intel Pro/1000 driver load, but it doesn't see the hardware. I have compared this output with that from a machine with 3.9 installed on disk (with working network). The enumeration of the card does not seem to be happening.

I am at my wit's end at the moment. I have removed all of the other network drivers (no luck). I know the hardware is functional since I can boot off disk and use the network. Also PXE successfully loads the image from our server.

This system is using an Asus Sabertooth X79 motherboard (with bios one level back, latest which will boot windows 8 for us). Intel 3930K processor, 32G. I am using the network on the motherboard, which Linux identifies as an Intel Pro/1000.

I hope that is enough info to start with.

I really want fog to run on this machine. We have 11 identical machines, and I'd like to have a master disk image on the server which I can push out when necessary. These machines are in a university lab, and people will mess with them.

Thanks for reading. I really need some help with this.

When it does boot to some suspect kernel, can you use any tools like lspci or ifconfig to diag more.

I did use ifconfig, and saw nothing but the loopback device. This makes sense since the adapter did not show up in dmesg output.

lspci sounds like a good idea, I'll do that tomorrow (I'm at home now) and post the output. I don't think it will be a problem to add new executables to the ram disk image.

I'm thinking this is either some BIOS issue with PXE (in which case I'm sunk), or Linux not handling some exceptional situation.

Thanks for the suggestion.

lspci info
 

I was hoping to be able to post the output, but the machine is not seeing my flash drive. That's another issue, I won't get sidetracked yet.

I ran "lspci -vv" and found the info for the adapter. It is an Intel 1503, which wasn't supported in 2.6.35. I'm going to try building 2.6.39 and see if that helps. If that doesn't work, I see that Intel and Sourceforge have e1000 drivers.

Thanks again for the suggestion. Just the thing I needed to get over the hump.

No joy so far. The 2.6.39 kernel sees the adapter, but fails with "unable to allocate interrupt".

The driver from Intel is a loadable module, which I'd rather avoid if I could. Messing around with the ramdisk image sounds risky (recall that I am PXE booting this image)

The sourceforge driver is a bunch of files without so much as a README. So I have no clue what kernels it supports, or how to build it. I don't think I'm supposed to stuff them down in drivers/net/ (for 2.6 tree) and hope they build.

I'd sure like to ask on the fog forums, but they still have not sent the activation email. :-(

Maybe try this for a test.

Get an old Knoppix cd from maybe 3.3 or so. Pretty sure 3.3 worked OK and had similar kernel. (check)

Knoppix had a real neat way to run a set of scripts to get a booted live cd knoppix to run as a pxe server. Boot to knoppix on a test computer and then start Knoppix Terminal Server and fill in a few check boxes if needed. The intel ought to be supported out of the box I think. Then boot the pxe client to see if it does indeed work.

I'm happy to do that, but let's see if you still want me to do that after this update.

PXE client/server are working as they should. The 2.6 kernel boots (without the proper driver), but I cannot ask more of PXE than that.

The 3.x kernel has the proper driver but didn't boot. I have now pushed past that. When I made the initramfs image (as described in my original post) I mounted the 2.6 initrd and created a cpio archive of its contents. I never thought to question the files on that image. I had my suspicions about the mounting process, and they were well founded. There was no /etc/fstab.

/facepalm. The 2.6 image was a filesystem, and was mounted by PXE. The 3.x image is a cpio archive of files which need to be unpacked somewhere. Well, maybe that isn't the proper explanation. But I put a minimal /etc/fstab on, and the 3.9 kernel *almost* booted. It goes cruising along and then stops after enumerating the USB keyboard. There is a delay of approx 1.5 minutes then (retyping this while staring at dead machine)

Stopping Sockets.
Stopping target Sockets ...
Starting Emergency Shell ...
Staring Journal Service
Stopped udev Kernel Device Manager
emergency.service: main process exited, code=exited, status=203/EXEC
failed to start Emergency Shell
Dependency failed for Emergency Mode.
Unit emergency.service entered failed state.
systemd.journald[162] Received SIGTERM

then stopping a bunch of services
Startup Finished ... blah blah
<hang>

The 3.9 kernel was taken from Fedora 19 (the one happily running on this hardware). The filesystem was from 2.6, and included all of the fog software. There are probably some necessary files missing. I'll see if I can put together a minimal 3.x ramdisk and add the fog bits in later.

Update: giving up on that for the day. I think the mounting of root is still failing. At least I know more today than I did yesterday.

Fog was a neat idea. I looked at it before. Seems to have limited updates since 2011.

At first your indication was maybe irq or other resource on one of the fails. This old kernel may not be a great way to test new hardware. Also you might consider using a newer kernel on different setup like the other school LTSP or thin client setup for testing.

I still think that we need to look at booting this pxe via some means. Consider also GPXE/IPXE or even www.netboot.me for some general testing.

There may be some issue with how secure boot affects pxe that I am unaware of.

I think fog is still in development. Version 0.33 is in beta (but has been for a while). This is a complete rewrite, and perhaps a bit too ambitious. I don't feel that I have a lot of good alternatives. I've used Ghost on these machines, but it would do crazy things like only multicast to a few machines. When it "imaged" and then restored Vista resulting in a blue screen I gave up. I have found Ghost's support to be better than Symantec -- for years it has just worked.

I've made a lot of progress today. My attempts to get some minimal support for my adapter did not pan out. It will take a ton of time to go through that driver.

But... I have a 3.10 kernel booting into busybox. Startup is still messed up. The 3.10 ramdisk did not have init.d or inittab, but I believe busybox wants those. I put some modified versions of those on the ramdisk, but the busybox shell doesn't start. (Without those I get a shell). So I'll have to back some of these changes out.

I should have /var/log + shell access within the next couple of hours.

Do you need to automate this from server or can you go from machine to machine and perform tasks?

I'd prefer to have things automated. Going from machine to machine is on the table, currently somewhere around plan Y.

Some good news: I have been able to register on the fog forums, so hopefully I can find out how others are booting this kernel. I'm going to wait a bit and see what comes of that, but will summarize things here. I've learned a few things in the process.

If they know, let us know also.

16910
 

Hi! #ajgoreigFARE

Automated bot?

The kernel being booted over the network did not have the proper network driver. The ones with the proper driver were having IRQ conflicts during boot. I was able to remove unneeded drivers and get this kernel to boot.

... then it comes up and cannot see the disk drives.

One of the drivers I removed was the IDE driver. I figured that SATA would be fine without it (I don't believe there was a dependency). I'll dig into this more later