@networkguy I know why I keep asking people for posting a picture of what they see. Don’t want to sound arrogant but we usually see more than most users (especially as there are more eyes in the forums!)… The picture you posted is showing a different error than you initially posted. Timeout on default.ipxe is totally different than timeout on the preceding DHCP request.

@george1421 said:

Is there a way in the iPXE kernel script to either try X times then die or set a startup delay to give the NAC system a chance to reregister the device between each network wink?

This reminds me of the fact that the iPXE developers added some kind of spanning tree detection (and wait) probably about two years ago. So I am wondering if this should be addressed within the iPXE source as well. A quick search for “ipxe 802.1x” on the web revealed this post. While I haven’t tested it to me this sounds like iPXE in fact should cope with basic EAPOL stuff. I will check the code when I have a bit more time.

On page 5 of this presentation it says: “PXE Boot -> Open access”. From this document it seems to me that you need to configure your PXE booting ports as “Open access”. Sorry if you’ve already done this and it’s still not working. While I have done a fair amount of networking stuff I didn’t have a chance to look into that 802.1x stuff much yet. So this is just me flying “on sight” (means reading the manuals).

I’m also slightly hesitant to upload a pcap from our domain controller.

Perfectly fine. I do understand this. Less information simply means less professional help. Your choice.

@inafog9 Please set different DNS servers for testing. I have seen trouble with too big (and therefore truncated) DNS answers from the google DNS servers (the ones you have configured as well). Try opendns in your /etc/network/interfaces for example:

...
dns-nameservers 208.67.222.222 208.67.220.220

Then restart the network interface (sudo ifdown eth0 && sudo ifup eth0) and see if DNS lookup is better?!

@george1421 I guess Luke just means reading the setting and storing it together with the other information. Then on deploy you could also read the setting on the new PC and fail or at least warn if settings don’t match. At first I was going to go with what George said about tools not being available for linux across all platforms but then I remembered a tool called dmidecode. While I am not sure if this will actually help I stumbled upon the information possibly being available as simple as using lspci.

I tested three different computers (Lenovo and ACER workstation and Lenovo x230 laptop) and all gave me similar results:

# old Lenovo workstation
lspci | grep AHCI
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05)

# ACER workstation
lspci | grep AHCI
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)

# Lenovo x230
lspci | grep AHCI
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 4-port SATA Controller 1 [AHCI mode] (rev 05)

Switching the later one to IDE (compatibility) in BIOS the output changed to [IDE mode] when running lspci again. So I am pretty sure we should be able to add a detection without much fuzz. Not sure how reliable this is but to me this sounds pretty “stable” as we run a very recent kernel version. What do you think @Senior-Developers and @Developers?

You are welcome! As well I learned to pay even more attention to what I see in the PCAP file. Would have saved us at least an hour or two… When testing with the command line client Scott didn’t know about the important -i option for Windows tftp command line client as described here. When looking at the PCAP file Scott sent me I didn’t notice that it tried to request the file in ‘netascii’ mode instead of ‘binary’.

So everything is working now and it was just the upper case filename option in the DHCP config…

@Wayne-Workman Nice one. Thanks for bringing it up. While I hate all the tracking stuff going on nowadays I think it can be used in a good and totally anonymous way to help improve things.

FOG already has got this but it might need improvment. I can take a look in the next week or so.

I am wondering if generating a GUID is really a good idea as it would make tracking possible again. Don’t like the idea. On the other hand we do need some form of ID to distinguish between…

@Ignacio Sorry but I have no idea what you are saying. What is your native language? Please write in your native language and we may be able to translate and find out what you mean.

@askingthisonething As soon as at least one person (better two) opt in to maintain the docker image we are ready to go.

@wdmartin As you see in the first screen it says /dev/sda1 where it shows /dev/sda2 in the second screen (Not expanding ...). So the 100 MB is only the first partition but not the whole image. The second partition fails. My guess is that the destination disk (in the VM) is simply too small to fit the sda2 image!

Please check the original partition table (/images/<image-name>/d1.partitions) on the FOG server to see what size the original disk was. You need to create the VM disk at least that big in your case - using legacy format partimage and sda2 obviously being a RAW/imager partition. Post the contents of d1.partitions here and we should be able to help you calculate the original disk size.

Starting a new discussion about this topic as Tom has put in some work into getting this important part of FOG to work with new things like eMMC, ePCI SSDs and what not. I feel that we should discuss things and post new findings to improve this even more.

I started looking into different methods of enumeration. Two seam interesting: lsblk and the information in /sys/block and accordingly /sys/class/block. After some research and testing I think we are on the right track with lsblk already! The sysfs information is great too but more complex to parse. lsblk is using the sysfs anyway.

Interesting things I came across:

• lsblk -I 3,8,9,... to only see devices with those major device ids (so we need less awk foo!)
• lsblk -o TYPE to distinguish between ‘disk’ and ‘part’ without trying to guess on the basis of minor device id or even device names like ‘mmcblk0boot0p1’. This seams to work with those new devices as well as we see here: https://communities.intel.com/thread/57157?start=0&tstart=0
• We might also be able to handle raid/md (http://linuxaria.com/pills/linux-shelllsblk) and logical volumes (http://unix.stackexchange.com/questions/90290/how-to-display-all-the-partitions-in-a-tree-like-format-primary-extended-and-l#90298) using the TYPE.

I am still not sure how to handle those mmcblk0boot0 disks. At first I thought they are used raw (dump bootloader straight to disk) but I haven’t found enough information to confirm. On the other hand I hardly find information about those disks really being partitioned. Seams like you can. But is this really used? Should we up/download those disks raw as they are very small anyway or better ignore them completely (as well as mmcblk0rpmb)? Does anyone know more about this?

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…

@Tom-Elliott said:

Downloading the image could become faster but it still has to be put on the HDD once the image was downloaded, which would only be at HDD speed after the download. Speed difference may be faster to download the image but you still had to wait to put it on the HDD.

I can confirm that in my tests the speed kind of picked up as more and more of the image arrived at the clients. But the network/switch also had to handle more and more.

BUT if I remember correctly I used a modified torrent client which was able to write the image straight to disk. Yes, I found that link! Very much to the end you see ./btdownloadheadless.py /tmp/bittorrent/currentimage.torrent --saveas /dev/sda1

@Junkhacker Re-reading the old thread on torrent imaging… I was somehow aware of this in the back of my mind but I actually didn’t remember that you were using it even at the cost of having to download first before dumping the image to disk. Must have been really useful for you. Are you still not using multicast? If you are keen to get this back into FOG (including writing straight to disk - otherwise does not make sense to me) I offer to put in what I know and tested a while ago.

Can’t believe it… this topic got five pages full of posts and dozens of hours of work from different people all in three days. And now this was all fixed by re-installing FOG trunk…

Removed from wiki as I don’t feel like anyone really cares about running FOG on a Mac OS X server…

@andyroo54 Thanks for noting! I just added this to the wiki: https://wiki.fogproject.org/wiki/index.php?title=Installation#VMWare_ESXi

@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…

@moses said:

One issue I noticed is the bandwidth graph is gone on the home page. The http://fogserver/status/bandwidth.php page seems to be missing.

Shouldn’t that be http://fogserver/fog/status/bandwidth.php??

@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.

Good catch man! Marking this solved.

Ok, together with Jbob I seem to have figured out a working set of libraries (SharpPcap and PacketDotNet) and C# code to send and receive the packets we want. Hopefully we’ll have the first alpha version of a tool ready soon!

Whoops, sorry. Didn’t properly read the @andyroo54’s last post… Good to hear that you solved it!