Posts made by rstockham23

@george1421 Here is the output of the ls command. Also note, that these images are stored on a Node server, so this command is being run on the Node server:

total 1661360
drwxrwxrwx  2 root root      4096 Jan 31 13:00 .
drwxrwxrwx 53 fog  root      4096 Jan 31 13:01 ..
-rwxrwxrwx  1 root root     32768 Jan 31 12:56 d1.mbr
-rwxrwxrwx  1 root root      1267 Jan 31 12:56 d1.original.uuids
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p10.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p11.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p12.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p13.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p14.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p15.img
-rwxrwxrwx  1 root root 212540978 Jan 31 12:58 d1p16.img
-rwxrwxrwx  1 root root   6742981 Jan 31 12:58 d1p17.img
-rwxrwxrwx  1 root root 730396661 Jan 31 12:59 d1p18.img
-rwxrwxrwx  1 root root   6742981 Jan 31 12:59 d1p19.img
-rwxrwxrwx  1 root root       100 Jan 31 12:56 d1p1.img
-rwxrwxrwx  1 root root 730396691 Jan 31 12:59 d1p20.img
-rwxrwxrwx  1 root root       276 Jan 31 12:59 d1p21.img
-rwxrwxrwx  1 root root       261 Jan 31 13:00 d1p22.img
-rwxrwxrwx  1 root root    245987 Jan 31 13:00 d1p23.img
-rwxrwxrwx  1 root root       272 Jan 31 13:00 d1p24.img
-rwxrwxrwx  1 root root       351 Jan 31 13:00 d1p25.img
-rwxrwxrwx  1 root root    127142 Jan 31 13:00 d1p26.img
-rwxrwxrwx  1 root root  13873585 Jan 31 13:00 d1p27.img
-rwxrwxrwx  1 root root       100 Jan 31 12:56 d1p2.img
-rwxrwxrwx  1 root root       100 Jan 31 12:56 d1p3.img
-rwxrwxrwx  1 root root       100 Jan 31 12:56 d1p4.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p5.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p6.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p7.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p8.img
-rwxrwxrwx  1 root root       100 Jan 31 12:57 d1p9.img
-rwxrwxrwx  1 root root      4357 Jan 31 12:56 d1.partitions

@Wayne-Workman Here is a link to a couple of videos with the Fog errors. One of them is before the imaging process and the other is after the imaging process. I never got these messages before and I assume that maybe they are related to why my Chromium images are not working. Please check it out:

link text
https://photos.app.goo.gl/ITMbKdiwib8Xaict2

@Wayne-Workman Thank you Wayne. I’ll try to upload the pictures again later. Your recommendation did help with the speed. It’s running at the speed I would expect it now. However, I still can’t use my Chromium images after the upgrade. They properly copy the files fine, but it’s something with the partitions…maybe UUID…I’m not sure, but they will not boot into Chromium. Just get the black screen. I can go to the UEFI settings and find all of the boot files, etc. I’ve tried them all, but nothing works. Everything worked fine until I upgraded. I went ahead and upgraded to the 1.5 newest Release Candidate and still having the same Chromium issue. I don’t even know what to try now, but it’s a pretty important thing to our school district.

I was recently having some Database/Schema issues with my 1.3 Fog Server and decided to just go ahead and upgrade to 1.4.4. After updating, FOG was operational again, however the Web Interface and any kind of boot loading interactions are extremely slow compared to what they were before. I tried restarting the server, etc and still no difference. Nothing changed otherwise and I’ve been running a FOG server for many years on this VM with no performance issues. Ubuntu 16.04 and updates are turned off.

Also another big problem is that we predominantly use FOG for Chromium images. We had just been using our Chromium image a few days before on some Dell laptops and everything was working great. Now since the upgrade, the image will still load onto the laptop through FOG and it appears everything was successful, but the laptops will never successfully boot into the Chromium image. Exact same hardware, exact same image, UEFI settings all the same as before, but they will not boot after imaging with version 1.4.4.

Anyone else seen any kind of similar issues after an update like this. I’m also attaching a couple of screenshots. There are some error messages showing when we image now that didn’t used to be there. Not sure if it could be useful with these issues or not. I’ve tried some Windows images and they work fine, although much slower to load than before, but no go with Chromium.
 

@Joe-Schmitt I tried manually rebooting after the first login and it didn’t make a difference. After the reboot, it still took the same amount of time to restart on it’s own, rename, etc. I did try changing the FOG_CLIENT_CHECKIN_TIME from 60 seconds to 30 seconds and it did approximately cut the wait time down in half. I’m not sure what time is too short…if that’s too much network chatter or not, but it helps. Problem not really solved, but it is better than 10 minutes. Problem still seems to be that it takes multiple attempts for the client to Authenticate to the server.

@george1421 @Joe-Schmitt @Tom-Elliott @Wayne-Workman Looking closer at the Fog Log it appears to me that at first, it’s not Authenticating correctly. It’s checking every 60 seconds and the first few times it checks, it’s getting this:

1/27/2017 2:04 PM Middleware::Communication Download: http://10.23.8.45/fog/management/other/ssl/srvpublic.crt
1/27/2017 2:04 PM Data::RSA FOG Server CA cert found
1/27/2017 2:04 PM Data::RSA ERROR: Certificate validation failed
1/27/2017 2:04 PM Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: The signature of the certificate cannot be verified. (NotSignatureValid)
1/27/2017 2:04 PM Middleware::Authentication ERROR: Could not authenticate
1/27/2017 2:04 PM Middleware::Authentication ERROR: Certificate is not from FOG CA

Then when it does finally authenticate, it’s just a minute or two before it actually get’s the name change in order and reboots. Any ideas why the authentication errors early on after it boots up?

@george1421 That’s correct…I have done all of those things. Install client, disable service, run sysprep command to start service again. I just tried reimaging one to follow it and after it gets to the desktop for the first time, I checked windows services and it shows Fog Service as Automatic and Running, but yet it isn’t renaming/rebooting. I then manually restarted the Service and it still sits there for about 10 minutes after restarting the service before it actually does anything.

@Joe-Schmitt Good catch. I did not set it to delay. Not sure why it’s taking so long to start. That is a bit strange though, because early on when we were having this issue, I looked at services.msc and confirmed that the Fog Client service was running and it still wasn’t rebooting for quite some time. Unless the gui said it was running when in fact it wasn’t. I’ll have to watch that more closely next time and see if indeed that’s what is going on. Still strange that it’s taking that long for the service to kick on.

@Wayne-Workman Wayne…Ignore the first part of that message about reboots. I was just referring to the sysprep stuff and it actually only reboots once. Once it settles and autologins to the desktop, it is taking consistently and approximately 10 minutes before it restarts to change the name of the computer and then it will restart one more time after that to join the domain. It’s that 10 minute time period that I’d like to trim down. Attached is my fog.log file from a computer that I just imaged. For your reference, the time that the computer first auto logged in to the Desktop was 12:57. The reboot for the name change happened at 1:07 and the domain join reboot at 1:09. 0_1485540857343_fog.log

@george1421 It is set to 60, which I assume is seconds. However it’s taking about 10 minutes consistently before it changes the name.

@Tom-Elliott I thought I was using one of the newer clients. It is version 0.11.1
Is that too old to work properly with Win10?

Server

• FOG Version: 1.3.0
• OS: Ubuntu 16.04

Client

• Service Version: 0.11.1
• OS: Windows 10 Education

Description

I recently created a new fog server after many, many years of using my old one. We are also deploying Windows 10 computers for the first time in our managed environment as well. Everything is working great, except for one thing that I’m just wondering if can be tweaked. We almost always have FOG rename our hosts and join our domain. The process is actually working, however after the client boots up after image and has a few restarts and gets to the desktop…the client will take sometimes up to 10 minutes before it will rename and the ultimately join the domain. It will always eventually do it, but it just seems to take forever for that process to be initiated. I didn’t know if there could be any modifications that could help with this. It seems very consistent as well. We may re-image 10 computers and they will all get to the desktop. Sit there for nearly 10 minutes and then consistently, one by one finally rename, restart, and join the domain. I’d love to be able to cut down on that time that it sits there and seemingly does nothing before renaming and joining. Any tips would be appreciated.

Thanks Wayne. I checked out the log and also communicated some with Tom. I had to update my Active Directory info in Fog for Legacy Fogcrypt and the new password system. All is well now. Thanks!

I recently updated to Fog 1.3.0 in order to be able to create and deploy images for Win 10 and Chromium. Had great success with Chromium, but yesterday I was trying to create and deploy a Windows 7 image. I’m a long time fog user and never had problems with this before, but after deploying the image, it did not auto-join the domain. The setting was selected for that client to join the domain and all the settings were still correct from the previous version, but after the image, it never joined. It changed the name, etc, but did not join the domain. Anyone else have any issues with this after updating? I’m not really sure where to go to troubleshoot what’s happening.

Note: I did use Sysprep and the new Client. I followed the directions to disable the Fog Service and use the sysprep script to re-enable the service after the image. I also removed the checkbox for the early namechange option as well. All seemed to work except for the domain joining.

@Tom-Elliott Just tried removing all of those files and re-installing fog trunk. This time it did get to the screen in the installation where it said to access the site to update the schema and then hit Enter to continue. However again, when I went to the website to update the schema, I got this message on the browser:

SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘hosts.hostPending’ in ‘where clause’ SQL: [93] SELECT COUNT(hosts.hostID) AS total FROM hostsWHERE hosts.hostPending=‘1’ LIMIT 1 Params: 0

@Tom-Elliott Let me ask you this real quick. If I create a brand new fog server from scratch with Trunk. Is there any way to transfer information from the old to the new? Images, registration information, etc? Or do you think I’d be better off trying to fix my current one?

@Tom-Elliott Exact…copy and pasted from the web browser I tried to access it with

@Tom-Elliott Thank you. I just attempted to upgrade to Trunk. Ran into some bumps. I was using Ubuntu 12 before and appeared PHP wasn’t going to be new enough, so I upgraded to Ubuntu 14 and then updated to Trunk. Appeared to be successful but when going to the Fog login page, I’m getting this error instead:

SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘hosts.hostPending’ in ‘where clause’ SQL: [93] SELECT COUNT(hosts.hostID) AS total FROM hostsWHERE hosts.hostPending=‘1’ LIMIT 1 Params: 0

Any thoughts?

I updated to Trunk today from 1.2.0 and the install was succesful with no errors, however after the update when accessing the website to login, I get this error instead:

SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘hosts.hostPending’ in ‘where clause’ SQL: [93] SELECT COUNT(hosts.hostID) AS total FROM hostsWHERE hosts.hostPending=‘1’ LIMIT 1 Params: 0

Any thoughts?

Re: ChromiumOS r48 - EliteBook 8730w

I have seen a few posts on here of people saying they were able to successfully create and restore an image for Chromium OS. I have tried in the past unsuccessfully but recently gave it another shot after seeing some success messages on here. I’m using Chromium 52, Fog 1.2.0, with Image type of Linux, Multi Partition, Single Disk. When uploading, all the partitions seem to be successful and when downloading, they seem to transfer fine as well, but then after the image, the hard drive will not boot to Chromium. Doesn’t recognize it as bootable. Any tips?