@Valer For the Storage Group/Storage Node issue, fog doesn’t delete anything when installing.

At most it may alter tables or swap data around but I don’t think that’s what happened here.

I do see it showing 12 storage groups, I don’t see your screen for storage nodes. I’ll see if I can replicate the problem there. Confusing why it shows 12 to 1 of 1 entry? A little strange

Refind needing being signed, makes sense. The Secureboot stuff we worked on was mostly concerned with the flow from IPXE -> Kernel, I didn’t think about the refind file. I’ll see if I can address that.

Can you tell me what schema version you’re on?

MariaDB [fog]> select * from schemaVersion; +-----+--------+ | vID | vValue | +-----+--------+ | 1 | 323 | +-----+--------+ 1 row in set (0.000 sec)

Is what you should see. 323 is the latest which injects that new Task item, that said if your machine is in legacy boot, (non-uefi) you won’t be presented with the menu.

If you can give me:

SELECT vValue FROM schemaVersion; SELECT pxeID, pxeName FROM pxeMenu ORDER BY pxeID;

@Cpasjuste

Thank you, I appreciate that. And yes, I did spend a lot of time on it.

I agree that it bypasses the official installer in order to make use of Docker environment variables; however, at this stage, I don’t believe that FOG is going to change so dramatically that it’ll break it often.

I will add that if this could get adopted as an official docker image, we could work with the FOG team to make sure nothing gets to pushed to the FOG code that would break the container until we can adjust the container as well.

@Tom-Elliott said in Wiping Drive via PXE menu:

@vanfifty1 Sweet so it is functional and seems to be much more verbose about the actions it’s performing, thank you!

Thank you!

With the experimental init.xz when it said the following in my case: “Erasing /dev/nvme0n1 with an NVMe sanitize block erase (sanact 2)” does this mean the following command was run?: nvme sanitize /dev/nvme0n1 -a 2

Does this mean the bug is patched? Should I use the experimental init.xz file on the production FOG server? What ramifications will this have? Is it better to wait until this is released in an official version down the road?

@Alun Thank you and added to documentation and within the installer to try to more cleanly account for this.

@Tom-Elliott

Ah man that’s exactly what I needed. Thanks so much sir!

@hariskar

I didn’t really catch the described use case…
But anyway, if application stores something in the database, then the database need to be backed up, of course. Fully and incrementally also (separate logic).

If you use application that stores data in the same machine where it is installed, better would be to configure it to store data on the remote database, e.g on specific database server or some other way.
You can create network drive or other remote storage and point your database files there - if needed to be separate (for each PC).

This way you have all the data in the same place, and you can make backups of this server or drive more easilly.

Backuping entire PC with database in it - this can be done, but why?
It feels strange.

Example:
Lets say, employees in your company are working with important documents.
Do you really want to backup of entire PC (with os and applications and data), instead of storing those documents on secure and reliable remote storage?
Better solution is to simply make network location (local or in cloud) and let the users to store documents there - so the documents would not be lost if some pc dies.
If PC dies, then you simply replace the pc and deploy ready to use system image.

@trent_potter Yes you figured it out. Sysprep is a Windows utility, it has nothing to do with FOG. It is always recommended to sysprep before capturing an image.

In Reports Menu, Imaging Log You will find this information.

@george1421 I have installed fog with DHCP server but DNS doesn’t work at all (no dns server appear on windows client) so I’m stuck.
It’s my first time installing DHCP and DNS on Debian so I think I made mistakes.
DHCP work fine.

edit : It’s fixed. I forgot to add “option domain-name” and “option domain-name-servers” in dhcpd.conf

For the script, I think it must be simple to set FOG as DHCP server at startup if after 10 min no IP is given from a DHCP server then set server to static IP and start DHCP and DNS services.
And then reverse this at shutdown.
Maybe this can be done manually first.

edit : Here is the first script.
I have create files ending with .dhcp for conf for external DHCP/DNS and file ending with .static for conf for local DHCP/DNS.
It looks to work fine.

# Configuration actuelle echo "Etat DNS local :" systemctl is-active bind9 echo "Etat DHCP local :" systemctl is-active isc-dhcp-server echo "" loc(){ # Configuration DHCP local echo "DHCP local" # Configuration if [ -e /etc/network/interfaces.static ] then echo "Copie interfaces" cp /etc/network/interfaces.static /etc/network/interfaces else echo "interfaces.static not found" exit 1 fi echo "Redemarrage service reseau" systemctl restart networking.service if [ -e /etc/resolv.conf.static ] then echo "Copie resolv.conf" cp /etc/resolv.conf.static /etc/resolv.conf else echo "resolv.conf.static not found" exit 1 fi # Services systemctl start bind9 systemctl start isc-dhcp-server } ext(){ # Configuration DHCP externe echo "DHCP externe" # Configuration if [ -e /etc/network/interfaces.dhcp ] then echo "Copie interfaces" cp /etc/network/interfaces.dhcp /etc/network/interfaces else echo "interfaces.dhcp not found" exit 1 fi echo "Redemarrage service reseau" systemctl restart networking.service if [ -e /etc/resolv.conf.dhcp ] then echo "Copie resolv.conf" cp /etc/resolv.conf.dhcp /etc/resolv.conf else echo "resolv.conf.dhcp not found" exit 1 fi # Services systemctl stop bind9 systemctl stop isc-dhcp-server } # Demande de Configuration while true; do read -p "Voulez vous passer en DHCP externe ou en DHCP local? (e:externe l:local) " el case $el in [Ee]* ) ext; break;; [Ll]* ) loc; break;; * ) echo "Please answer yes or no.";; esac done

Finally, I did my update.

The problem was that I was running Debian Buster, so I first had to upgrade to Debian Bullseye so that the installer could install the new packages.

Then, I made a copy of the fogproject/ folder, deleted the folder to initiate a git clone
Next, I followed the tutorial and restarted the installer, which restored my old settings. The web interface is working, so I assume my clones will work as well.
Thank you.

@Hojjati I’ve found a solution for this issue that worked for me.
You need to manually edit the Windows hosts file at C:\Windows\System32\drivers\etc\hosts and add an entry with your FOG server’s IP address followed by the name “fogserver”.

This is necessary because SmartInstaller.exe performs a pinning process during installation, if you notice the installer hangs or fails exactly at that pinning stage, it is definitely due to this resolution issue.

Adding the entry ensures the installer recognizes the server and can download the certificate properly.

I’m going around replying to all these old Docker request threads so people can try out my work. Check out my thread here:

https://forums.fogproject.org/topic/18000/unofficial-docker-image-beta

and provide feedback in the comments.

the actual github repo is here:

https://github.com/88fingerslukee/fog-docker

Finally found out why I couldn’t auth over 636, I needed to add my domain’s CA cert to the FOG server’s root cert store. Once I did that I can now use my AD creds over 636 on the web UI and iPXE menu items.

@george1421 Thanks, George.