@george1421

I used to see the issues with warm boots on older versions. That seems to not be the case in the latest version.

@astrugatch The link is in my signature. Testing is suspended by request of @Sebastian-Roth until the 20th of this month. The last test results can be seen on the site.

Thank you to all for your answers.

I think, i will use the safe approach : i will clone my existing Golden Win 7 image in Virtual Box.
With the cloned image, i will install Ubuntu with Grub and upload the new “Golden Dualboot Win7/Ubuntu image”.

In my ref image, i do … nothing 'cause all conf", softs and scripts are run at the post-deployement …

I will try this approach and “i will be back” with the results.

Thank you for “the right way” 😉

[Mod Note] duplicate post from here: https://forums.fogproject.org/topic/13807/error-update-database-after-capture-image

I guess I would have to ask you a question of what are you trying to accomplish by not having FOS Linux reboot after its done with imaging? What is your goal here?

I’m seeing the not registered static text here:
/var/www/html/fog/lib/hooks/bootitem.hook.php
/var/www/html/fog/lib/fog/bootmenu.class.php

I would look in the bootitem.hook.php first.

as well as in the language files in
/var/www/html/fog/management/languages/

Your dhcp server needs to send the boot file name ipxe.efi for uefi based systems and undionly.kpxe for bios based systems.

If this is just a one off system you can manage dhcp option 67 by hand. If you want it to automatically adjust based on the target computer there are instructions here as long as your dhcp server is windows 2012 or newer or linux based: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

As we have had so many requests about this topic I have tried to sort this out and properly fix it. Turned out to be quite hard but I hope I got it now without causing any other harm.

@Tom-Elliott Can you please take a look at this commit and let me know if something jumps at you that could cause us trouble. I mean I have tested things a bit but as I had to change code right in the FOGController class I am unsure about side effects this might cause. What do you think?

@TigerTran What Linux OS do you have? My guess is you have Ubuntu, right?

Did you read what is mentioned in the official release message? https://forums.fogproject.org/topic/13488/fog-1-5-7-officially-released

Please make sure you say NO if asked about removing and re-installing PHP and Apache when upgrading to 1.5.7 on Ubuntu!!! There is an issue within the installer trying to switch to MariaDB that causes a problem on Ubuntu installs otherwise. If you have such an issue see here: https://forums.fogproject.org/post/126476 and https://forums.fogproject.org/topic/13447/lost-database

@ITCC Let us know what exactly you are trying to achieve. The AD settings are meant to be used for domain join and from what you write I get the impression that you want to misuse “Name Change/AD Join Forced reboot” to forcefully log off people from their machines. Maybe this is just a misunderstanding on my side but you keep calling it “force logout” and therefore I get the impression.

There are other ways of doing this. The web is full of it:

https://answers.microsoft.com/en-us/windows/forum/windows_7-security/how-to-force-logoff-from-command-line/8e7507e0-12c8-4ac7-8d5e-a1917e4af997 (using shutdown /l /f command) https://social.technet.microsoft.com/Forums/en-US/1c525aa7-5b09-45fb-ad47-56c41f1df2bc/force-user-logoff?forum=win10itprogeneral (using GPOs)

If you can’t make it work this way you need to explain to us what exactly you want to do. We won’t change this otherwise!

Just as a side node: I have not really looked into what needs to be changed but I can imagine this being a change in the fog-client code as well. There are many other things that needs fixing before we’d get to change that in fog-client.

You are more than welcome to dig through the code yourself and implement the change. I am not saying it cannot be done.

@Wayne-Workman Sorry this has been without attention for a long time! Not only this topic but all the others:

https://forums.fogproject.org/topic/11868/how-to-change-colors-on-bandwidth-graph
https://forums.fogproject.org/topic/11999/bandwidth-line-colours
https://forums.fogproject.org/topic/6912/can-i-change-the-colors-of-the-tx-rx-graph

I played with the things mentioned in the other topics and figured that it seems to pick colors just by itself if we don’t force it to use our colors. When I remove the color scheme as described I get the following picture:

fog-bandwidth.jpg

Please vote if you find this appropriate. Sure the more nodes you have the less obvious distinct colors there are. But from it’s still better than using a successive shade of whatever color you start from.

I’ve tested this in three different browsers on a Linux machine. I would imagine this working nicely on Windows and Mac OS browsers as well. What do you think @Tom-Elliott?

@Sebastian-Roth said in Deploy one Linux Mint image to computers of different manufacturers?:

I am not sure if Mint does some fancy things like LVM partitioning, home partition encryption or similar stuff FOG cannot handle. Make sure you choose a simple plain partition layout when installing the master image machine and you should be fine.

My daily driver (not in the office) is a Linux Mint system (ubuntu based). It just has standard partitions not lvm.

As Sebastian said, you can get near windows like deployments with most linux distros if you want to do it manually through post install scripts or via the FOG client. I can say I’ve never used the fog client as part of a FOG linux deployment.

One other comment, I have a how-to on netbooting your favorite distros to where you can live boot linux mint on hardware without installing it first for testing purposes here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

Well, The cron syntax wouldn’t “disappear” unless your web front end translates the date/schedule to a Cron style system automatically.

Yes the idea should be possible, though I don’t know how best to help except to help provide basic syntax of the API so you can process and parse the data that’s returned.

I guess, though, I don’t fully understand the why. Everything (with exception of the scheduled cron tasks) is already available via the GUI we provide as a part of our software. “viewing said Scheduled tasks, view active tasks, and when a system is added to the host list that host will be added to the web page” are already done with the provided interface. Why create a new hen-house when the one you got with the land is also a hen house that does everything you need it to do.

@huatrongkhang Currently FOG is not able to deploy WIM images. But we are an Open Source Project and everyone is welcome to add features as needed. Can’t remember exactly but I think this has been discussed in the forums at some point already. Use the forum search.

@george1421 ok i Don’t Think about that. I Will do the corrections tomorrow. What about the rest of mounts?

Because the image is extracted and compressed it would be more than difficult to make that a live image where you can patch it and then reseal the image. It would be faster to deploy it to a VM patch and then recapture. But with this method you will run into a limit on the number of times you can sysprep an image. There are workarounds but its just one more hoop to jump through.

I can tell you how my company handles this (which may not be the best way for you), we use Microsoft’s Deployment Toolkit to build our reference image using the lite touch method. So every time we need to update the golden image we make the adjustments in MDT and then have MDT rebuild the golden image, we then sysprep it and capture with FOG. MDT gives us a consistent golden image each time we run the task sequence so we don’t need to validate the image each time its rebuilt. That single captured image is then deployed to our fleet of 14 different dell models. One image for all. (truth be told its 2 images for all, one is for bios based computers and the other is for uefi based computer. MDT builds them both the same way for us).

@george1421 @THEMCV Wiki is online again. Thanks for letting us know!

@astrugatch said in See last time a computer checked into FOG:

----------------------------------UserTracker--------------------------------- ------------------------------------------------------------------------------ 9/17/2019 3:06 PM Client-Info Client Version: 0.11.16 9/17/2019 3:06 PM Client-Info Client OS: Windows 9/17/2019 3:06 PM Client-Info Server Version: 1.5.7 9/17/2019 3:06 PM Middleware::Response Success ------------------------------------------------------------------------------

This is all perfectly fine - Response Success as you see.

@TammyTinkleToes90

It’s possible the previous admin scheduled a daily image deployment that contains a broken NIC driver. (check scheduled tasks)
The second possibility is a snapin that is done every day. (check snapins)

Check fog client hostname settings

Some devices have somewhat buggy UEFI firmware, especially with network boot. BIOS update might help.

Oh… I didnt even think about it that way. Especially that we have the “locked” state for the same purpose, prevent accidental deletion. Actually it is a double of the double protection. Not truly bad, but… strange design.