Is this a newer thing from the 1.x series of FOG? I distinctly remember in the 0.32 days it would always just rename the file and move it to /images without having any involvement with setting up FTP, etc.

Hi friends. I’m running Ubuntu 14.04 with FOG 1.2.0. I’m working with an Acer V5 system. I have Windows 8.1 built on it and uploaded it as a multiple partition/single disk image (p.s. - will single partition mode even work with Windows 8.1 given it creates a boot partition automatically during install??)

Anyway, when I upload it, it seems fine, but I noticed that the image remained in the dev folder named by the MAC address. This is a brand new install of Ubuntu/FOG. I double checked the permissions but it’s 777 as I’d expect/want.

Is this something to do with this particular model system, by chance? I don’t have any others handy to upload and test, but I got to wondering if a Dell or something instead of Acer might yield different results. Anything else I can try?

I’m still tinkering around with FOG but I’m curious where that option is to auto expand partitions? Also, is this feature NTFS only, or will it work on EXT systems for Linux based images too?

Hello friends. I’ve used FOG extensively in the XP days and have rarely touched it in the last two years or so. Given that what Windows machines we have today are 8.1 based, I got to wondering about some best practices with sysprep, as I have some questions. I already have my answer file built, but I’m trying to lay out in my mind how to handle this tomorrow, a month down the road, a year down the road, etc.

Here’s the story. I have a base image with Windows 8.1 on a Lenovo E430. We’ll call it system A. I uploaded the image both before and after sysprep, so I basically have LenovoE430Windows8.1Base and LenovoE430Windows8.1Sysprep. It’s my understanding that for future “maintenance” when it comes to adding new updates to the image, I should deploy the non-sysprepped image, update it with Windows Update, then reupload as the sysprepped image. Okay, fine.

But let’s say system A gets destroyed, or deployed, or for whatever reason I no longer have the exact system I built the image on. Let’s say I do however have system B, a totally separate system, but still identical hardware; Lenovo E430.

Am I “okay” to deploy the non-sysprepped image to system B to pull down new Windows Updates? Or will I introduce issues? I would suspect that imaging system B with system A’s image, despite being identical hardware, would have some sort of Windows SID related issues. That being said, I would also suspect that once I run sysprep on system B and upload that as my mass deployment image, that I may very well rectify that issue as part of the sysprep process.

What do you folks do in your environments and recommend for this situation? Maintain two images, one being my base image to add new things into, and then an identical sysprepped variant of that image to utilize for mass deployment? Is dumping the non-sysprepped image on a different (but identical hardware) system in the way I described okay to do?

Hey there. Yes - it does. More than anything I just wanted confirmation that the UUID did need to match in fstab in order for swap to be used, as I simply couldn’t wrap my brain around how swap WOULD work with mismatched UUIDs. So that clarifies things a bit.

I could use the device ID, but I guess I’m just a believer in sticking to UUIDs due to their accuracy. The systems can vary wildly, I’m talking from a desktop made in the very early XP era to a two year old laptop, all running from the same image.

I still can’t really understand how the UUID is changing, though. What I do is I built the image on a 40 GB HDD, the smallest HDD I deal with. I blast that to the drives and expand the EXT4 partition to utilize the entirety of the space on the disk. To give you a little feedback as to what I’m doing, this is the basic jist. I work for a large public school district in the IT department. While the vast majority of our systems are Ubuntu, we do indeed use FOG for imaging the handful of Windows systems that are in-house. I’ve used FOG at my last district I worked at (all Windows based) with flying success. It felt like a natural course of action since FOG is, well, pretty much awesome. Our district is quite large, and spans a huge geographical area. A decent portion of the district is of lesser income individuals. As a result, I accept older computers from the XP generation and newer from pretty much anybody who wants to get rid of them. After using DBAN on the drives, or FOG’s full disk wipe, I put Xubuntu fully loaded with a lot of software, including educational software, on the computers for these people. All in all, I basically repurpose old computers and donate them to families who can utilize them, all free of cost, all running free and open source software. The point is to ensure that no families are left out unable to have a computer for their kids to do homework on; something that’s growing increasingly common (do I dare say, important) given the level of dependency with technology that districts are growing towards. Point of this story is to highlight exactly why (and how much) the systems I deal with can vary in hardware.

Given that Clonezilla does not change the UUID, it makes me wonder what process under the hood is operating differently versus FOG. I ‘thought’ FOG and Clonezilla were both built on a lot of the same core fundamental technologies. Since I am not imaging thousands of these systems at the same time, Clonezilla Live might be more suitable for a predictable image deployment, as I can simply house the image on my server and pull it over my gigabit LAN via SSH or SMB. I’d like to get FOG to work though in the event that we want to utilize it for our Linux systems, despite the fact we’re running our own imaging platform that was largely built by some of our HS tech interns (hosted on github, known as FLDT). But hey, options are nice, so it’d be nice to use FOG at home and know how to work around this in the event we ever want to put FOG to use at work.

I do have to wonder if FOG is being a bit fussy with the UUIDs in regard to how I’m imaging the drives. I have a spare tower on my desk with multiple IDE and SATA ports, so I drop the drives in that tower and PXE boot that tower to handle the images via FOG, or USB boot via Clonezilla Live. So the system that is running with the drives is not the system that the drive sees when it’s 100% packaged up and ready to go. Perhaps this is where FOG is getting miffed? Hard to say, but given an image is an image is an image, it would confuse me if this was the culprit.

At any rate, just some rambling thoughts and whatnot. Thanks again for your assistance - it’s appreciated!

The only question about that would be… is swap still usable by the system if the UUID of the swap partition did not match to ‘mount’ it? I look at it like this… if swap is just swap (which I believe), then why even bother fstab’ing it? Since the system automatically adds swap to fstab I can’t help but to think there’s a reason for that.

Thanks for your response!

Hi there. Thanks for your response. I guess I’m just not understanding ‘why’ it’s changing the UUID of swap in particular, but not root. I duplicated these efforts with Clonezilla, but when I deploy an image with Clonezilla, both UUIDs of swap and root (as seen via blkid) match what is in fstab. This is not the case for FOG.

On one hand I’m just thankful it’s swap and not root. If it was doing this to the root partition, we would have an instant road block until the UUIDs were manually (and tediously) changed. It makes me wonder if the mismatched UUID of swap thereby makes that partition useless, as if the system won’t know what to do with swap since it’s not ‘mounted’ properly as per the UUID it’s looking for not being available.

I’ll try what you mentioned above and see if it makes a difference. Have you personally witnessed this? Or has this process you explain at the end been something you’ve always done since day one?

Hello friends. I’m imaging some Linux systems (Xubuntu 14.04) using an Ubuntu 14.04 system as the server. When I deploy the images, everything works flawlessly, but I notice on the deployed systems they boot up citing a UUID error for JUST a split second at boot. It’s quick enough I can hardly catch anything it says. I checked via terminal and saw that while my UUID for the EXT4 root partition matches on each deployment, the UUID for the swap partition is different on each and every single one.

I have not noticed this with my previous imaging solution, Clonezilla Live, so it makes me wonder what is different that’s happening under FOG. Is there a way to counter-act this from happening?

Thanks for any and all assistance!