@Kleber I guess the spacing of the information printed is not working as intended when the status bar is just started. I played with the stuff a bit and came up with an easy solution that would expand the text information to the whole width but restrict the green status bar to the lower part:

statusbar.jpg

Would that be a feasible option? If not then some else with more status bar skill needs to look into this.

@premier Turns out this was a bug in the code. This is now fixed in latest dev-branch version. With the new official release on the door step your should update to 1.5.10 as soon as it’s out.

PS: If you’d kept up the topic and offered more information we might have been able to fix this way earlier.

Hi @Sebastian-Roth,
Yes, I think that the dev-branch solves the problem. I tried to install from master branch and the problem with the xinetd appeared, but with the dev-branch apparently works fine

I know this is quite an old topic, but we ran across this on the latest version of fog and I wanted to share my solution.

What ended up working for me was to get into the database console with mysql -u root

I then selected the fog database use fog;

Then I listed out the tasks SELECT * FROM scheduledTasks;

In my case the most recent record had an stID of 13, so I dropped that row, which fixed the issue DELETE FROM scheduledTasks where stID = 13;. After that the scheduled tasks menu loads fine.

@H3Krn Thanks for checking up in this. I’ve got it on my list but don’t seem to find the time.

@rodluz Do you want to take a look at this?

Thanks everyone for the comments on this. Looks like we better remove “Delete a host” and “Approve a Host” from the iPXE menu altogether.

With the “Update a product key” I see different opinions. While I understand your point @Tom-Elliott I am wondering if people actually use this at all because typing a 25 character key right at the machine is not much convenient. But on the other hand I think adding the security check should be enough to prevent from malicious/anonymous user inputs which @george1421 mentioned. I tend to leave that option in the menu but secure it - and same for “Join a multicast session”.

@skyrider223 I just merged your pull request and opened a new issue to take care of removing the menu items as discussed. I added a list of code changes needed to the issue report already. Are you keen to look into this as well?

@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.