@Sebastian-Roth Just an FYI, I ran into this again on different hardware. An HP Z2 G4 Workstation did the same thing.
There may have been more to it though, still troubleshooting a bit. My failsafe in the postdownload script to have it still join the domain through the unattend file was injected into the file, but the computer did not join the domain through that method, there may have been a different reason for that though.

Point being, there could be other hardware that weirdly doesn’t get all the variables. I sadly can’t super test on this hardware as I discovered it when imaging a production machine that I can’t take out of production for testing. But I can probably find a chance to get the fos level device info or something.

@pep Finally found some time to properly document this issue on github.

Update issue: https://github.com/FOGProject/fogproject/issues/561
Snapin issue: https://github.com/FOGProject/fogproject/issues/562

Both should be fixed in latest dev-banch. The later still needs some good testing. I just did a very basic test to make sure the default schema is being applied.

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