FOG Problems

• S

  No Subnet Declaration for virbr0 After Upgrade to 1.5.9
  • SCavender

  11
  0
  Votes
  11
  Posts
  31
  Views

  S

  @sebastian-roth Ahh, I didn’t see that either. Okay, so in DHCP I changed the router to 192.168.22.1 and range starting IP to .20

  In fogsettings, I changed both routeraddress and plain router from 192.168.22.11 to 22.1

  The test client gets online just fine now.

  Thank you again, Sebastian!

• M

  Fog installation failed
  • mesaman0182

  5
  0
  Votes
  5
  Posts
  24
  Views

  S

  @mesaman0182 Thanks to @Tom-Elliott this is fixed in dev-branch. So if you want to install FOG on Ubuntu 21.04 you just need to use the latest dev-branch version from github.

• A

  Schedule Delayed Deployment is not working anymore
  • Aquadt

  6
  0
  Votes
  6
  Posts
  1343
  Views

  S

  @john3892 Best if you open a new topic. Just cross link this forum post here as reference and then send all your details like FOG version, Linux OS/version, steps you took (in detail)…

• B

  Stop FOG from rebooting after registering host
  • b_man

  4
  0
  Votes
  4
  Posts
  13
  Views

  B

  @george1421 That makes sense, thanks!

• R

  Error deploying an image on Dell Optiplex 7080
  • Rotoi

  11
  0
  Votes
  11
  Posts
  52
  Views

  

  @rotoi Are you still running fog 1.3.3? More specifically you updated the kernel to something more modern, but have you touched the init.xz file? FOG 1.3.3 doesn’t (shouldn’t fully) support NVMe drives. The NVMe protocol wasn’t created until much later than FOG 1.3.3. Its akin to trying to install Windows 95 on an 11th gen laptop. It would kind of work, but not really well.

• L

  Imaging/Debug menu stuck at downloading BzImage 0%
  • lcsmd

  2
  0
  Votes
  2
  Posts
  8
  Views

  

  @lcsmd I see it has you have 2 different issues at the moment.

  The mac address is changing between iPXE and FOS Linux. The image transfer stalling out loading bzImage (FOS Linux kernel).

  You are able to get iPXE to boot so your chromebook has an i86 compatible processor in it (in the era of ARM you always have to ask).

  Lets tackle the mac address thing first since hopefully that is the easiest. We have seen this in the past where the firmware bios has an option switch for “mac address pass through” This is where the laptop doesn’t have a physical network adapter, but contains a mac address for the physical adapter. The idea is that the built in mac address would overwrite what is in the USB dongle making the device have a unique mac address even if you are using a single dongle for all of your device. This is great and exactly what we would want in an ideal world. FOS Linux’s driver understands this pass through uefi request and honors it.

  The problem comes in at the iPXE level, its drivers are not as advanced as linux so it only sees the mac address of the dongle and not the pass through address built into the tablet.

• C

  IPXE / DHCP problem?
  • cf20corvuss

  3
  0
  Votes
  3
  Posts
  16
  Views

  

  @cf20corvuss Well lets think about this for a minute.

  The screen shot you provided looks like the fog ipxe boot loader. If it is we can then make a few assumptions. My hesitation ATM is that some hypervisor’s use iPXE as their pxe boot rom (Virtual box being one). If we work under the assumption that the screen shot shows the FOG iPXE boot loader we know this.

  The target computer can speak to the FOG server. We know then because the iPXE boot loader was sent by the FOG server and received by the PXE booting computer. The target computer is getting a dhcp address from some place AND that dhcp information told the client where to get the iPXE boot loader from. So we know that dhcp is working. We know that iPXE has the proper driver for the network card in the pxe booting computer because iPXE sees the mac address of the network adapter.

  Where we typically see this is with the network configuration where Spanning Tree is enabled but one of the fast spanning tree protocols are not used. Standard spanning tree will listen for a loop back interface for the first 27 seconds a link is active then start forwarding data. With imaging when the PXE ROM hands off control to iPXE, iPXE will reset the network interface causing the link to drop briefly as iPXE boots. Well this link briefly dropping causes the spanning tree counter to reset. So when the target computer is trying to get an IP address again, spanning tree is still listening for a loop back. By the time standard spanning tree starts forwarding data again, iPXE and FOG have already given up.

  You can test this in a physical world by putting a dumb unmanaged switch between the building network and the pxe booting computer. This unmanaged switch will keep the building switch from seeing the brief link drop. Most cheap switches do not support spanning tree. So its all good there.

  Now NAT and imaging do not go together with FOG. Everything needs to be bridged with real addresses for FOG imaging to work.

• J

  Issue with EFI through PFSense Firewall
  • jonhwood360

  18
  0
  Votes
  18
  Posts
  51
  Views

  J

  @george1421 said in Issue with EFI through PFSense Firewall:

  @jonhwood360 said in Issue with EFI through PFSense Firewall:

  so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

  Well lets think about this for a minute. When I looked at the packet capture I did notice the lease times were different too.

  Looking at the config file you provided both the lease times and route address are set correctly. Why are we seeing a difference in the packet captures from the configuration. Its almost like we have a different dhcp server for bios than uefi. Or two instances running with different config files on the FOG server.

  Yep. The only thing I can figure is that somehow either the DHCP Relay or Arp Proxy in Pfsense is doing something weird, or the DHCP server is not processing my second range definition in its entirety (which is weird because booting into an OS proper, the exchange happens normally and gets the right settings).

  Although in the mean time I have had to move along in my research so I moved the DHCP/ Bind DNS to PFsense and have configured it to have the correct options. EFI boot from fog server is working in this new configuration. I am leaving the existing configuration in place on the fog server though to return to this issue (which I think has value to try and solve).

• D

  Certificate wrong server address
  • d2freak82

  5
  0
  Votes
  5
  Posts
  14
  Views

  D

  @sebastian-roth
  I was able to figure it out - when I made the vm that I took my image from my fog-server address was different as I installed it many times trying to get it to work.
  The machine I captured the image from had the fog-client pointed to the old server, once I removed the fog-client and reinstalled with the FQDN it did the trick.
  Thank you

• D

  Change webserver port?
  • DiscoNaut

  2
  0
  Votes
  2
  Posts
  13
  Views

  S

  @DiscoNaut While you surely can mess with the port in the Apache config I am fairly sure this will break some of FOG’s features like wake on LAN, snapins and maybe even PXE booting. Will definitely take some manual adjustments in files in the FOG server to get this somehow working.

  What’s your intend in doing this?

• B

  SOLVED Secureboot issues
  • bgbgbgbg

  15
  0
  Votes
  15
  Posts
  253
  Views

  A

  @lee-rowlett I would be very interested to see how this could be achieved. I have 1000 Lenovo devices and I would prefer to not have secure boot reconfigured on all machines…

• F

  iPXE menu error
  • fogman4

  4
  0
  Votes
  4
  Posts
  31
  Views

  

  @fogman4 This looks suspicious.

  choose --default os.Debian.10.9 Live via ftp --timeout 3000 target && goto ${target}

  The tag name should not have spaces. Looking at the actual menu item

  param sysuuid ${uuid} :os.Debian.10.9_Live_via_ftp kernel tftp://${fog-ip}/os/debian/vmlinuz initrd tftp://${fog-ip}/os/debian/initrd imgargs vmlinuz initrd=initrd boot=live components fetch=ftp://${fog-ip}/filesystem.squashfs

  I wonder if the underscores are breaking the default option.

  :os.Debian.10.9_Live_via_ftp

  They are translating to white space characters. Use dashes or dots in the tag name and see if that fixes it.

• S

  Kernel Update Transfer Failed
  • SCavender

  10
  0
  Votes
  10
  Posts
  23
  Views

  S

  @sebastian-roth The kernel update works now and image capture is successful.

  I’ll start a new topic on the networking issue.

  Thanks Sebastian!

• M

  check in failed - ignored null byte in input
  • Murphy

  6
  0
  Votes
  6
  Posts
  39
  Views

  

  @sebastian-roth or the web items are being compressed, but not decompressing for display.

• J

  Help in deleting image in fog server
  • jonathanho92

  4
  0
  Votes
  4
  Posts
  19
  Views

  S

  @jonathanho92 said in Help in deleting image in fog server:

  When i try to click delete they prompt me for credential i am not sure which credentials to key in to delete the image

  That’s the same credentials you use to login to the FOG web UI. It’s just a safety thing to prevent people from deleting image files in a rush.

• J

  Authentication URL
  • jbandy

  2
  0
  Votes
  2
  Posts
  8
  Views

  S

  @jbandy Edit C:\Program Files (x86)\FOG\settings.json on the client machine. Then restart the service called “FOGService” or the computer.

• J

  SSL Issue srvpublic.crt
  • jbandy

  10
  0
  Votes
  10
  Posts
  36
  Views

  S

  @jbandy said in SSL Issue srvpublic.crt:

  ... "GET /fog/management/other/ssl/srvpublic.crt HTTP/1.1" 302 631 "-"

  What we see in all those access log line is status code 302. So really, each and every request is not being answered directly but redirected.

  Maybe this is something special Ubuntu is doing to push SSL/HTTPS forward? I am not sure. To try and see where this is coming from we need to start digging through the apache configs. First post the contents of the file /etc/apache2/sites-available/001-fog.conf here in the forums.

  How do you change the url it’s using to communicate?

  Edit C:\Program Files (x86)\FOG\settings.json on the client machine. Then restart the service called “FOGService” or the computer.

• A

  Daily wake-up routine not working after update
  • altitudehack

  82
  0
  Votes
  82
  Posts
  213
  Views

  

  @altitudehack The clear current tasks run the following:

  truncate table powerManagement; truncate table scheduledTasks;

  This will restart both tables to ID of 1, but hopefully after this you will be good to go.

• P

  SOLVED Scheduled Wake On Lan
  • Petěrko

  17
  0
  Votes
  17
  Posts
  85
  Views

  P

  @tom-elliott
  @Sebastian-Roth

  Thank you all. It is solved now in 1.5.9.78 with HTTPS on.

  /var/log/apache2/other_vhosts_access.log

  80 "POST /fog/management/index.php?node=client&sub=wakeEmUp HTTP/1.1" 302 599 443 "GET //fog/management/index.php?node=client&sub=wakeEmUp HTTP/1.1" 200 9111 443 "POST /fog/management/index.php?node=client&sub=wakeEmUp HTTP/1.1" 200 9111

  /opt/fog/log/fogscheduler.log for Power Management Task

  [04-29-21 6:16:25 am] * 1 task found. [04-29-21 6:16:25 am] * 0 scheduled task(s) to run. [04-29-21 6:16:25 am] * 1 power management task(s) to run. [04-29-21 6:16:25 am] * Power Management Task run time: Thu, 29 Apr 2021 06:16:00 +0000 [04-29-21 6:16:25 am] * This is a cron style task that should run at: 1619676960. [04-29-21 6:16:25 am] * Found a wake on lan task that should run. [04-29-21 6:16:25 am] | Task sent to fcaa-https

  /opt/fog/log/fogscheduler.log for Scheduled Task:

  [04-29-21 6:22:26 am] * 1 task found. [04-29-21 6:22:26 am] * 1 scheduled task(s) to run. [04-29-21 6:22:26 am] * 0 power management task(s) to run. [04-29-21 6:22:26 am] * Scheduled Task run time: Thu, 29 Apr 2021 06:22:00 +0000 [04-29-21 6:22:26 am] * This is a cron style task that should run at: 1619677320 [04-29-21 6:22:26 am] * Found a scheduled task that should run. [04-29-21 6:22:26 am] - Is a host based task. [04-29-21 6:22:26 am] - Unicaset task found! [04-29-21 6:22:26 am] - Host fcaa-https [04-29-21 6:22:26 am] - Task started for host fcaa-https!

  Thank you again! Now our school can wake-up on Schedule

  Peter

• K

  Replication oddity after moving Master node
  • Kiweegie

  15
  0
  Votes
  15
  Posts
  53
  Views

  K

  @tom-elliott So to clarify that last point Tom, the SQL should reflect under ngName both the Storage group name AND the Storage node name? DCSTORAGE in this case is the name of the Storage node master server for the Storage Group 3 storage group.

  I’ve compared to the other image(s) which are only hosted on (and are being replicated from) the Master node and they only reflect the main storage group under ngName.

  I’ve made note of the replicator service restart command, cheers. I went a bit neanderthal and just rebooted all my servers just now to see if that kicked things into life.

  Checking the Image Replicator logs under FOG Configuration > Log Viewer it only references DCMASTER and the 2 nodes in its storage group. Does replication from the Storage master of the other storage group show in these logs? Or do we need to check local log files on the server itself?

  cheers Tom