Unidonly.0 question



  • 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:

    DNSMASQ configuration for iPXE - but it isn’t actually explained why.

    
    #dhcp-option=17,/images
    #dhcp-option=vendor:PXEClient,6,2b
    
    

    Finally, I don’t really understand why [I]/etc/exports [/I]is changed from:

    /images                        *(ro,async,no_wdelay,insecure_locks,no_root_squash,insecure)
    /images/dev                    *(rw,async,no_wdelay,no_root_squash,insecure)
    

    to

    /images                        *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1)
    /images/dev                    *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2)
    

    Any explanations are very much appreciated :)

    Thanks!


  • Developer

    @Trevelyan, post: 47309, member: 7471 said:

    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! :)

    potential.



  • 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! :)


  • Developer

    #dhcp-option=17,/images
    is commented out because it’s not really valid for the way ipxe works
    in the [I]/etc/exports[/I] the change from async to sync is to prevent data corruption
    and the addition of fsid is due to it being a documented requirement for nfs4


  • Developer

    @Trevelyan, post: 47285, member: 7471 said:

    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.

    Thanks!

    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.

    Thanks!


  • Senior Developer

    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:

    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
    

    ProxyDHCP, for whatever reason, is always searching for <filename>.0 That’s it. That’s the only reason you need it.


  • Developer

    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 http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q3/004285.html

    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. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

    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.


Log in to reply
 

354
Online

38746
Users

10569
Topics

100051
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.