Sorry, didn’t think you’d read this that fast…
Tom is working on other issues right now and it might take an hour or two till he’s got time to add this to the code. Probably will be 3149 then.

We are working on it… ASIX AX88772B should be able to work with iPXE when using undionly.kkpxe instead of undionly.kpxe… For more information see here: [url]http://fogproject.org/forum/threads/hp-stream-11-pro.12330[/url]

Great to see that you guys have been busy working on this! I read through all of it and through a lot of things on the net too. It boilds down to: iPXE does not have a native driver for ASIX AX88772B. We could start porting the linux kernel source to make it part of the iPXE source (can’t see that I have enough time to do this) or we need to stick to UNDI (common NIC interface to not have to have a native driver for each and every piece of hardware). Unfortunately it seems like this NIC chip is kind of buggy and doesn’t work with iPXE’s undionly.kpxe straight away. Others have tried that before:
[url]http://fogproject.org/forum/threads/asix-ax88772a-initialization-failed.10825/[/url]
[url]https://gist.githubusercontent.com/robinsmidsrod/5696924/raw/1fbe20bd672e59beb1ca892a9321ddaeae113c68/gistfile1.txt[/url]

So we end up with having to use undionly.kkpxe for now. AFAIK there is no way around this at the moment. First step done!

Now iPXE loads the kernel and init.xz. This hangs on your hardware. Might be a NIC issue but I doubt it. Tom just added a new option to increase debugging output level in the web interface. So please update to current SVN, crank up the loglevel to ‘7’ and try again. The next screenshot will hopefully tell us what’s wrong then!

USB NIC support is still kind of new in iPXE. We try to help getting things to work but be prepared to be part of this process too. We need your help to be able to make things work.

@Cody Lee: Which USB adapter exactly do you have? Were you able to make FOG work with your adapter?

@Mike2014: Could you please take a another picture earlier in the process (what do you see before all the dots flash down the screen?). I am still trying to figure out which chip is used in you XZ613AA NIC.
It would be helpful if you could boot any kind of live cd (e.g. ubuntu) on a client with the adapter connected. Post the output of ‘lsusb -t’

Do you see any errors in your apache log files when mail is being sent? I guess you need to configure smart host with sendmail… [url]https://www.dnsexit.com/support/mailrelay/sendmail.html[/url]

[quote=“kansukee, post: 44184, member: 1017”]…
drwxrwxrwx 2 root root 4096 Sep 8 2014 T431s
drwxrwxrwx 2 fog root 4096 Mar 3 10:29 T510
drwxrwxrwx 2 root root 4096 Feb 17 13:43 T520
…[/quote]
Why is T510 owned by fog? Maybe there are other “issues” with those files in the directory?!?

[CODE]sudo chown -R root:root /images/T510
sudo chmod -R 777 /images/T510[/CODE]

EDIT: re-reading the whole thread I think this is not really relevant… sorry!

Have you tried my earlier suggestion?? For me this error sounds like the initrd issue on mac os x… see here: [url]http://fogproject.org/forum/threads/mac-support.11033/page-2#post-34584[/url]

I reckon it’s time to build your own ipxe binary with debugging enabled to get more information about this… see here: [url]http://fogproject.org/forum/threads/build-ipxe-from-source.10152/[/url]

[CODE]make … DEBUG=dhcp[/CODE]

Saw that… Does anyone know him/her? I also found a post (his/her only post!): [url]http://fogproject.org/forum/threads/how-to-using-your-fog-server-to-backup-and-restore-macintosh-computers.625/[/url]

Should I merge those infos into “FOG on a MAC”?? I don’t like to have similar information in several different places in one wiki… makes it hard to keep it all up to date.

We don’t have enough information to properly answer this. Let’s start right fromthe beginning:
[LIST]
[]PC boots up and is set to boot from network
[]requests an IP via broadcast and receives a DHCP offer including DHCP option 066 (ip to tftp server) and 067 (filename, probably undionly.kpxe)
[]tries to load tftp://<ip>/<file>
[]executes <file>
[/LIST]
FOG (1.2.0) boot images all include a short embedded iPXE script that requests the file ‘default.ipxe’ from that same TFTP server. SFTP is never used in the boot process!

To see if TFTP is properly working you should try downloading default.ipxe from one of your clients by hand! Boot into whichever OS you’ve installed and run tftp from the console/cmd:
[CODE]C:> tftp <ip>
tftp> get default.ipxe
tftp> quit
C:> type default.ipxe
…[/CODE]
If you cannot download the file you may look into firewall settings (iptables) or routing issues (route). Please provide more information on IPs (client and all servers) you use if you need more help on this.

[quote=“Tom Elliott, post: 44160, member: 7271”]It’s not in the init. I build them directly in the kernel.[/quote]
Not much difference. Makes the kernel bigger and bigger. But probably better then having a lot of people waiting for a minute for no reason…

[quote=“Tom Elliott, post: 44146, member: 7271”]I mean no harm with that, I just need to add the file to the compiler.

Hopefully doing that will fix the slow issue you’re seeing.[/quote]
Sure but how many firmware files do we add to the initrd? Most are for WLAN adapters which we don’t use with FOG (so far). But there are also a couple for normal ethernet adapters…

Was just a dirty hack anyway. So I guess we are back to the inital question of why does the kernel sit and wait for so long?? Right now I can only think of turning on kernel debugging to see where it takes so long. Open /var/www/fog/lib/fog/BootMenu.class.php, jump to line 435:
[CODE]…
$kernelArgsArray = array(
“mac=$mac”,
“ftp=$ftp”,
“storage=$storage”,
“storageip=$storageip”,
“web=$this->web”,
“osid=$osid”,
“loglevel=4”,
“consoleblank=0”,
“irqpoll”,
…[/CODE]
Change ‘loglevel=7’ and add another line just after that called ‘debug’…
[CODE]…
“loglevel=7”,
“debug”,
…[/CODE]
Schedule a task for the client and see the kernel messages scrolling past. Probably best to take a video or picture so you can check later on.

Kernels are placed in /var/www/fog/service/ipxe/ in FOG 1.2.0. Backup those, download the old FOG version and give it a try…
This is untested, think twice before following this blindly!
[CODE]cd /tmp
wget http://downloads.sourceforge.net/project/freeghost/FOG/fog_0.32/fog_0.32.tar.gz
tar xzf fog_0.32.tar.gz
find fog_0.32 -name “bzImage”
…<path-to-bzImage>…
cd /var/www/fog/service/ipxe
sudo mkdir kernel_backup
sudo mv bzImage* init*.xz kernel_backup
sudo cp /tmp/fog_0.32/<path-to-bzImage>/bzImage* .
sudo cp /tmp/fog_0.32/<path-to-bzImage>/init*.gz .
sudo chown www-data:www-data *[/CODE]

You might have to change /var/www/fog/lib/fog/BootMenu.class.php to match filenames… I am very interested to hear if you can get this to work. It might cause other trouble, so be warned!

Alright, I call this solved (eventhough it really isn’t). We’d be very happy to hear if someone can reproduce this so we are able to fix it. For everyone running into this: see post #39 in this thread on how to solve the issue yourself!

Interesting. Seems like it does not match the md5sum anymore. Not sure which kernel image this is but I downloaded 3.19.1.x and 3.19.0.x and non of the md5sums match! Please rnu this commands too:
[CODE]$ file -k bzImage
…
$ ls -al bzImage
…[/CODE]

Please try the following from a linux client within your subnet:
[CODE]$ tftp 10.10.0.235
tftp> get pxelinux.cfg/01-34-17-eb-83-ef-ed
tftp> get fog/kernel/bzImage
tftp> quit
$ md5sum bzImage
…
$ cat 01-34-17-eb-83-ef-ed
…[/CODE]
Please post the output…

You’ve made it pretty far with “NO” Linux knowledge. So you’ll be able to learn the rest too I reckon. Please make yourself familiar with GNU MAKE and play around with building your own ipxe binarys ([url]http://fogproject.org/forum/threads/build-ipxe-from-source.10152/[/url]).
We try hard to answer all the questions properly but we can’t give a step by step solution for everything. No offense!

[quote=“Bowen73, post: 44028, member: 29054”]has anyone used the intel nuc with fog?[/quote]
Not personally but I know someone who has! AFIAK he uses Intel NUC D34010WYK

The thread Wayne pointed out doesn’t sound very promising. At least some people were able to pxe boot. Try different bios versions and double check all bios settings every time you up/downgrad the bios!

From what I can see the config posted by Jeremy is perfectly fine. Maybe there is an old zombie of tftpd still running and listening on the port.
[CODE]sudo netstat -antup | grep “:69”[/CODE]
Kill any process you see before trying to start (service tftpd-hpa start) it again.

If this does not help or if you don’t have any zombie processes you might try starting it in “debug mode”:
[CODE]sudo /usr/sbin/in.tftpd --foreground -vvv -s /tftpboot[/CODE]

Then try tftp from another console:
[CODE]tftp 127.0.0.1
tftp> get default.ipxe
tftp>[/CODE]

You should see something like this in the logs:
[CODE]sudo tail /var/log/daemon.log
…
… in.tftpd[26418]: RRQ from 127.0.0.1 filename default.ipxe[/CODE]