@Tom-Elliott : That makes sense, regarding the mount. This was also true for the values returned by my CURRENT assignment, via. blkid, where its UUID also did not reflect the host machine’s swap UUID. What I am interested in now is what you mentioned about removing the UUID for the swap and defining it for the partition itself. Would you mind elaborating on this a little for me? I am digging around trying to understand more about how to configure this, and I feel you are hinting on something similar to where I should be headed.

The image I am handling by-the-way, currently, is just an Ubuntu 14.04 desktop installation. So I have done nothing special to it other than install it, shut the machine down, and capture its image. I figured this would be the best starting place for a lot of things, but it is starting to sound like that is a loaded gun. That I need to configure a few things at a minimum to ensure subsequent images are deployed more smoothly?

-Dustin

@george1421 : It could very well be a simple answer to an otherwise superfluously complex problem - of which I may have fabricated :P. Let me look into other ways of handling the definition of the partitions in the fstab.

I absolutely feel the problem is significantly simpler than I am looking at it from, so this would be a very nice solution if it works. I have no attachment to the UUID’s, I just need all the partitions properly identified, so that Partclone can capture the image and so the drive is registered when the machine boots. In the former, it appears to completely thwart Partclone if any of the drives appear to be “not mounted”. The later causes the machine to hang during boot, prompting the user to either skip drive mounting or to wait for the machine to figure it out.

Nonetheless, I agree. I believe the post download scripts knowledge will come in great use here soon We have a lot of plans for remote imaging, and I am looking to become pretty intimate with the everything FOG provides.

-Dustin

Okay! My script is being called, and I believe I see the issue…

Every time I deploy a new image, my swap drive has the incorrect UUID in its fstab. So I thought I would just update it after imaging, which led me to post download scripts. Now that I am looking at it, it appears that the ‘fstab’ has no contents at the time of its execution, so it is not able to update the swap drive’s UUID in the fstab after imaging the host machine.

Everything said, there is no way what I am doing is valid. I have seen very little resources on people having this issue, yet it is the very first thing I have hit with every image I captured. What can I do to ensure the swap drive gets assigned the correct UUID? When going through the debug process, I noted sections where the following occurred…

• Resetting UUIDs…
• Resetting swap systems…
• Restoring swap partition

For some reason, I feel like there is an issue in how I am capturing images, or in how the server resets the swap drives. I have to imagine it’s on my end though, given the nature of the issue and lack of articles with other users having the same issue. Is there a better way to handle how the swap drive gets assigned its UUID in it the host machine?

-Dustin

@george1421 : That makes sense. I am going through the debug deploy task as we speak - very cool! As soon as I can, I will query this (currently in the middle of Partclone).

I really want to learn more of what you guys did here, it’s really awesome. As someone overcoming the whole understanding-networking-in-depth, going through the process of learning what you guys have done has been great. That said, boy am I ready to develop something where the network doesn’t kick my ass left-and-right!

-Dustin

@mrayzies : I like that update to the fog.postdownload file, prompting input! I was avoiding a lot of these prompts, not sure how the script was executed and whether it had to avoid blocking commands or not.

Regarding the ${postdownpath}, I have tried with both a trailing slash and not, as I have no idea where this variable comes from. That said, where can I determine this variable’s assignment?

Yes, that is the other article I am referencing - a lot of examples in it! Let me try adding in some echoes and attempt a debug deploy. I have never done a debug deploy, do I need to enable the PXE menu to get this to work? Currently I have the menus hidden. Giving it a whack in the mean time.

Thanks!

edit:
A question regarding bullet point #3 and #4 in your comment.

Would this include copying the actual script to the host machine? Or, would this only include additional resources I import during the scripts execution - similarly to the fog/funcs.sh in the other scripts?

-Dustin

Thought I might get to answer something on here for once! What Wayne said though is all I had to say

Don’t forget the MYSql call was going to be my one major point to not forget.

-Dustin

Server

• FOG Version: 1.3.0-rc11
• OS: Ubuntu 14.04

Description

I am near the end of what I need from the FOG project, and everything seems to be functioning pretty solid so far. However, I am having issues kicking off post download scripts.

I have followed the following two articles to no success…

• https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script-under-construction/3
• https://wiki.fogproject.org/wiki/index.php/Auto_driver_Install

My /images/postdownloadscripts/fog.postdownload looks like…

#!/bin/sh

. ${postdownpath}update_swap_uuid.sh

And update_swap_uuid.sh looks like…

#!/bin/bash

ORIGINAL=$(grep -v '#' /etc/fstab | grep swap | cut -d ' ' -f1 | cut -d '=' -f2)
CURRENT=$(blkid | grep 'swap' | cut -d ' ' -f2 | cut -d '"' -f2)
TIME=$(date +%Y%m%d%H%M%S)

if [ "$ORIGINAL" = "$CURRENT" ];
then
  exit
fi

# NOTE: Backup 'fstab'
cp /etc/fstab "/etc/fstab.$TIME.backup"

# NOTE: Overwrite ORIGINAL with CURRENT swap UUID
sed -i -e "s/$ORIGINAL/$CURRENT/g" /etc/fstab

I have had no issues using the update script itself, so I am not sure why FOG would have an issue with it.

I have also given ‘755’ rights to the whole postdownloadscripts/ directory.

Am I forgetting something or doing something incorrectly? I have tried little permutations of editing the fog.postdownload and update scripts, as well as hunting for settings and permissions to allow access to these contents.

Also, where would I look for any indication that these are being run? I have looked very closely through the entire process and have seen no output text about running this particular region of scripts.

Many thanks for your time!

-Dustin

Understood - I felt I should have done that as well; my mistake.

That said, I have resolved the issue. The issue was addressed by updating the swap drive’s UUID. I raised this question before, how the swap drive does not correctly re-assign its UUID upon deploying an existing image. I had to manually re-assign this to get the image capture to work correctly. Moving forward, the swap drive’s UUID needs to be set as a part of the post-imaging process. Otherwise, subsequent image captures will fail, it appears, from my experience so far.

Nonetheless, thank you for being so attentive - all of you. You guys are seriously the most enjoyable group of dev’s I have had the pleasure of asking questions.

-Dustin

I am having one more issue, which I figure I should also ask about while I am digging around for an answer.

During image capture, I now receive an error from Partclone stating, “bitmap free count error” on ‘/dev/sda1’. I have checked the partitions in both ‘/images/dev/…’ and validated them against the host machine - which are valid. I am not sure if this is just a side effect of recent imaging operations (potentially gone wrong), or some other larger issue in finalizing the configuration for everything. The PC I am imaging is just a test box, so I can wipe it with a clean 14.04 installation as necessary. Which may very well be one of my next tests, as I am not having much headway with finding the answer.

Thanks again.

-Dustin

Holy! Thank you. I was so close; I was missing the FOG server IP from one of the settings. Please make this the #1 wikipedia entry regarding the configuration of this.

Let me test this with the test group of PC’s I have real quick, see if there are any immediate issues I should be concerned with when capturing/deploying images in this configuration.

Again, thank you for that article. It is the article I have been looking for all morning.

-Dustin

Yes, apologies. My terminology is still a WIP regarding networking. Yes, you are correct though; where the router handles DHCP. I have updated the original inquiry.

Now! Let me read the rest of your reply…

Hi!

I have successfully run FOG in an isolated network. However, switching to our primary network, where DHCP is handled by the router, I am unable to get the host machines to correctly boot into the TFTP. Each time I try to correct this, I always receive the “PXE-E53: No boot filename” error.

I am not very familiar with DNSMasq or configuring something of this nature, so I am not entirely sure what might be right or wrong throughout the process. That said, at this point, I have…

• Installed DNSMasq
• Updated ‘/etc/dnsmasq.conf’ to reflect configuration
  ** Should I instead use the ‘/etc/dnsmasq.d/ltsp.conf’ file? What are the differences?
• Given ‘/tftpboot’ all rights
• Dropped firewall
• Given undionly.kpxe its sym-link
• Ensure ‘xinet’ service is disabled
• Ensure ‘/etc/default/tftpd-hpa’ is configured correctly

I may have done a few more things, but this is the broad stretch of what I have tried.

During installation, I selected to NOT allow FOG to handle either DHCP or DNS as well.

A lot of the articles I find in both the wikipedia and online are a little dated or have made understanding what might, possibly, be correct. If anyone has a moment to help me understand what I am missing, I would be very appreciative.

Thanks!

-Dustin

I was caught up on a few independent tasks and am just coming back to these. @Thiago Thanks so much! That’s awesome! I wrote one up the other day, but this is a lot clearer in its implementation.

On to my next task; determining if I can kick FOG off with HTTP commands

Thanks again Wayne and Thiago!

I see! Thank you for all this information - it’s incredibly useful and just what I was looking for. I will go back to 1.3 and look into setting up FOS to handle a post script as you suggested. That DEFINTIELY sounds like what I want.

I was even telling a team member of a similar idea, so it’s awesome that FOG already handles this. You guys did an amazing job with this by the way. Before I started, I laid out a set of criteria for how I would like to handle remote imaging. When I came across FOG’s solution, I was like, wow, this is exactly where I was wanting to go, and it does it and more! Again, stellar implementation.

The /etc/fstab within the image.

So, to follow up on the other question I had, there should be no concern in using 1.3 then? Do you think the issues I am having with 1.2 are a result of some artifact from 1.3 when I “downgraded” to 1.2?

I will look at the postinstall scripts solution - is this something PXE would handle after imaging? Or are you just suggesting that I write an init script that always corrects the fstab?

Thanks, again; I know these are easy questions, but finding the answers have been more difficult than I was expected - perhaps, just a result of ignorance on the topic though.

I am new to FOG, and when I installed everything it was as of v1.3.0 RC8.

Upon successfully installing the FOG server on my local machine, I noticed that each image deployment would result in the ‘swap’ HDD UUID changing each time. This causes the /etc/fstab file to become invalid as a result - even when using ‘Single Disk - Resizable’.

I then proceeded to try v1.2.0, as it was stated as the most recent stable version. However, upon setting it up, I receive TFTP ARP and connection issues left-and-right. Unfortunately no particular resource helped me with this, and I have tried configuring the dhcpd.conf, turning on/off various firewall settings, and restarting services. I am also unable to invoke “tftp x.x.x.x -c get unidonly.kpxe” this way too - it times out.

I guess my question is, should I go ahead and use the latest v1.3.x RCx builds and is there another method for handling the imaging such that the fstab isn’t out of date (or that the swap doesn’t get assigned a new UUID).

Anyway, thank you for any input provided.

-Dustin