@george1421 Honestly, a better solution might be to use grub-reboot on startup in ubuntu. A bit hacky, but it’ll do

@p4cm4n There is a master imaging script that gets called when FOS Linux starts up its called simply fog https://github.com/FOGProject/fos/blob/fda59eca648af1a38ed57c94f65558221e77534f/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L1

At the beginning of that script on line 4 I added a long time ago the code for usb booting, in that the target computer would call back to the FOG server to get the kernel parameters. Normally iPXE would load the kernel parameters when fog imaging was requested. But with USB booting into FOS Linux there are no kernel parameters per se. So this code was added to the beginning of the master bash script.

if [[ $boottype == usb && ! -z $web ]]; then sysuuid=$(dmidecode -s system-uuid) sysuuid=${sysuuid,,} mac=$(getMACAddresses) curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac" "${web}service/hostinfo.php" -A '' [[ -f /tmp/hinfo.txt ]] && . /tmp/hinfo.txt fi

So specifically the curl calls back to the fog server to run a php file that loads the kernel parameters into /tmp/hinfo.txt then we stat or run that hinfo.txt file to load the kernel parameters into the bash variables. That was the trick to “rebooting” without actually restarting FOS Linux or the computer. Then after the variables were loaded I think I called fog.download directly.

If you look down that fog script a bit you will see the variables $mode and $type. After you load the kernel parameters you may need to unset $mode and set $type to “down” then call fog.download. That is what the script is checking for to know what fog module to call on each boot.

The trick is to call fog.download and not let the fog.man.reg exit, because when it does control will be returned to the main fog script and the target system will reboot.

@petec said in Hiren 1.0.2 PXE Boot:

initrd tftp://${fog-ip}/fog/hbcd/HBCD.iso
chain memdisk iso raw ||
boot || goto start

You have 2 problems here.

memdisk only works with BIOS computers. your iso has to fit inside a 32 bit address space. So the iso can’t be larger than 2GB in size (this also includes enough ram to run your OS too).

I have a tutorial here for hiren 1.0.1 here that might get you started: https://forums.fogproject.org/post/140212

@george1421 You helped a bunch my friend

i did some tweaking and now is works, here is the menu parameters for latest gparted:

kernel tftp://${fog-ip}/fog/gparted/live/vmlinuz
initrd tftp://${fog-ip}/fog/gparted/live/initrd.img
imgargs vmlinuz initrd=initrd.img boot=live config components union=overlay username=user noswap noeject vga=788 fetch=http://10.0.0.2/fog/filesystem.squashfs
boot || goto MENU

@anisgh Ok so lets follow that sysprep concept. The easiest solution is to not create the user when you build the golden image. I don’t use ubuntu so I don’t know if that’s an option. But lets say its not. So lets create a script called sysprep, and you would run that on your ubuntu golden image. Within that sysprep script you could execute a series of commands and then call a system shutdown (just like sysprep does). Now you need to decide what this sysprep script will do before shutting down ubuntu.

You might have it reset the hostname back to some generic name, and then remove the default added user with something like deluser --remove-home username The last thing you will need to setup is a first run script (akin to windows setupcomplete.cmd batch file) https://askubuntu.com/questions/156771/run-a-script-only-at-the-very-first-boot This will let you do some customization on first boot of the computer (like creating new use and such). You would do this with the unattend.xml file or the setupcomplete.cmd in windows anyway.

Now that you have the ubuntu image cleaned up shutdown the computer.

To extend this a bit more, in your post install script that renames the computer. You could access FOG fields like other1, other2, and (assigned user, don’t remember the actual field name). You use one of those fields to hold the name of the user account to create on the computer. You will write that user name to a text file that your first run script will find and create the user. When you create the user account with a generic password (like Password-1) use this to expire the account so they would be forced to reset the password on first login passwd --expire <username>

The point is to use FOG to leave bread crumbs in the target system based on deployment time values, then use a first run script in the target OS to pickup the crumbs and do something with them. This is the same for windows as well as linux. While FOS is linux, its not the target system linux so it can’t do much more than leave bread crumbs behind for the target OS to find.

SOLVED!

Solved it by adding the line RewriteCond %{REQUEST_URI} !^/utils to the VirtualHost block at /etc/httpd/conf.d/fog.conf so it looks like this now:

<VirtualHost *:80> <FilesMatch "\.php$"> SetHandler "proxy:fcgi://127.0.0.1:9000/" </FilesMatch> ServerName 10.0.0.1 ServerAlias fog.servers.domain.io DocumentRoot /var/www/html/ RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] RewriteRule /management/other/ca.cert.der$ - [L] RewriteCond %{HTTPS} off RewriteCond %{REQUEST_URI} !^/utils RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L] </VirtualHost>

@george1421 hi and once again let me thank you for your time.
I just managed to get over the problem and disabled the HTTPS redirect for the /utils path.
SystemRescue loaded just fine.

I would suggest, maybe, adding this rule by default when we enable SSL on the fog server, and having therefor a specific path to put boot files that could be blocked by curl’s certificate check.

@bryan-wright said in Can't add snapin to group:

I was expecting the snapins to be attached to the group, but looking at this code in group.class.php, it appears that the snapins just get attached to each MEMBER of the group:

That is not a bug. That’s by design. Search the forums for “persistent groups” to understand that FOG’s concept of a group is not what you think it is. Groups are more or less a too to push settings to all the hosts being member of that group.

On the other hand I am running FOG 1.5.9 here and I do have the snapins listed when I go to Group -> Basic Tasks -> Advanced -> Single Snapin.

Your can find the full list of changes between 1.5.5 and 1.5.9 on github: https://github.com/fogproject/fogproject/compare/1.5.5..1.5.9

We can’t support or even fix older versions of FOG I am afraid. So please update to 1.5.9 and let us know if you still see the same issue.

@lambo Just wondering if you are still looking into that issue or got it solved at some point?

@sebastian-roth Yeahh, it works ! Thanks again !

@george1421 Okay sounds good. I am checking this page frequently so if you need more from me just let me know!

@george1421 mainly I wanted to select raid on so that if a laptop hass issues and looses bios settings it will still work 🙂

Example I have a couple of HP laptops that for some reason if left not being used for a couple of days they loose bios settings even if they have battery life :S

@Fog_Newb Notification loads for me in Firefox 95.0.

https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

@tom-elliott sweet! Thanks Tom!

@tesparza

I made the same thing with this doc : https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@kilua4650 Can you explain how this is related to FOG?

@doctrg Its always best to migrate same version to same version. The issue is the database since there has been many changes between 1.5.5 and 1.5.9.

On your new fog server go ahead and install 1.5.9, then bring over the 1.5.5 database and raw image files. The first time you attempt to access the web ui it should detect and older database and try to upgrade it. It will take you to the db upgrade page instead of taking you to the login page.

@lerne-nie-aus said in After Deployment - No Configuration Methods succeeded:

So tell me pls how i can solve this.
What you mean with cold startup?

I don’t know how to solve this with VirtalBox, I’ve only seen it before. The problem is specific to VB.

Warm boot == just restarting the OS without powering off the virtual machine.

Cold boot == is powering up the Virtual Machine from a switched off state.

I did find a reference to this in the FOG Forums: https://forums.fogproject.org/topic/9700/solved-unable-to-boot-fog-from-pxe-with-a-vm-virtualbox-guest

@sebastian-roth hey thanks for your quick Help.

With “Grub” Options in Host-Bios-Exit-Typ work all fine.

You are great.

@JJ-Fullmer I am sure you are incredibly busy. I was just wondering if you had a few minutes to help me out with the FOG API and changing inventory values?