• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. george1421
    3. Posts
    • Profile
    • Following 1
    • Followers 65
    • Topics 113
    • Posts 15,342
    • Best 2,780
    • Controversial 0
    • Groups 2

    Posts made by george1421

    • RE: PXE-E78 Cannot locate boot server

      @mkstreet Is the fog server, dhcp server and target computer in the same subnet?

      If so then lets grab a pcap of the pxe booting process. On your FOG server install tcpdump program. Then start the pcap with the following syntax sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 After you start the tcp dump program then pxe boot your target computer. Once you get the error then press ctrl-c to stop the tcpdump program. Upload the pcap file here. That will let us see what is going on in your pxe boot environment.

      posted in Linux Problems
      george1421G
      george1421
    • RE: Slow IPXE UEFI?

      @Killklli OK so based on your testing the iPXE kernel setup is the slowest part of the booting process. I would have really like to see the iPXE uefi boot times to rule out pxe booting and pointing to the iPXE kernel it self. If I get some time tomorrow I’ll see if I can create the usb uefi boot. I know where the developers keep the configs for what they fold into FOG. Right now I don’t see a way around using iPXE…

      posted in General
      george1421G
      george1421
    • RE: PXE-E78 Cannot locate boot server

      This seems to be dnsmasq day today.

      I wrote a tutorial a while ago for setting up dnsmasq on centos 7. Please compare the configuration file here to what you have with your setup. https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

      If your fog server, dhcp server and pxe booting clients are in the same subnet then that is all you need to do. If any is on a different subnet then you need to do a few more things.

      posted in Linux Problems
      george1421G
      george1421
    • RE: Slow IPXE UEFI?

      @Killklli If you have time to experiment it would be interesting to know if its the PXE booting process, iPXE, the motherboard, or something else. (this is not a forever solution) I did create a process where we could boot the FOS engine using a USB flash drive. This process does not use the iPXE kernel at all, but uses GRUB instead. https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image I did also write a tutorial for usb booting the iPXE kernel in UEFI mode: https://forums.fogproject.org/topic/6400/usb-boot-uefi-client-into-fog-menu-harder-way In this tutorial I documented the steps to create an new iPXE kernel using rom-o-matic web site. Maybe there are specific iPXE kernel requirements that would make uefi pxe booting faster.

      Where do you see the most time being consumed during the booting process in uefi mode? (TBH at my work we still use legacy (bios) mode for everything even new hardware).

      posted in General
      george1421G
      george1421
    • RE: Slow IPXE UEFI?

      I’m working with the new version of dnsmasq in another thread: https://forums.fogproject.org/topic/8677/dnsmasq-bios-and-uefi And I’m finding that its the uefi firmware that is slower as compared to bios (legacy) mode. It takes 3-4 seconds to just start to send the initial dhcp request packet as compared to legacy mode. This is all firmware at this point not anything to do with a boot kernel in my experience. And then the next slow down comes as the boot kernel discovers all of the devices and associates drivers with the hardware.

      At this point I’m not sure if there is anything that can be done with speeding up pxe booting to OS. In our case we don’t pxe boot through fog to boot the OS off the hard drive. This saves us on startup time. The down side is that someone has to physically sit at the computer to image it (which typically happens less than three times in the life of the target computer).

      posted in General
      george1421G
      george1421
    • RE: i219LM NIC, ASUS Q170M-C Motherboard

      @dustindizzle11 Its not clear in my mind, is it time that fixes the issue or manually bringing up the interface?

      If its manually brining up the interface (or time for that matter), you “could” create a custom init.xz (i.e. init_asus.xz) that executes the ifup command during the initialization stage of the FOS Engine startup. Then assign this new init_asus.xz to those systems that have this mobo installed. Its not the cleanest solution but then at least you could automate system imaging with this kind of mobo. If you know what needs to be done the actual update will take you about 15 minutes to copy and modify a new init.xz and push it out to these clients settings in the FOG gui.

      [edit] changed "15 minutes to create a new init.xz " to "15 minutes to copy and modify a new init.xz " to give a better understanding of what must be done.

      posted in Hardware Compatibility
      george1421G
      george1421
    • RE: Running a storage node as an independent pxe/tftp server at remote location

      First let me say that if you are using FOG 1.3.0-RCx servers then the storage nodes includes the bits (tftp, pxe) to support this. If you are using 1.2.0 then you have some manual work to get these services installed.

      You only need dnsmasq when your dhcp server can’t supply the dhcp options 66 and 67 for pxe booting. Adding in dnsmasq adds a bit of complexity but it is manageable.

      Yes in your example above this is totally possible. You will have your remote dhcp servers point dhcp options 66 and 67 toward your storage nodes at the remote locations.

      You will also need to use the location plugin so that you can direct the target computes towards their local storage node. You will create one storage group and then place the FOG server in that storage group as a master node and then add the remote storage nodes to that same storage group. This will then start the images and snapins replicating right away.

      posted in General
      george1421G
      george1421
    • RE: Dnsmasq bios and uefi

      @Wayne-Workman Considering what is currently being packaged with modern linux distributions is dnsmasq 2.72 (Sep 2014) is over two years old, its about time they did drop the old syslinux syntax requirements. One of many improvements I’ve seen so far.

      [edit] Just reviewing the change log for 2.76 this jumps out in regards to file names:

      
      	    Subtle change in the semantics of "basename" in
      	    --pxe-service. The historical behaviour has always been
      	    that the actual filename downloaded from the TFTP server
      	    is <basename>.<layer> where <layer> is an integer which
      	    corresponds to the layer parameter supplied by the client.
      	    It's not clear what the function of the "layer" 
      	    actually is in the PXE protocol, and in practise layer 
      	    is always zero, so the filename is <basename>.0
      	    The new behaviour is the same as the old, except when
      	    <basename> includes a file suffix, in which case
      	    the layer suffix is no longer added. This allows
      	    sensible suffices to be used, rather then the
      	    meaningless ".0". Only in the unlikely event that you
      	    have a config with a basename which already has a
      	    suffix, is this an incompatible change, since the file
      	    downloaded will change from name.suffix.0 to just 
      	    name.suffix
      
      posted in General
      george1421G
      george1421
    • RE: DNSMasq Setup - No Boot Filename

      @dholtz-docbox said in DNSMasq Setup - No Boot Filename:

      I was in sync with what you were saying until here

      where DNS is handled by the route

      I assume you meant that DHCP is now handled by your router.

      If you are installing dnsmasq on your FOG server then all you need to do is install dnsmasq and ensure it starts upon reboot then update/create /etc/dnsmasq.d/ltsp.conf then restart dnsmasq. That is all.
      As long as your dhcp server, fog server, and target computers are on the same subnet it will just work. If your target computers are on a different subnet than your dhcp server and FOG server then there are a few more things you need to do.

      I do have a tutorial on how to set dnsmasq up under Centos with an example config file you can use.
      https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

      As part of installing fog you should have already disabled the firewall on the fog server as well as set selinux to disable.

      posted in Linux Problems
      george1421G
      george1421
    • RE: Dnsmasq bios and uefi

      I started doing a bit more reverse engineering on what these bits of the dnsmasq configuration was actually doing.

      If you turn off this section of the dnsmasq config, that also disabled udp port 4011 (dhcpProxy).

      # PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
      pxe-prompt="Press F8 for boot menu", 10
      
      # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
      # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
      # This option is first and will be the default if there is no input from the user.
      # PXEClient:Arch:00000
      pxe-service=X86PC, "Boot BIOS PXE", undionly
      # PXEClient:Arch:00007
      pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
      # PXEClient:Arch:00009
      pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi
      

      This causes the dhcp proxy function to fail and the device won’t boot.

      If you turn off this section

      
      dhcp-vendorclass=BIOS,PXEClient:Arch:00000
      dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
      dhcp-vendorclass=UEFI,PXEClient:Arch:00007
      dhcp-vendorclass=UEFI64,PXEClient:Arch:00009
      
      dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.112.24
      dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
      dhcp-boot=net:UEFI64,ipxe.efi,,192.168.112.24
      dhcp-boot=net:BIOS,undionly.kpxe,,192.168.112.24
      

      The dnsmasq server will not send out the file name in the initial dhcp offer request. Which I found doesn’t matter. I could send out one name for the dhcp offer and another name in the proxy section. The proxy section always won. So in my current config I have the vendor class stuff turned off since it was not impacting what actually was downloaded from the tftp server.

      pxe-prompt="Boot to FOG iPXE", 1
      pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
      pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
      pxe-service=X86-64_EFI, "Boot UEFI PXE-64", snp.efi
      

      So this is what I have for the part that actually sends the file to the booting client. I also discovered in the new version of dnsmasq that it doesn’t automatically append .0 to the file name, what ever the name is listed above is what is requested from the tftp server.

      In the pxe-service line. The first value correlates to the Architecture Type in this document: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#General

      By creating unique pxe-service lines your dnsmasq server will send out the proper boot file based on the transmitted architecture type in the dhcp request. So far in testing with the 6230 undionly.kpxe is sent in bios mode and ipxe.efi is sent in uefi mode. I’m still hitting a wall in uefi mode where it initializes devices for about 5 minutes then reboots. But the right iPXE kernel is being sent to the target computer. I checked and the bios is old (A11) vs current A15. I’m going to update the firmware after a bit to see if that is what is causing iPXE to not init right. I can say it works flawlessly in bios mode.

      posted in General
      george1421G
      george1421
    • RE: Fog update

      This goes hand in hand with Joe’s question.

      If you are using Ubuntu LTS 14.04 or 16.04 then the path is here: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk if you are running anything before 14.04 you are better off to spin up a new ubuntu server with one of the stated (and supported) OS versions.

      posted in FOG Problems
      george1421G
      george1421
    • RE: Recommended guide for Windows 10 image creation (from scratch) ?

      @Scott-Adams My script essentially is the same as your except I have an array of applications that I look through and remove but they heart of the script does the same as your script does. The only difference is I’m not doing it in audit mode (if that matters).

      posted in Windows Problems
      george1421G
      george1421
    • RE: Recommended guide for Windows 10 image creation (from scratch) ?

      @MRCUR said in Recommended guide for Windows 10 image creation (from scratch) ?:

      @george1421 If you use WSUS then updates will not force themselves on the machines unless you approve them. The “Windows Update for Business” stuff only applies to non-WSUS deployments where you’re controlling Windows Update only with group policy and no WSUS.

      FWIW: There are documented “bugs” with CBB 1607 where windows updates will hang applying them. This happens with images being built in MDT as well as images already in production. The late September cume update kb3193494 as well as setting the DeliveryOptimization registry key fixed the MDT / WSUS deployment issues with image creation. I suspect that kb3193494 will also address the 1607 systems in the wild too, but we don’t have any as of now. Which will be interesting since wsus is broken so the only way to deploy that update is via some alternate methods.

      posted in Windows Problems
      george1421G
      george1421
    • RE: UEFI won boot tools via fog menu.

      @dureal99d I’ve kind of lost where this thread is going.

      Lets recap. You are using dnsmasq on dd-wrt to supply the missing bits needed to pxe boot a target computer in uefi mode. (I haven’t looked) but doesn’t dd-wrt use isc dhcp server? If so then dnsmasq is not required, since isc dhcp is all you need. There is a FOG wiki page on how to set it up. https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

      Can you pxe boot a target computer into the fog ipxe menu and capture or deploy an image. If this doesn’t work then we need to understand what is going sideways. Beyond that if you are trying to pxe boot random applications not delivered with FOG then those need to be addressed. But we need to make a clear distinction is this a FOG issue or third party application issue.

      posted in FOG Problems
      george1421G
      george1421
    • RE: Dnsmasq bios and uefi

      @Sebastian-Roth I also saw that too (dhcp server sending out the next-server). The main dhcp server (Linksys WRT54GS, yes I know its old but it is a nice friend) is sending out the next-server pointing to itself. I thought this was strange since there is no option to change/set this in the wrt54’s firmware. I could reflash it with DD-WRT but it hasn’t been a problem until now.

      As for the 6230 hanging. If I remember right that series was the first to fully support network pxe booting in uefi mode. I need to check to see if there is a firmware update for that. I also plan on building an ipxe usb boot disk to check to see if its the ipxe kernel or something else. The last bit is I might try the old ipxe kernel that Tom added back into fog, the one for getting the Surface Pros to boot. I think my issue is with ipxe and not dhcp/dnsmasq at this time since the ipxe kernel is making it to the target computer.

      posted in General
      george1421G
      george1421
    • RE: UEFI won boot tools via fog menu.

      @Wayne-Workman With the libraries mentioned I can get really close to the distro had, except for one module that didn’t seem to impact ipxe booting. But your idea of updating the wiki pages for dnsmasq is not a bad idea. I sure would like to get a solid boot before updating anything, but the key was to use dnsmasq 2.76 and the updated config to get it to boot anyway.

      posted in FOG Problems
      george1421G
      george1421
    • RE: Dnsmasq bios and uefi

      Here is a pcap of the proper UEFI PXE boot. This was captured from the FOG-Pi server perspective.

      0_1475453397643_uefi_pxe_boot.pcap

      While I haven’t been able to get into the iPXE boot menu as of now, I can say that the dnsmasq part appears to be working since the iPXE kernel makes it to the target. But right now the iPXE kernel tries to initialize the devices for about 5 minutes then reboots the computer. I still need to dig into that but so far its taken me 4 hours to get this far so enough for tonight.

      posted in General
      george1421G
      george1421
    • RE: UEFI won boot tools via fog menu.

      @dureal99d I started another thread where I’ve been documenting my travels with dnsmasq and uefi here: https://forums.fogproject.org/topic/8677/dnsmasq-bios-and-uefi

      My config is pretty close. I can pxe boot a uefi system. Right now its hanging on the iPXE kernel initializing devices… But I did have to compile the latest dnsmasq program because the one for my distribution did not work even with the updated config file.

      Looking at your config file I would have to say you need to update this line:
      dhcp-boot=tag:efi-x86_64,ipxe.efi

      to this:
      dhcp-boot=tag:efi-x86_64,ipxe.efi,,192.168.1.109

      Just like you did for the bios undionly line.

      posted in FOG Problems
      george1421G
      george1421
    • RE: UEFI won boot tools via fog menu.

      @dureal99d Interesting because in the picture its thinks your fog server is 192.168.1.1 because that is where its trying to load the default.ipxe file from. I can’t remember off the top of my head where that setting comes from, its either from FOG or the next-server value from dhcp.

      posted in FOG Problems
      george1421G
      george1421
    • RE: Dnsmasq bios and uefi

      Being the daring person I am,. I downloaded the source code for dnsmasq 2.76 to the Raspberry Pi. I checked and gcc was installed so I “thought” I was good to go. I compiled and installed dnsmasq 2.76. Everything went great until I tried to restart the dnsmasq service. The start command responded with an illegal command switch was used to launch the application. There was not indication to what or why just it wasn’t going to start.

      After doing a bunch of digging and reverse engineering I found that a few options needed to be defined in the src/config.h file. More precisely.

      #define HAVE_DBUS
      #define HAVE_IDN
      #define HAVE_CONNTRACK
      #define HAVE_DNSSEC
      

      As well as some required libraries:

      sudo apt-get update
      sudo apt-get install -y libdbus-1-dev libnetfilter-conntrack-dev libidn11-dev nettle-dev libval-dev dnssec-tools
      

      Once everything was in place I ran the following command again:
      sudo make install

      then
      sudo service dnsmasq restart

      I started wireshark again and pxe booted the target laptop. This time I saw the dhcp discover, offer from both the router and the dnsmasq server, then dhcp request and finally the dhcp ack from the router. !! On the client it had booted to the point the iPXE kernel was initializing devices. (!!)

      The rest of the settings didn’t change all I did for this pass is upgrade dnsmasq from 2.72 to 2.76 (the version reported to work with uefi firmware).

      posted in General
      george1421G
      george1421
    • 1
    • 2
    • 640
    • 641
    • 642
    • 643
    • 644
    • 767
    • 768
    • 642 / 768