Realtek 8111\8168 & undionly.kpxe -> hangs on Initialising Devices...
-
Tom,
I recompiled a new undionly.kpxe using this site: rom-o-matic.eu and with help from these forums on chainloading default.ipxe, I was able to upload an image into FOG 1.0.0.
Is there a way to remove (or reduce) the 60 second wait time on the “i2c-parport-light adapter type unspecified” message before the kernel is finally loaded?
Embedded script:#!ipxe
dhcp
chain default.ipxeThanks again,
Andy
-
Again, I’m not aware of anything wrong with the undionly.kpxe file. The kernel however is a different beast. The kernel is simply trying to load the drivers. The only way to remove something is to remove the related item from the kernel in its entirety. This i2c-parport-light adapter isn’t necessarily the thing taking a period of time but rather the last message you see while the rest of the drivers are loading.
-
Just to add some more notes to the thread - my test machines include a Biostar A880GB+ motherboard with the Realtek NIC I referenced earlier. The other is an Asus laptop - a K60IJ with an Atheros AR8121/AR8113/AR8114 pci-e NIC along with an Atheros wireless card. Again, the “stock” FOG undionly.kpxe file didn’t work with the AR8121. I got a “insert boot media” error.
I decided to try using the undionly.kpxe file that I compiled for the Realtek NIC. Full host registration seemed to go fine but if I told FOG to image the computer upon reboot, undionly.kpxe would see the wireless NIC (identified as net0) and bypass that with an error. It would then identify the AR8121 (as net1) and boot into the FOG menu with a “Not a registered host” error. On a hunch, I yanked the wireless card and then imaging could take place properly if the AR8121 was identified as net0. I’m sure what this all means yet, but I wanted to note my experience.
These two hosts worked fine in 0.32 from start to finish, including snapins & multicasting.
Andy
-
I’m trying to get more familiar with iPXE. Am I OK to assume that I can (attempt to) build an all-drivers ipxe.kpxe file and use it with FOG as long as the script to chainload to default.ipxe happens? I’m trying to figure out why undionly.kpxe is being used by default in FOG. Thanks for any feedback.
Andy
-
undionly.kpxe is used by fog because it is compatible with more network cards. .pxe versions dump the UNDI and require recompiling with additional drivers to support new cards
-
This dirty hack in my default.ipxe file seemed to do the trick:
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
isset ${net1/mac} && chain [url]http://10.0.0.50/fog/service/ipxe/boot.php?mac=${net1/mac}[/url] ||
params
param mac ${net0/mac}
param arch ${arch}
chain [url]http://10.0.0.50/fog/service/ipxe/boot.php##params[/url] -
Why are you sending net1 instead of net0, are you booting from another nic, or is ipxe booting from another nic?
-
ipxe.kpxe (and undionly.kpxe for that matter) is identifying the wireless NIC as net0. I had to get to net1 somehow.
-
fyi, you can associate more then one MAC address with a host.
add additional MACs to a host on the host management page for that host. -
Thanks. All these years using FOG and I’d completely forgotten about that feature.
-
[quote=“tamatech, post: 26861, member: 24111”]Tom,
I recompiled a new undionly.kpxe using this site: rom-o-matic.eu and with help from these forums on chainloading default.ipxe, I was able to upload an image into FOG 1.0.0.
Is there a way to remove (or reduce) the 60 second wait time on the “i2c-parport-light adapter type unspecified” message before the kernel is finally loaded?
Embedded script:#!ipxe
dhcp
chain default.ipxeThanks again,
Andy[/quote]
Tamatech:Could you please be gentle enough to show how you did it (or share your working undionly.pxe)?
-
Baite:
Here’s my ipxe.kpxe.
Andy
[url=“/_imported_xf_attachments/0/843_ipxe.zip?:”]ipxe.zip[/url]
-
[quote=“Baite, post: 28277, member: 24308”]Tamatech:
Could you please be gentle enough to show how you did it (or share your working undionly.pxe)?[/quote]
You can also use any of the ipxe.*pxe files in trunk and this should work for you as well as it’s basically the same.
-
[quote=“tamatech, post: 28445, member: 24111”]Baite:
Here’s my ipxe.kpxe.
Andy[/quote]
Thank you, Tamatech -
[quote=“Tom Elliott, post: 28446, member: 7271”]You can also use any of the ipxe.*pxe files in trunk and this should work for you as well as it’s basically the same.[/quote]
Thank you, Tom. -
[quote=“Tom Elliott, post: 28446, member: 7271”]You can also use any of the ipxe.*pxe files in trunk and this should work for you as well as it’s basically the same.[/quote]
For me to use any of those files, I just need to replace the undionly.kpxe file with that one, right? -
Yes, and replace it AS the undionly.kpxe
-
After much trial and error, this one is working well for me.
[url]http://mastacontrola.com/ipxe/f3d42-QUOTA_20-GOOD/undionly.kkpxe[/url] -
[quote=“andjjru, post: 28706, member: 575”]After much trial and error, this one is working well for me.
[url]http://mastacontrola.com/ipxe/f3d42-QUOTA_20-GOOD/undionly.kkpxe[/url][/quote]Ohh yes that does seem to be a good file, my machines like that and so do my virtual machines as long as the exit method is set to “exit” and not sanboot.
-
I’m in the unfortunate situation of having a lot of important computers out there that require sanboot to continue to boot to hard drive, as well as a lot of important Dell laptops with IRRT enabled that need the opposite.
Rock, hard place, etc.
