@bmick10 said in Updating Fog to newer version and Pending Mac Addresses:

just wondering if it is always something that breaks locally or if things can be affected by developers or fog employees.

We aren’t employees, FOG is supported entirely by a community of volunteers that help out at their own discretion, of their own accord. There’s no money involved besides donations - which are never expected but always appreciated. You can help out too, just by answering questions you can answer or writing tutorials or documentation, videos, etc. You’ll find that you will learn a ton just by reading the stuff that’s posted here.

As for if things are affected or not by the devs - if you re-run the fog installer, it would get the latest kernel and init in order to support the latest hardware - but no web-core changes or DB changes are made unless you actually go get the latest version of FOG. As for your OS, when you re-run the installer it makes sure it has the latest version of the packages it needs, everything else is left unchanged. Ubuntu is notorious for resetting customized configuration files during updates, which in turn cause problems - this is of course compounded because Ubuntu by default automatically updates and most people aren’t knowledgeable enough about Linux to rip out that functionality.

@george1421 I’ll do some more testing Monday and get back with the results.

Thank you for your answers.

@FredG Sure we could go with a list of lables but what bugs me is that lables are just kind of like a sticky note. Very much volatile and therefor I don’t think it’s worth the effort to add this to FOG. I would like to come up with a more reliable / robust way of actually detecting if a partition is system or recovery or …

Thanks George and Wayne - I’ll submit my request for wiki account now.

@dpotesta50 (snarky: I did amend my original post to reduce the snark level).

The unattend.xml and setupcomplete.cmd files are something created by your previous admin to tweak your windows 10 build post image deployment with company/site specific settings. You may want to review these files to understand why he felt the need to do this. I can tell you its common practice to use the unattend.xml and setupcomplete.cmd files. So the short answer is yes you may need them.

If you don’t have them, and your previous admin used them, I can tell you how to collect them (assuming they are in your master image today). Take a computer and deploy your standard image to it, when FOG is done, power off the computer. Take the hard drive out and add it as a second drive temporarily in another computer. This will give you access to the media to collect these files.

“default” is not used.

And I say again, FOG doesn’t do this natively. How you configure your machines is how you configure them. FOG Just captures a replica of the hard drive. It will deploy that replica to many other systems.

@george1421 said in Passing host variable to iPXE menu:

@sebastian-roth I don’t think this is possible here. I think we have the chicken and egg situation here. dhcp knows about the computer’s name because the client tells it during dhcp negotiations. In this case, the client is a new born and doesn’t know enough to tell the dhcp server its name. To get it to work correctly the OP may have to setup dhcp reservations to inform the dhcp server what the client associated with mac address xxxx is.

Exactly this. We should used to furnish boxes with the hostname through DHCP (using option 012) but it requires manually configuring reservations.

Thank you guys, I will try these steps, I’ll keep you updated if anything happens

Thanks

@guyincognito said in Use QNAP NAS as source to multicast to clients:

I don’t think I want to try running the whole fog-server on the nas, I would be too scared if something brakes after updating the NAS-Software for example. A dedicated fog-server seems to be more practicable.

I agree 100% with this comment.

You can set kernel parameters on a global basis (as you found). You can also set kernel parameters on a per-host basis too (I assume it also applies to FOG groups). So only host will know about shutting down after imaging (or any time bzImage is transferred to the target computer).

BUT I think your quest has merit as a feature request. (in my non-programmer opinion) There should be an option on the setup page for multicast to shutdown after imaging, just like there is for a unicast image. I can see value in having that part of the core function of FOG.

@bricktop135 Though George is right about the USB key setup to boot Macs (and other machines) this is not the perfect way since it has issues.

Depending on the Mac you have you should be able to boot iPXE directly from a USB key (slightly different to what George posted). From what I read between the lines you have PXE settings in your DHCP server already or you wouldn’t have been able to PXE boot the windows PCs for imaging. Or did you use George’s USB key manual for the windows clients as well?

So back to the “other” USB key method. Simply format a USB key with FAT32 and create directories \EFI\Boot\ on it. Then copy ipxe.efi (found in /tftpboot on your FOG server) into that sub-directory on the USB key and name it bootx64.efi. So you end up with a single file on that USB key: \EFI\Boot\bootx64.efi

Plug in the USB key, fire up your Mac and hold down ALT on the keyboard. You should see several boot entries. Select the orange one called “EFIBoot” and see if you get to the FOG menu.

Please take a picture in case you hit an error and post here so we can have a look.

@tom-elliott 😄
It works perfectly now

Problem: image task not going to completion, getting error
could not complete tasking /bin/fog.upload
on host

Solution: configure password - fog user account, tftp in fog settings and storage node - to match that in .fogsettings file
https://forums.fogproject.org/topic/10892/could-not-complete-tasking-bin-fog-upload/2
AND configure SELinux policy (CentOS/Red Hat)
To make it permissive all the time:
https://wiki.fogproject.org/wiki/index.php?title=Fedora_25_Server#Continue_pre-config
Particularly the two lines dealing with SELinux.

Since I don’t currently have any important work to do while at work…

Inkscape. Newer versions have a MSI file. Should be very easy to make a Snapin with.
Download link: https://inkscape.org/en/gallery/item/11263/inkscape-0.92.2-x64.msi

LanSchool. No idea what this is, but it does offer silent installation options so you should be able to script something.
https://helpdesk.stone-ware.com/portal/kb/articles/install-uninstall-lanschool-via-the-command-line-cmd
https://helpdesk.stone-ware.com/portal/kb/articles/scripting-or-mass-deploy-switches-for-lanschool-install

Scratch 1.4. Use the msi file available here. It has an ini file with it, so upload the entire zip file as a SnapinPack and choose the msi template.
http://download.scratch.mit.edu/Scratch1.4.msi.installer.zip

Scratch 2. Already showed you that one, but there are newer versions available.
https://scratch.mit.edu/download

@loktar said in Have some problems with dban:

I still cannot list x.x.x.x/dban For some reason. It still redirects.

That’s ok. Just the way our redirecting works right now. It’s on my list to fix but … can’t do it all at once. But you should be able to access the file through URL directly. Just no directory listing possible!

Great you got it working now. Marking this solved.

@wayne-workman Nothing is wrong with Debian. I use UbuntuStudio16.04 as my FOG server OS at my work. I was just asking the question to see if it would work for my home setup.

Thanks,
Reuben

@joe-schmitt Perfect ! 😉

@tian said in finally switched from 0.32 to 1.4.4:

when all computers are starting simultaneously there are more deploying at the same time than allowed in the storage node’s “max clients” option: e.g. 13 are allowed and it has been 14 to 16 for the first deploy batch of a room, the later computers normally will start when it is below 13 again but it can happen that 2 will start at the same time again (depending on the moment they try to check in I think) and it might be 12->14 again

That’s a known problem - it’s caused by a race condition. It is a minor problem since everything still works and sort-of stays within the boundaries.

@jackiejack said in Could not complete tasking /bin/fog.upload:

That long string in .configure file is the password?

Yes that is the password and not the hash. The password for the linux user fog should have never been password. That is the default password for the web gui admin called fog yes I know its confusing. I really wish the developers long time ago would have change one of them to something different to avoid the confusion.