"PXE-T00: File name too long" on some machines
-
@yochaigal Well that’s an interesting one. Can you please get me a packet dump of that by running the following commands on the FOG server (while x.x.x.x is your client’s IP address!):
sudo aptitude install tcpdump sudo tcpdump -w /tmp/too_long.pcap udp and host x.x.x.xLeave that command sitting there and boot up your V570. After you hit the error stop tcpdump (ctrl + c) and upload the file /tmp/too_long.pcap here in the forum (or send me a PM with a download link).
-
@Tom-Elliott or even copy
undionly.kpxeto justu, surely one character is short enough? -
i’ve heard that some pxe clients (especially old ones) have problems with filenames longer than the old 8.3 limit (8 characters, a period, and a 3 letter extension, like DOS), but it’s uncommon enough that i haven’t seen it myself.
-
Thanks everyone for the replies - I will follow some of your suggestions as soon as I am able - unfortunately I woke sick this AM so it won’t be until tomorrow!
I really appreciate the help - what a great project!
-
I’ve attached the tcpdump file - wireshark tells me that you’re right on the money, though:
I also tried changing the undionly.kpxe file to just u.kpxe (and updated my dhcp server) but had the same result; is there something else I need to do when changing the name?
Thanks
-
@yochaigal u.kpxe still has 4 characters after the period, that may be causing issues if it’s trying to adhere strictly to 8.3 format (disclaimer: i haven’t looked at the pcap file)
-
@Junkhacker Oh right, that makes sense!
Well, I changed the name to undionly.pxe (8.3) - same issue. Uploaded new pcap file.
0_1463151170763_too_long.pxe.pcap -
@yochaigal Can you check for a firmware update for this troublesome target host?
-
could you try renaming the file to undionly.0 ?
-
@Junkhacker Done. Same problem:
0_1463154351281_undionly.0.pcap -
@Wayne-Workman I already did - it is using the “latest” release (late 2011).
-
Here’s a more general question:
I’ve setup FOG for my computer repair business; we install Win/Mac/Linux on a daily basis on all sorts of different hardware scenarios; we were originally looking into MDT until I found this amazing FOSS solution, that so far works great!
However, In instances where I’m dealing with different hardware on a regular basis, what is the best “fallback” scenario? Is there an alternative PXE booting utility I could use in these cases? I’ve already tried PLOP but had the same issue.
Thanks
-
you could try this http://ipxe.org/download
burn to cd or make a usb boot drive. this will load an ipxe network boot rom into memory and boot to it, instead of the network card’s onboard boot rom -
@Junkhacker Yeah, this totally worked! That’s really all I need; I doubt I’ll see another of these machines for some time.
Thanks so much you guys! Consider this thread solved. I really appreciate how quickly people here responded; I’ll try to help others in turn (at least, as much as I can!). -
Great to hear that you guys found a workaround to this. Thanks a lot for the pcap file anyway. It actually shows exactly what the error message is saying. I wouldn’t believe it if it wasn’t in the pcap! That machine is requesting not just
undionly.kpxebutundionly.kpxe\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377....
Looks like it’s padding the string withEOL(end of line) symbols. I have no idea why that is. If PXE booting is working fine for you with all the other machines you are perfectly fine with booting this one via the iPXE cd image! Don’t bother about it. -
Simple solution to file name too long is Long Path Tool.
-
@piercerob Can you explain what you mean? From my point of view there is no simple tool that can help you fix this.
-
@sebastian-roth I worked around the issue using an iPXE boot ISO.
