Developers

For anyone running into this. We’ve just pushed some changes to dev-branch and working-1.6 to make updating from Debian 9 to 10 easier. You should not be able to do this following the steps outlined here:

sudo -i
apt-get update && apt-get upgrade
apt-get dist-upgrade
reboot
sed -i 's/stretch/buster/g' /etc/apt/sources.list
apt-get update && apt-get upgrade
apt-get dist-upgrade
reboot
apt-get --purge autoremove
cat /etc/debian_release

cd fogproject
git checkout dev-branch
git pull
cd bin
./installfog.sh

@marted Just want to keep this topic up as it might be very helpful for others. Not sure if you have time and access to systems right now though.

@alansopro Somehow lost track of this and forgot about it, sorry! Now that I am starting to tackle this I see that it’s not as simple as I’d hoped. In a basic setup (single FOG server, no storage node, clean install, no plugins, unicast deploy) I don’t see the issue as described. So we need some more details of your setup:

• What does your storage setup look like, what nodes do you have?
• Any plugins you have enabled?
• When this happened, did you do a unicast or multicast deploy?

As well I may ask you to do DB maintenance and try forcing a deploy task again. Just to make sure we are not hunting down a dead rabbit.

I’ve already looked at the “force task” code and I have to say that I can imagine something can go wrong here if a plugin goes astray.

@astrugatch @Kiweegie Looking at this topic again after a while I am wondering if we’d just use a simple redirect as mentioned before. I just tested adding the following line in FOG’s apache config:

RedirectMatch "^/$" "/fog/"

Fairly straight forward and I would hope this doesn’t cause issues for existing installs. Though I am not exactly sure as many people use their FOG server for booting Live distros and we don’t know for sure how they setup it up. But the rule is very distinct and shouldn’t cause problems I would think. Except if you use the apache webserver to serve another website on that same server.

@kstrout Well then check out the EXIT TYPE setting for this host. Play with the different settings.

Some particular hardware has issues with chainloading to disk. Please let us know which Lenovo desktop you actually have. Chances are good other users in the forum have the same hardware and can share their knowledge on this.

As well we need to know if the Lenovo is set to UEFI or legacy BIOS?

@dirtysoc Thanks for posting. This is fixed in dev-branch already. As well we have fixed another issue on Raspbian Buster in dev-branch (compiling udpcast).

Both fixes will be in the next release.

@dirtysoc Good news, this is a known issue with VirtualBox. Switch to ipxe.pxe boot file and the issue will be gone.

@jc35 Got around to hopefully get this fixed. Before officially releasing it we need more testing. Please download https://github.com/FOGProject/fog-client/releases/download/0.11.19/SmartInstaller_Linux_stop_hang_fixed.exe and test on your Ubuntu 18.04 install. I have tested on pre-20.04 myself and therefore don’t have a clue if this updated fog-client will run in Ubuntu 18.04 using .Net 4.5.2 now. Please give it a try and let us know.

@eseo-fcolas Unfortunately the fog-client as it is right now doesn’t work in Ubuntu and Windows on the same host because it was not created with that feature in mind. It will take some major work to fix this.

For your example: Snapins itself are not bound to the OS. So if your hosts boots Windows it will still try to execute the snapin but fail due to it not being able to install the Linux Chrome package on Windows and therefore drop the snapin task.

Thanks for bringing this up. This is something we should be able to prevent from in the fog-client with less amount of work than the issue mentioned above. I will take a look at this over the weekend.

@kstrout Thanks for posting the video! What we see here is that the iPXE FOG menu is set to be hidden and therefore it seems to use the default menu item - chainloading from the local hard drive instead of showing the menu.

Now if you schedule a deploy task for this particular client I am fairly sure it will actually do the deployment. If you think you have scheduled a deploy task for this host already, then take a look at the Active Tasks list to check.