Hi guys, just looking for some explanations really
First of all, I haven’t really been able to understand, or find anything on, what “undionly.0” is and why its needed. Here’s my ltsp.conf file, modified after a 1.2 FOG installation:
pxe-prompt=“Booting FOG”, 0
pxe-service=X86PC, “Boot from network”, undionly
pxe-service=X86PC, “Boot from local hard disk”, 0
This gives a “TFTP Error - File Not Found” at PXE boot. If I copy undionly.kxpe to undionly.0, however, it works fine. I’d imagine a symlink should sort this; but what I don’t understand is
Why this didn’t come in the fog installation by default (I had to do this myself)
What the significance of the .kpxe file not loading and why a .0 file has to be used instead?
[*]Finally, I don’t remember doing this before when I set a 1.2 FOG server up, but I must have done, since it exists, now that I have had a check. It was, however, “modified” after the rest, so I suppose I made it myself!
Next - what do the following two lines do? They appear to be commented out in the new version of the guide for [URL=‘http://jbob.io/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE’]DNSMASQ configuration for iPXE[/URL] - but it isn’t actually explained why.
Finally, I don’t really understand why [I]/etc/exports [/I]is changed from:
Any explanations are very much appreciated
[quote=“Trevelyan, post: 47309, member: 7471”]Is it just avoiding possible data corruption, or certain data corruption? I haven’t seen any ill effects of not changing, to be honest. I’ll keep going without changing it but keep it in mind anyway. Thanks for explaining it! [/quote]
Is it just avoiding possible data corruption, or certain data corruption? I haven’t seen any ill effects of not changing, to be honest. I’ll keep going without changing it but keep it in mind anyway. Thanks for explaining it!
is commented out because it’s not really valid for the way ipxe works
in the [I]/etc/exports[/I] the change from [FONT=Consolas]async to [/FONT][FONT=Consolas]sync[/FONT] is to prevent data corruption
and the addition of fsid is due to it being a documented requirement for nfs4
[quote=“Trevelyan, post: 47285, member: 7471”]Cheers for the responses guys, works either way I guess. Still not sure why those two lines were commented out in the above guide - and I haven’t actually had to change my /etc/exports file either.
Like I said, those recommendations were from an earlier version of FOG, and may no longer be required. The development had been rather stagnate before Tom showed up and took the reigns. We haven’t seen much of the previous developers
Cheers for the responses guys, works either way I guess. Still not sure why those two lines were commented out in the above guide - and I haven’t actually had to change my /etc/exports file either.
undionly.0 isn’t needed, it’s just what dnsmasq extends to the end of the filename. Technically, it should be asking for undionly.kpxe.0 and then a file name .0 according to your configuration:
[code]port=0 #don’t ask as dns
log-dhcp #log the dhcp
tftp-root=/tftpboot #where is the folder for tftp (probably not needed but better safe right?)
dhcp-boot=undionly.kpxe,10.1.63.202 #filename to search will have .0 appended to it, in this case it should be looking for undionly.kpxe.0
dhcp-option=17,/images #17 is the option, I believe for NFS boot which just links the nfs directly to the /images folder
dhcp-option=vendor:PXEClient,6,2b #This is how the system is connecting. PXEClient is the most common
dhcp-no-override #Don’t override current dhcp server, just prroxy
pxe-prompt=“Booting FOG”, 0 #Booting FOG is wrong, it is looking for Harddrive, that’s the 0 option
pxe-service=X86PC, “Boot from network”, undionly (Here it will search/append .0 to the filename you’re directly trying to boot which is undionly so it will search for undionly.0
pxe-service=X86PC, “Boot from local hard disk”, 0 #fairly obvious, again 0 is the indicator to use the hdd[/code]
ProxyDHCP, for whatever reason, is always searching for <filename>.0 That’s it. That’s the only reason you need it.
This (adding the .0 to a file name) doesn’t come with FOG by default because, DNSMASQ isn’t produced by the FOG developers and isn’t installed by default. We only use the tool to help alleviate the issues with networks. You can USE the dnsmasq tool to help pxe booting machines to find your boot files, but it is not required. IF you use a DHCP server such as a windows server, you can supply Undionly.kpxe without any problems. The ONLY time you need the .0 is when you use DNSMASQ.
In the future, should we decide to use DNSMASQ by default (we may if we can get EFI booting to work or we may include it for simplicity) we will add in fixes for the .0 problem. But for now, DNSMASQ isn’t required to operate a FOG server, but it does help to solve some of the issues that occur.
If you want to understand WHY the .0 is required… feel free to check out the DNSMASQ man pages, and ask a few questions over there, but basically it’s required by the PXE standard which pretty much forces the use of .0 [url]http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q3/004285.html[/url]
I can’t tell you WHY the .0 is required, other than the standard enforces it, but I figured out that it is required when we first began moving to undionly.kpxe and the ipxe system from the pxelinux system. I kept getting “boot file not found” errors and in doing some research found that the file it was looking for was undionly.kpxe.0
The reason the .0 is required at the end of the bootfile is not something I fully understand, I only found the issue and recommended a symlink to solve it.
The two codes you mentioned above were used for the pxelinux system. They are commented out because they are not needed with ipxe, we may use it in the future to help with EFI, but basically dhcp-option is a tagging system to help DNSMASQ decide what needs to be booted or options or even the vendor, or point to another boot server or time servers, etc. By Default DNSMASQ sends some tagging information, but the use of the dhcp-option allows you to override this information what what you feel is pertinent. I urge you again to check out the man pages. [url]http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html[/url]
I honestly have no input on the /etc/exports change, that was something that was recommended in FOG well before 0.32 and we carried it over. It may no longer be required, further testing will be necessary to arrive at that conclusion.