This PCAP file (as well as the one he send me via mail) does NOT have the PXE information (DHCP option 66/67, next-server, filename). Sure the client is not able to PXE boot. Please talk to your network guy!
Posts made by Sebastian Roth
-
RE: iPXE Error - Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b)
-
RE: FOG menu don't boot Windows - Chainloading failed
@thomasdec This is another very weird thing here LoadImage (EFI) function is not able to lead the bzImage although it seams to be intact (file size and signature checked)! So we need to dig into the EFI calls. Please try this ipxe.efi (compiled with
DEBUG=efi_wrap
) -
RE: Kernel update
@Pascal-Gazaille Is this with an external DHCP server? Just for the fun of it, would you want to try UEFI as well? Change from legacy BIOS to UEFI on your DELL Latitude and from undionly.kpxe to ipxe.efi on the DHCP server…
More and more UEFI is coming and it’s good for us to know how well we handle this already.
-
RE: Kernel update
@Pascal-Gazaille Wayne is asking for the iPXE boot file, so
undionly.kpxe
,undionly.kkpxe
,ipxe.pxe
,ipxe.efi
,snponly.efi
… -
RE: FOG menu don't boot Windows - Chainloading failed
@thomasdec Here is a signature file bzImage.sig for the current kernel image ( @Tom-Elliott I hope you don’t intend to update the official kernel images right now - would break my signature file…).
As well you need a “special” ipxe.efi binary (CA cert included).
-
RE: PXE boot DHCP settings check
I just compiled and tested
dhcping
. I think it’s useless for what we are trying to achieve. There is no way to specify DHCP options and we won’t get option 66/67 back from the DHCP server.The mentioned
dhcptest
tool does what we want but I actually don’t want to add another language (D in this case!) to the pool. I’d actually prefer to go along the lines of what we are running on the clients already - the FOG client. Don’t think it needs to be build into the FOG client but rather have a simple extra tool for users (ready to be downloaded via the FOG web gui if someone has trouble with DHCP). Possibly there is something to start from: http://windhcp.codeplex.com/releases/view/8903 -
PXE boot DHCP settings check
Reviving the a discussion I had with George a while ago about potential and usefulness of tools to check on PXE boot information in DHCP packets. The first idea was to have a listen only (capture) tool which I didn’t really like because it would need to run on a second PC while another one is PXE booting. Because of that we possibly don’t see the DHCP answer packets as they might be unicast or don’t reach that second client due to other network setup issues.
It should be fairly easy to get more information without using a hub or monitoring port by sending “fake requests” from a client that is not actually PCE booting at that moment. I have tried it using dhcptest (cmd options:
--query --wait --option 60=PXEClient:Arch:00000:UNDI:002001 --request 66 --request 67
).I had a quick look into PHP’s socket operations and I am sure it would be quite easy to implement a DHCP PXE boot info check. The only problem is that you are allowed to send packets from low ports (DHCP src port 68) as root!! So this would need another FOGService to run on the server. I don’t really see why we should add another FOG daemon which is not useful as soon as PXE boot is working for you. So I guess we better focus on the idea of having a cross platform client binary. This way we also see if network issues on the client would prevent DHCP answers from reaching the client - even better!
PS: I moved the posts from the other (kind of unrelated) topic here as well.
-
RE: new fog appliance
@Wayne-Workman While I agree with pretty much all you said about the VM and I had dismissed ISO already I might change my mind now that I have played with FAI a little bit more. My new working place is heavily using this project and I am starting to dive into it as well. Don’t get me wrong - this is not meant as alternative to FOG! It’s just what am going to work on soon and - as it turnes out - might be helpful for FOG as well.
I successfully setup an automated installation of debian/centos (more to come!) with added FOG installation on first boot. My first intention was to auto-test the FOG installer script on several systems. But now I see this might be adding a new direction to this VM discussion - because FAI comes with a useful command called
fai-cd
. From the man page:This command creates a bootable ISO CD-ROM image that performs the fully automatic installation from CD-ROM without an install server.
-
RE: DB wait_timeout
@Wayne-Workman Same here, 8 hours on Debian! Are you concerned about it being that high or what especially made you aware of this setting. My guess is that MySQL connections that don’t get any input for 8 hours straight will be terminated from the server side. All good I reckon!
-
RE: PXE-E32 error, unable to boot to fog from pxe
@Wayne-Workman Sure because this is the request sent by the client! It does not show the answers as those are requests from other PCs and the DHCP server seams to answer unicast instead of broadcast.
-
RE: PXE-E32 error, unable to boot to fog from pxe
I tried to get more information without using a hub or monitoring port by using this tool to send a DHCP PXE request to the DHCP server. For the record, command line options:
--query --wait --option 60=PXEClient:Arch:00000:UNDI:002001 --request 66 --request 67
Unfortunately something went wrong and the output.pcap still does not have the information we need. Will probably need to try again on Monday…But I remember a discussion about DHCP test tools with George. Back then I wasn’t very convinced for it to be a good idea. Can’t really remember which tools we talked about. I think it was more about tools that would read and display DHCP packets on the client. Now with this kind of tool that we used just now it would be very easy for pretty much every beginner to just send out a “fake” DHCP PXE boot request and see what the DHCP server’s answer is. I am thinking about having a simple (cross platform) command line tool which the user can download from his FOG server as soon as he has access to the web gui. Run the tool and it shows you your DHCP infos.
Now that I think of it why don’t have it integrated into the web interface? On click the FOG server sends a DHCP PXE request and shows the info…
-
RE: iPXE Error - Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b)
Follow Wayne’s answer (newer tutorials and FOG trunk is the future) but for now we can see if we can make this work for you as a testing machine.
- definitely use Bridged network if your DHCP is external (not on the FOG server) as you described - internal network won’t work!!
- “No such file or directory” most probably means that the filename configured on the DHCP is incorrect (double check it to be “undionly.kpxe” - all lower case) or the file is missing on the FOG server - check with:
ls -al /tftpboot/undionly.kpxe
- dnsmasq is not needed of DHCP is setup properly by your college!
Please enable packet capture on the client VM. Try netboot and upload the PCAP file to the forum. This will be the most helpful information you can give!
-
RE: new fog appliance
@VincentJ said:
… could you create a netinstall iso …
Although I kind of like the idea I refuse to go this way. I have looked into building bootable ISOs lately and it’s a very dark place!!! Some people have 32 bit CPU some 64 bit (yes even in VM!) and then some use BIOS and others UEFI which is even more hell then the 32/64 bit issue!! I don’t wanna answer those hundreds of “ISO does not boot on my XYZ” questions.
Sure we won’t be able to create a VM that suits everyone. But except the disk size (which we can make 512 GB - non pre allocated) all the other things you mentioned can easily be adjusted by really any person being able to download and start a VM! So I don’t see the point of digging into the ISO mud…
-
RE: PXE-E32 error, unable to boot to fog from pxe
@K-Hays Well either you want us to help you or you want to figure this out yourself. If we don’t have information we are pretty much helpless. I am kind of over it to ask 20 questions to get things like this fixed instead of just looking at the PCAP file that will give me all the details I need. Feel free to check out the PCAP file using wireshark yourself!
By the way, I had a look before you deleted it:
- Private IP addresses - no chance anyone here would be willing or able to make use of those to harm you
- A few DNS requests for porn URLs - just joking!!!
- DHCP wise I only see one
discovery
and onerequest
packet - not enough to find out what’s going on - I guess your DHCP server is responding to the client directly instead of broadcasting (which is kind of unusual as the client requests broadcasting in its packets)
For next time: The more filters you use with tcpdump the less we see in the PCAP file. But adding to many filters might possible hide important information. As well you can open the PCAP file in wireshark, add display filters till you are happy with it and then export the remaining packets
-
RE: No Replication to second Fog server, after updating to latest Rev. 5157
@John-L-Clark Newer linux versions usually use the commands:
service vsftpd restart
orsystemctl restart vsftpd.service
-
RE: Change Path For Images Trunk 7025
@LJedi You can change the path within FOG but I find it quite confusing to have
/images/images
. I guess you are doing yourself a favor if you if you move the images to the correct location. From what I read between the lines your iSCSI device is probably mounted in/images
and on that you have a folderimages
. What about:sudo mv /images/images/* /images sudo mv /images/images/.mntcheck /images
-
RE: PXE-E32 error, unable to boot to fog from pxe
Which version of FOG is this?
-
RE: Mounting file system: Failed. Uploading my first image
@Wayne-Workman said:
I really doubt it’s the unmanaged switches fault, and I’m willing to lay 99% odds it’s a cable.
While I totally agree on what you said and fully trust in your network knowledge (I mean that!) this is not a cable issue from my point of view - not this time at least:
http://www.viktorious.nl/2013/11/05/cisco-sg200-08-nfs/
https://supportforums.cisco.com/discussion/11755791/sg200-08-firmware-issueOther than that I found this as well: http://serverfault.com/questions/367107/cant-mount-nfs-share-over-tcp
Turns out there was a “security” feature enabled on our PowerConnect switch that took offense to NFS SYN packets with source ports < 1024 (dos-control tcpflag). Suffice it to say, disabling the feature solved the issue.
Reading this again I think this is actually the case here. Why? Because I made Miguel try
telnet <fog-server-ip> 56557
(the actual NFS data port) and it worked - as telnet is not using a high source port I suppose. -
RE: Task Management menu unavailable on Fog Web interface
@Seydoo My guess is that you had an old task in the list and deleted the host object. Seams like this is not something we have checks for in FOG 1.2.0. Please connect to you DB via command line client or phpmyadmin and see what you get from this:
mysql --user=root -p Enter password: ... mysql> use fog; ... mysql> SELECT * FROM tasks WHERE NOT EXISTS (SELECT * FROM hosts WHERE hosts.hostID = tasks.taskHostID ); Empty set (0.00 sec)
On my DB the query returns an empty result set because I don’t have tasks which are not connected to any host. But I guess you will see at least one entry. Note down the
taskID
and doDELETE FROM tasks WHERE taskID = 999;
(put in the taskID you saw from the SELECT statement)PS: @Tom-Elliott I tested and it is not causing a problem in FOG trunk. Although those task entries will stay in the DB forever…