@sebastian-roth Sorry, I didn’t see your answer. Yes it works.

@EduardoTSeoane And another old one I came across. This one is still an issue. I have dug through a lot of code today to try and properly fix this. While there are different ways of getting this right I didn’t want to mess with too much of the code and introduce new problems. In case anyone comes across this, feel free to look into it again and see if there is a better way.

Remove general encoding of HTML special chars (in FOGBase class) and add it where needed instead. This would be a lot of places (e.g. 1) because HTML output is generated throughout the code - so re-working pretty much all of that. As well this would also change the output we get from the API for example. Currently HTML encoded for no good reason I think. But changing that could break things for people being used to it. Another way would be to prevent the whole object from being saved in general when only associations should be set. This happens in many places as well (e.g. 2, 3). Same as above it would mean re-working a lot of the code. Although it’s probably worth it to reduce the amount of unnecessary changes being written to the database (improve performance a little). So I chose the simplest route of all to just fix this for snapins in dev-branch (4). It’s not perfect but at least the actual issue is fixed for snapins where chars like " and > are used by people. FOG still messes up those characters in other places, e.g. host/image description.

@EduardoTSeoane Just stumbled upon this topic. Got lost somehow…

I can’t replicate the issue as described in the latest dev-branch version (1.5.9.219 as of today).

I am pretty sure this was solved even before 1.5.9 was released: https://github.com/FOGProject/fogproject/commit/fffa0e2f3a1a0acab40670e53d1ffe054107b8c3

@kibade

My memory I really bad but IIRC I ended up having to upgrade to Ubuntu I was on 20.04 at the time

@jmeyer You can find more details on this in GitHub as well: https://github.com/FOGProject/fogproject/issues/424

I have found the answer - hostname was changed after next deploy operation. We can close the topic.

Thanks a lot,
@Sebastian-Roth !

Can confirm. In 1.5.9.159 Snapin update is working as expected.

Peter

@george1421 Let me try if it will create a conflict by using Location instead of Sites

@sebastian-roth Hi , Resume works but for example i create new topic, i didn’t receive when have a reply

@sebastian-roth Hi, just tested, works like a charm 🙂

@sgennadi Should be fixed now. Sorry for the issue. A kernel testing build got in the way.

Finally I found where the problem came from !

We are using a NAS Synology to share the printers drivers. It’s a share accessible without password (guest account enable on the NAS). We’ve got no access problem to this share at anytime.
This NAS is joined to the domain… And here is the problem !

As soos as we unjoined the NAS from the domain, FOG printers are pushed without problem.

I don’t know why but if you execute printui command as local system account when the drivers files are shared on a NAS member of a domain, there is an access error. If you try the same command as local Administrator, it works…

So unjoining the NAS from the domain was the solution.

@tatanas Well done!

@gn_ro Not exactly sure why you run into this issue but looking through the code and searching the web for this error message I might have an idea what’s going on. After the deployment (through partclone.dd in this case) FOS looks for any NTFS partition, tries to mount it and see if it can modify registry files to change the hostname of the machine (pre Windows boot up!). This feature is called “early hostname change” and can be turned off. In the FOG web UI go to FOG Configuration -> FOG Settings -> section General Settings -> uncheck CHANGE HOSTNAME EARLY and save settings.

Unfortunately this can only be turned on and off globally. Most people want to keep that turned on and so might you for most of your machines. But I think it’s appropriate for you to quickly turn it off whenever you need to deploy that special machine.

@sebastian-roth Thank you! I hope will help others too.

@colej Which version of FOG do you use?

@Afernandes Just updated the FOG kernels to 5.10.34 and included the firmware as requested. You can keep using the kernel George provided or update to the latest as you like.

@altitudehack Thanks and sorry for the long time it took. Finally found time to fix the issue and push to dev-branch. Please update to the latest.

@greg-plamondon Should be fixed in latest.

Thank you,

@sebastian-roth said in Fog 1.5.9.62 Location problems.:

@Greg-Plamondon Just pushed the fixed 1.5.9.63.

Awsome!
Appreciate your work!