Posts made by Wolfbane8653

@Roger-Saffle Are you using an image that was already attached to the domain when you uploaded it?

To make it official , I spoke with Tom today and I learned that the client auto updates at boot. (yeah been out of the loop for awhile) With many businesses using products like Clean Slate and Deepfreeze this client auto update would be a “useless” tool. Just to take you through the process. The pc gets client installed --> server gets updated along with new client update --> pc gets booted and the client sees a new update is on the server --> client downloads update and installs --> pc shuts down and Deepfreeze wipes out all changed made while in frozen state --> pc boots client sees new update and installs. This loop will continue until the client has been “thawed” and changes allowed to be made to the hard drive. This seems like wasted bandwidth. Don’t get me wrong auto update feature is awesome. Just some people (like me) will want auto updates disabled for hosts that are frozen.

Might I suggest a “Disable Client Auto updates” tick in the global settings and also for Host/Group settings.

“/” are a curse! Who uses “/” in passwords!

SOOooooo then.

• Try another 5040.
• boot to debug mode. do an ifconfig to see if it has an ip. if no ip then @george1421 is correct.

@ChuckC

Try another OPtiplex 5040. This maybe directly related to this particular machine.

Could already be registered with blank info in the database. But we’ll rule that out later.

IF same error occurs on the same model but different machine then try installing an earlier version of the kernels.

@Wayne-Workman

This was a feature implemented in May-ish

./installfog.sh --help

Usage: ./installfog.sh [-hdUuHSCKY] [-f <filename>] [-D </directory/to/document/root/>]
[-W <webroot/to/fog/after/docroot/>] [-B </backup/path/>]
[-s <192.168.1.10>] [-e 192.168.1.254] [-b <undionly.kpxe>]
-h -? --help Display this info
-d --no-defaults Don’t guess defaults
-U --no-upgrade Don’t attempt to upgrade
-H --no-htmldoc No htmldoc, means no PDFs
-S --force-https Force HTTPS redirect
-C --recreate-CA Recreate the CA Keys
-K --recreate-keys Recreate the SSL Keys
-Y -y --autoaccept Auto accept defaults and install
-f --file Use different update file
-D --docroot Specify the Apache Docroot for fog
defaults to OS DocumentRoot
-W --webroot Specify the web root url want fog to use
(E.G. http://127.0.0.1/fog,
http://127.0.0.1/)
Defaults to /fog/
-B --backuppath Specify the backup path
–uninstall Uninstall FOG
-s --startrange DHCP Start range
-e --endrange DHCP End range
-b --bootfile DHCP Boot file

https://github.com/FOGProject/fogproject/blob/33fe4988cc738a625308267ae78cdc7879a6e411/src/buildroot/package/fog/scripts/etc/init.d/S99fog

I hope this helps a bit to understand the commands you can use in the new ipxe menu in 1.3.0.

two if’s here…

if you were on the latest svn right before svn went down or used a git during that time
AND
if you uploaded an image on those svn/git builds then your freshly downloaded host may not resize correctly. It was even reported that some would resize correctly while others did not. This was a little glitch in the uploaded images.

SO TO FIX:
upgrade to latest svn/git then re-upload that particular image. Then your downloaded hosts will resize correctly.

32-bit and 64-bit both work in the inits.

You just have to boot into debug mode right now and then type in the above commands. I will talk with Tom to see if we can change the compatibility check first as we do not want to mess up the current flow

confirmed git 4333

Can clear by highlighting and delete but when you hit update it re-appears

Also clear fields button does not clear legacy field at all.

2 problems same field!

Tom has added the program into the init’s but has not implemented this in full as of yet.

Tested x86_64 (aka init) and commands work correctly

Need to test the x86 (aka init_32)

this will be done in the morning

https://help.ubuntu.com/community/Smartmontools
http://www.techrepublic.com/blog/linux-and-open-source/using-smartctl-to-get-smart-status-information-on-your-hard-drives/

• I want to add to the compatibility check and incorporate a smart status check on the drives being imaged.

• Also add the check right before imaging while the inits are doing checks, check the SMART disk status. If “PASSED” then continue. If “FAILED” then error out with message about a bad drive. If “UNSUPPORTED” then continue. (need to check on the message for unsupported but you get the jist)

This also gives you all the details of the HDD check it out!

apt-get install smartmontools 
smartctl -i /dev/sda
smartctl -H /dev/sda  

We could store that HDD info in the database if we wanted also for inventory purposes and such

I believe this will create a better stability of FOG itself

What do all of you think?

@Wayne-Workman said:

I’ve had this issue on both Dell 7010s and on some older Lenovos. Every now and again I’ll find a machine that just won’t image.

Sometimes, pulling the network cable and power cable and then hitting the power button a few times, then hooking everything back up will fix it. It’s just strange.

WORKED for my one Dell E6400. Very odd. That trick is used for clearing corrupt RAM and I did a swap so it doesn’t exactly make sense. Whatever…it works now.

Still working on the D630 image will be done with it shortly.

I installed windows on a D630 and then straight uploaded it.

This “new” image with no programs installed or anything work on 2 of the D630’s. Continuing to install all needed software on the “new” image and then will reupload again and test on those 12 troubled laptops.

BIOS update did not fix issue.
RAM change did not fix issue.

Got this error on another model and different image.

Having this issue:
(1) Dell Latitude E6400 x64 – Used another machine to image the HDD
(12) Dell Latitude D630 x64 – Re-uploading image now to test

Not having issues:
(ALL) HP dc7800
(Most) Dell Latitude E6400 x64
(ALL) Dell Latitude E6410 x64
(ALL) Dell Latitude E6420 x64
(ALL) Dell Latitude D610 x32

git 4290

Issue occurred during download at step “restoring partition tables (GPT)…”

Error: “Error trying to restore GPT partition tables”

Checked gdisk /dev/sda but no partitions present due to the FOG script clearing them. Tried a “Quick wipe” and “Full wipe” tasks but still no go.

Went into gdisk again to see if I could create an MBR correctly and it did succeed.

I thought that it maybe the drive so I threw this drive into a confirmed working host. The new host download the image on to the HDD without issue.

Looking into BIOS updates or bad RAM for the issue. Will report back with full solution.

Just thought I would report just incase anyone else had the issue.

Touchy subject…sysprep should be used at least for your licensing. As for drivers and hardware compatibility sysprep is not needed for identical hardware BUT make sure the host is not connected to your AD before uploading.

FYI wifi profiles are not carried across on windows. Use xml files for this.

Please continue to use git as that version is up to 4193 and the svn is at 3799. Tom is currently working on repushing the versions up.

Again Tom will release an announcement when svn is up-to-date.

x32 bit machines should now be fixed in the latest git.

• x32 Upload times are slow but they will upload all the way. ~84Mib/s with lvl 9 compression (4:20:15)
• x32 Download times are “fast” ~1.8Gib/s lvl 9 compression (00:12:01)
• x64 Up 3.2Gib/s lvl9 (00:20:00) Down 7.3Gib/s lvl9 (00:09:00)

Full Description of problem:
1.)nfs mount issue was due to not getting an ip address during init boot.
2.)Not getting an ip was due to an addition of fixing VLAN issues for networks and sleep command was an “Illegal Instruction” (along with other commands essential to “init fog script”)
3.)sleep was not working due to a compiling issue in the glibc v2.21.

*Solution:
1.) Downgraded init’s to use glibc v2.20 (fixed sleep function).
2.) init’s now get ips from edits in files K40Network and S40Network.
3.)NFS mounts successfully now that init gets an ip address at boot.

These changes have been pushed to both init_32.xz and init.xz.

If you see this issue with your old 32 bit only processors please make sure you update to the latest version and this should be fixed.

P.S. @Tom-Elliott thanks for the remote sessions and time. Took us a while but we nailed down the problem

Is this your set up?

–Pre-existing DHCP server (windows, linux, novel, etc.)
–all one LAN (no vlans)
–all using the same subnetmask

If so, YES! You do not need dnsmasq. dnsmasq is used if you are unable to edit your DHCP server options 66 & 67 due to “security” or “location”. “ProxyDHCP is a solution for those of you who are working with an unmodifiable DHCP server or wish to avoid the hassle of editing the already existing DHCP server, or even as a portable imaging solution.”

SO if you already have a DCHP server running all you need to do is follow the instructions:
https://wiki.fogproject.org/wiki/index.php/DHCP_Settings