I’m running another upload - just got my init changed (work’s been busy). I’ll let you know if I can get it working for me.
I do have a question for you though (for my own problem): are you by chance using a single partition image, or a multi partition non-resizable?
Ahhh okay.
Tell you what, since I’m going to go dig around in the FOG init anyways to see about that ntfs resize, maybe I’ll add a dummy function that involves using $machine and see what I can find. I’m hardly a linux expert though (never even touched it before FOG), so hopefully someone else can give you some advice too.
Ah. Yeah, it doesn’t actually perform the clean up, and as a result doesn’t perform the ntfs extend.
The only real difference I can see here is that one image is single partition resizable, and one image is multi-disk single partition non-resizable.
I’m guessing that it’s not running an ntfs extend by design for the multi-disk single partition image. Maybe. Is anyone else who is using this function using an image type other than single partition?
If it makes you feel better, I uploaded a new image over the weekend and now I’m having errors too, haha.
Something about not having enough white space for the CP. Reuploading right now to see the error again…
Hmm… the difference that stands out to me is the fact that you currently have the folder in place on the image, but the other scripts are creating it. Maybe a permissions issue? But then the fact that you can do it by “hand”… I guess i’m not sure.
If using just “$machine” is working for you, is there a reason you cant just use that?
Hmm I’m a little confused, but from what I can make out it almost sounds like a permissions issue. Have you checked the folder permissions and ownership?
Also, is it actually a storage node? I don’t use any nodes other than the default, but my understanding is that storage nodes are stripped down, but actual installations of FOG which point back to the master server – more than just a network drive.
Ahhh that could be the problem I’m having. Idk if I’ll be able to get it working for my workplace (we have a bit of an odd situation with joining domains, where doing it through the unattend isn’t really an option – don’t ask, it’s complicated, haha). Maybe I’ll just add in some vbscript to query for that registry key and edit the unattend in the middle of the process to the current computer name.
Thanks for the link though! I always like to see where variables are coming from.
Yeah, I’m just puzzled as to why the Single Partition works for the one with that extra boot partition, but not for the one that has the boot partition removed. I would expect it not to work for either in this situation.
But hey! It’s working. And that’s what I really care about, haha.
Ah. This actually still isn’t working for me. Using this in the specialize pass (in the same place):
<ComputerName>%MACHINENAME%</ComputerName>
Do you know where the %MACHINENAME% variable is pulling its information from? I was under the impression it grabs the hostname currently in place, but I may have misunderstood.
Got it working as a Multi-Partition Single disk. It’s interesting that a Single Partition upload works for a VM with two partitions, but only a Multi Partition upload works for a VM with one partition.
Here’s some information regarding my current situation:
I’ve got two VMs, both running Windows 7. Image#1 has the 100mb partition, Image#2 does not.
I can upload Image#1 as a single, resizable partition. I can only upload Image#2 as a multiple partition - single disc (not resizable).
I may have to do that.
I ran into another snag though (which is probably the actual problem) - With my original VM, it would properly recognize NTFS, and would upload as single partition, resizable. With my new VM, it doesn’t properly recognize NTFS, has a fit, and then tries to upload as RAW.
The two main differences I can find is that the working VM is IDE and has the 100mb partition in place. The one that is not working is SCSI and has only one partition.
Still trying to run down a solution. Not having much luck.
I have a question for those of you using VMware to upload images.
I have VM that I converted from a deployed Ghost image, which automatically pulled in to IDE, but the size is just awful (78.3GB allocated for the VM). However, FOG will only grab what’s actually being used by the VM, and leave behind the white space.
When creating a new VMware image, I had to go with SCSI, as I only had VMware player available to me. I got the 3.5 kernel recompiled with the VMware SCSI driver so it loads properly, but it looks like FOG is trying to grab the entire partition (40.0GB) instead of only the used space (24.4GB).
Does anyone know a good way to work around this?
What type of filesystem is the network drive using? And when does the error occur - when you try to attach the network drive to your server, or when fog tries to automatically store an image on it?
Ahhhh it takes %MACHINENAME% but not %COMPUTERNAME%? Bah.
Thanks for the link! It definitely helps, and I appreciate it.
No problem. And if you need to fill the holes, you can always use the MDT to grab the extra stuff. My only experience is with the D and E series laptops, but the only extra driver I had to add in with MDT was an Intel Centrino wireless driver, and I believe that’s only because they aren’t standard parts for Dell machines.
Another useful bit of information would be the type of image you’re using: is it single partition, or multi partition? Lots of users report issues when trying to create a single partition image with Windows 7.
Interesting. I currently have it left as-is, since my organization typically doesn’t use quick imaging (we either have scheduled multicasts, or we use full host registration and inventory as new computers come in), but this is definitely good to know. Thanks for looking into it!
I actually use the cab files on the Dell site, plus a few extra (my company often orders different network cards, and those aren’t in the cab files by default). A lot of the files may not be 100% up to date, but they sure are close.
If you absolutely must have the newest drivers, you could look into using Microsoft’s Deployment Toolkit (MDT). You can use the deployment workbench to strip drivers down to the minimum using the Import Drivers function for the “Out-of-Box” drivers. You can use it to pull drivers off of a 100% functioning computer too (but be careful: it’ll often pull in a bunch of drivers that are unnecessary, depending on what’s all been installed on the computer).
That being said, it’s a little bit tedious as well. You could always try Dell’s automatic update client, allow it to download drivers, then use MDT to convert them to a deployable form. I’ve never had much luck with their update client, though.