Posts made by Sebastian Roth

@badhonsoam Please post a picture of the error!

@brakcounty The latest dev-branch has some fixes but it’s not way ahead of 1.5.7 as of now. Still, the Ubuntu upgrade issue described is fixed already and a few other things.

See changes compared to the master branch (1.5.7 really) here: https://github.com/FOGProject/fogproject/compare/dev-branch

It would be great to have more people around actually running dev-branch to find issues earlier. So if you have a little bit of spare time to test things and like to use bleeding edge you are more than welcome.

I will try to be as responsive as possible in case you need help.

@chunter2 You are free to ask pretty much anything here but don’t expect a full answer. ;-)

Though you are using FOG this has not much to do with it and I won’t find the time to step you through this. Maybe other user will.

What I was actually trying to say is that there are forums with users way more experienced on this particular topic than we are. So even if people wanna help I am sure there are other places you get more experienced eyes on your question to help you.

@brakcounty said in Updating FOG and retaining settings:

Ok so if i just say “No” to the first part of the installation where it asks if i want to reinstall apache and php, everything else should go through without issue?

Yes it should!

@Veerakumar Thanks for the update. I was wondering why you wanted to use that other field in the “FOG Boot settings”…

@oleg-knysh This doesn’t make sense. Removing the partitions manually doesn’t influence the speed.

@ckasdf I just pushed two commits to dev-branch to fix some of the warnings. Will work on the rest when I find the time.

@Fernando-Gietz Seems like we have introduced some PHP warning when adding that fix to dev-branch. See the PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296 messages here: https://forums.fogproject.org/topic/13602/errors-in-apache-log-and-www-error-log

I won’t revert your fix as I think you are totally right. It shouldn’t query the full userTracking table if it only wants the information for one particular host! But the problem seems to be the action array send with the query. I’ll have a closer look at this now.

Edit: Nevermind, just pushed out a fix to dev-branch.

@ians said in Fog Client fails to join AD Domain with error 1326:

I hadn’t even thought of the possibility that it could be the special characters in the password. I went ahead and created a new domain admin account and used only letters and it worked!

Ohhh, do we actually have a special character issue?!

Updating the settings on my groups also updated the settings on my hosts, yay!

So this sounds like you were able to get things right and domain join on the client worked? Shall we mark this solved?

About the group settings you want to use the forum search and ask it for “persistent groups”. My guess is that you are expecting something from FOG’s group capabilities that it doesn’t have.

@NTLINUX Yes right, fresh installs are not affected by this! Fresh installs on Ubuntu with 1.5.7 work perfectly fine.

@ians What I was referring to are the two different version numbers of FOG you posted!! Now that I read it again I see that I might have overlooked the + sign. So you meant “using plain text password because I run FOG newer than 1.3.0” right?

Well, that’s definitely correct to use plain text on FOG 1.5.7.

Still the error message is pretty clear. Please search the forums. There are numerous topics on the “unknown username or bad password, code = 1326” error and I think most cases were solved by correcting the credentials.

There was one user stating that special characters in the password cause an issue but I wasn’t able to reproduce the issue myself: https://forums.fogproject.org/topic/12407/active-direcory-join-fail-bad-password-1-5-4

And here is another one who had issues with a sysprepped installation: https://forums.fogproject.org/topic/9256/computers-not-joining-our-domain-during-sysprep

Read through this and double check the credentials in the places mentioned by Wayne in this topic!!

@brakcounty said in Updating FOG and retaining settings:

so i went ahead and ran the update and broke mysql and mariadb beyond repair. apt update --fix-broken wasnt working. so i backed up my images, and reinstalled ubuntu server and fog 1.5.5 fresh. i luckily had a .sql backup file i exported two days ago and was able to import it via web ui successfully. i also mounted my RAID array to “/images” and its working fine. i will hold off on updating FOG to 1.5.7. Thanks for the input!

Sorry to hear you went through this. I thought my warning a day ago was clear enough but obviously it wasn’t.

There was no need to re-install Ubuntu as the database was still existing in a different directory (/var/lib/mysql-5.7). I suppose it’s all gone now. On the other hand it’s good to know that you got things up and running again using the sql backup file. But it would have saved you a lot of work and trouble if you’d waited for my instructions.

It’s fairly easy to upgrade to 1.5.7 and not break things but I needed to do a test on my end to make sure this is really working as I think it is before I would tell you. When you start the 1.5.7 installer you get to a point where it asks this question:

 *** Detected a potential need to reinstall apache and php files.
 *** This will remove the /etc/php* and /etc/apache2* directories
 ***  and remove/purge the apache and php files from this system.
 *** If you're okay with this please type Y, anything else will
 ***  continue the installation, but may mean you will need to
 ***  remove the files later and make proper changes as 
 ***  necessary. (Y/N): 

If you upgrade from 1.5.5 or 1.5.6 you are save to say No (n) here! In this case you upgrade to 1.5.7 without running into the database issue!

@kkptrck said in Skipping partition restore (MBR Only):

/dev/sda1 : start= 64, size= 1076291, type=27

I have missed one important thing here when you first posted this. The start sector 64 is quite unusual (usually it’s 63 or some other sector but I have not seen 64 yet) and I can imagine this being the cause of your issue. Did you manually do the partitioning?

@Luc-Novales Still waiting for you to test 01_undionly.kpxe! Please let us know.

@kkptrck Why ARM kernels?!? Dell doesn’t produce ARM platforms right?!?

@kkptrck said in Skipping partition restore (MBR Only):

I tried both arm and not arm version without success.

What do you mean by that??

@NIoSaT Thanks for testing! I will see if I can still fix this issue in the init scripts.

@Atton The mentioned service on your FOG server does not check for online hosts instantly. Default setting is every half an hour I think. Do you still see it as offline now?

@kkptrck Are you sure the source and destination machine are compatible enough to have the same Windows installation (not sysprepped) running on them??

By the way, which version of FOG are you running?

@dolf Great to see you read my reply as it was meant - a technical elaboration and not personal offense! :-)

Why do you choose resizable if you intend to make a backup copy of this laptop? This backup is supposed to go back to the same machine with the same disk and there shouldn’t be a need to use resizable image type for that reason!

Because it’s the default option, and when in doubt, default options are usually safe. In this case it’s not. I understand why this was a bad choice. Lesson learnt.

This choice is years old, so not something we changed lately. It was even before I started to help working on this project, so I can just guess. I think it’s the most used image type because people want to be able to image to different machines and it is working in most cases. While you can use FOG for backing up machines it’s not the common aim of this software. Again, not saying it’s perfect but we try to make it as save as we possibly can.

May I suggest that there shoud be some help text or a link to the wiki in the GUI that warns users about the pros and cons of different types of images?

Would you help us write the texts and find a good way to place them in the web UI so people definitely see them but don’t get annoyed?

Did you disable Windows 10 fast boot and properly shutdown before you started the capture?

I always shut down from the command line before capturing. Is that sufficient? As far as I understand that disables fast boot for the next boot.

Yes, good you knew about this. I was under the impression that this might have been caused by a unclean filesystem because of fast boot that got somehow corrupted.

There is no way we can prevent users from all different kinds of situations. We try to make FOG with as much care as we can bit it’s like a swiss knife and if someone uses it the wrong way no one will blame the factory or engineers for having created a dangerous tool, right?!

This is true!! But maybe the default option should be the safe(-r) one?

What is the default option of a swiss knife? I suppose it’s opening the hinging blade. I think you are on the right track with saying, we should add help text for people to let them know about the pros and cons of the different choices.

I am sorry I can’t give you really good advice on the actual problem. Without having the machine in front of me I fear I could give instructions that could make things even worse. But let’s give it a try anyway. I suppose you have some parts of the image capture on the FOG server. Take a look at /images/dev/.... There should be a folder named by the MAC address of this computer. Take a look at that. Do you have files d1.mbr, d1.partitions and d1.minimum.partitions in that. Please post the contents of the later two here - they’re just text.