Ahhh okay. That would explain why I’m not seeing them - I currently have a deployment VM as a local guest on my personal machine. I have it bridged, so it would be using my Intel NIC drivers, I believe.
I actually have been intending on pushing this VM to our vSphere ESXi host as well at some point - If I find time I’ll do some troubleshooting, but I haven’t done any uploading from there yet.
Any chance there are some VLAN/QoS settings which are throttling the upload speed?
Really? I haven’t had a problem using VMWare to handle the uploads.
What version of VMWare are you using? And is it player or workstation?
On a side note, you actually can use non-SCSI drives. Getting to that point is anything but intuitive, though.
Upon VM creation, VMWare will force you to start with a SCSI drive. However, before booting, you can open up the configuration for the VM, delete the SCSI device, and upon re-adding a hard disk, you can select IDE – which FOG detects and handles innately with the Kernels it has built in. I tried both ways, and found that just using a VMWare IDE disk was the best solution for us.
Haha good stuff. That’s actually a lot better speed than I was expecting.
unattended.xml should not be required for the FOG system (I think).
If you want to join the domain during the sysprep process, then yes, you will need to set up an unattended.xml file and use sysprep (not necessary for Windows 7, but can still be beneficial).
I’d suggest adding in the following lines right after “ntfs-3g -o force,rw $part /ntfs”:
[CODE]printf “Error Message: $?\n”;
sleep 10;[/CODE]
Or use echo instead of printf. Just to see if there’s anything useful in there.
Tried finding the exit codes online, but it looks like the fastest way to find them would be to pull up the ntfs-3g man page from the console to see what the exit codes are (here’s the reference page which suggests doing that):
[url]http://www.tuxera.com/community/ntfs-3g-manual/#9[/url]
Interesting… $? checks for an error thrown by the previous statement, right? (I don’t have a ton of experience in bash). Maybe the mount succeeds, but technically has an error? $? could have useful information that could be printed. Hopefully, haha.
There is logic to remove the hibernation and page files:
[LIST]
[]FOG_UPLOADIGNOREPAGEHIBER is a constant defined in config.php
[]createUploadImagePackage from functions.include.php makes use of this constant to determine how to set $ignorepg
[]$ignorepg is used by init.gz/bin/fog at about line 746 (search for $ignorepg, I have edited this file a couple times. not sure what line exactly it will be for you)
[LIST]
[]If $ignorepg has been set to 1 by createUploadImagePackage, then the drive should be mounted with ntfs-3g, and pagefile.sys and hiberfil.sys should be removed by rm -f
[/LIST]
[/LIST]
Good luck! Sorry for the wall of text.
If you feel like getting in to it, in order to get the boot package to get sent to the right location, you could take a look at the following lines (for example, inside function createInventoryPackage() in functions.include.php):
[php]
$ftp = ftp_connect(getSetting( $conn, “FOG_TFTP_HOST” ));
$ftp_loginres = ftp_login($ftp, getSetting( $conn, “FOG_TFTP_FTP_USERNAME” ), getSetting( $conn, “FOG_TFTP_FTP_PASSWORD” ));
[/php]
If you feel like getting in to a more “correct” way of doing this, I think the issue with getting the boot files pushed to the correct locations is that $conn is (correctly) looking at the master node since that’s where MySQL lives, so the “FOG_TFTP_HOST” information it receives are the master node settings. I [I]think[/I]. I’m not positive on that. I was thinking of switching it so it gets its information from the config.php file located on the service, but there are a [I]lot[/I] of calls to the MySQL based getSetting function. It might take a lot of changes to rework that.
Alright. Got home from classes, and switched computers so I could grab my notes. Of course I have to say be really careful with all of this: if something goes wrong, it will most likely make your production system not functional. Try to do all this on a test system instead of a production system, if at all possible. At least make backups/take notes of what you all changed.
I have attached the list of my notes of what I all had to change to get it working. I’d attach the files themselves… but I have a lot of other changes inside these files as well, so I tried pulling out the only changes you’d need to get subnet / location based image push.
Couple of things:
[LIST=1]
[]The subnets I’m working with are 192.168.4.0-192.168.7.255, 192.168.14., and 192.168.24.* – make sure you change the instances of this to match your subnets.
[]When FOG determines where to put the boot file named after the client’s MAC address, it is still placed on the master node. With the synchronization methods put forward by that guide, it will be duplicated across all nodes and this isn’t technically an issue.
[]Any changed files need to be sync’d (or at least copied) to the remote nodes from the main node.
[]Here’s the part I feel could be done better: Inside functions.include.php the line “$command=”/sbin/ifconfig eth0 | grep ‘inet addr:’ | cut -d: -f2 | awk ‘{ print $1}’“;” is actually executed on the server side. When I started working on this, I thought it would execute on the client side. The end result is that it still finds the correct subnet, but there has to be a better way to do this. At the very least, all of the array functions wouldn’t be necessary. You could probably just compare full IPs. I have a couple ideas for more sophisticated changes, but I haven’t gotten to test them yet. The joys of being a full time student and trying to do all this in the middle of an IT support internship…
[]So, in order to get this to run correctly, I ran into a few problems – since the folder containing the boot file “default” is being mounted on remote nodes, and since the boot files for specific MAC addresses are also in this location on the main node, I had to keep this mounted. The change involving overriding the “web” variable in S99fog inside init.gz is a workaround. A bit strange, but it works. I need to work out a solution to unmount those drives, and get the specific boot files placed in the right location in the first place. Shouldn’t be too difficult, but I haven’t had the time.
[/LIST]
Let me know if you run into any issues, and I’ll help you the best I can. I’m definitely not a FOG expert, by any means, but I’ll try.
[url=“/_imported_xf_attachments/0/303_fog_location_changes.txt?:”]fog_location_changes.txt[/url]
Yup! … Well, sort of. I don’t really do the delegation - it just picks it automatically based on the subnet. I’m actually at school right now, and all my FOG notes / custom changelogs are stored on my work computer which I don’t have with me. It actually ended up being slightly more complicated than just a few changes.
[url]http://www.fogproject.org/wiki/index.php/Multiple_TFTP_servers[/url] <---- this is a good place to start. I have two remote nodes that both started with this setup (almost - my rsync setup is slightly different as I have more files I want to synchronize than suggested).
Off the top of my head, I know it’ll take edits of about 3-4 PHP files, as well as a change somewhere to ensure that the bash WEB= variable set by the boot files is correct. Maybe. Currently I have it set up so the node you PXE boot through is the node that gets chosen, but it gets chosen in a strange roundabout sort of way. I might actually do some rework to get it working in a way that makes more sense, now that I actually know what’s going on.
Got it. I’ll have to do more testing to verify that I haven’t broken anything going on behind the scenes, but if anyone is interested, drop a post here, and I can put together what I had to change to get this working.
On a side note, question for someone who knows more about PHP than I do (which doesn’t take much at all, haha) - what’s the purpose of using the underscore in echos? As in the underscore in the following line after the echo:
[PHP]echo _(“Error attempting to start imaging process”);[/PHP]
No bites yet, huh? 
Okay, more digging!
I found that the item fog.tasks.taskNFSMemberID in MySQL (which corresponds to the StorageNode, if I understand it correctly) [I]is[/I] being set correctly. I added in some var_dump() and some sleep() into functions.include.php so it wouldn’t fly by and I could actually see this.
Essentially, the correctly overwritten storage node is being placed in fog.tasks.taskNFSMemberID – [I]but! [/I]-- when the computer to be imaged is restarted and booted to pxe again, the taskNFSMemberID changes. Looks like some code somewhere (probably Pre_Stage1.php) is overriding the taskNFSMemberID. I’ll have to spend more time looking when I get a chance.
Well. Did some digging. So far no luck. I [I]thought[/I] I had a solution – but maybe someone here on the forums can help me out.
The file auto.register.php calls the function getImageMemberFromHostID (from functions.include.php) which in turn creates and returns a $member object. $member is created with parameters that include $nodeid (which comes from the MySQL database -> fog.nfsGroupMembers.ngmID).
After some testing, I know I have the logic behind my IP collection / string splitting / etc working correctly. I originally thought that was the problem.
My question is this: Is the $nodeid variable stored inside $member functional, or has it been depreciated? As in, is that where FOG determines which node pushes the image to the computer?
Thanks for the link Kevin – I had taken a look at that, and I was hoping to get away without completely overhauling the MySQL databases. Wishful thinking, I’m sure, haha. I was going to attempt another route, after looking at the number of files that got changed. I’m currently running FOG 0.32, and I believe that patch only works with 0.31 (or that’s what users were reporting in the thread, anyways).
I was considering doing it that way, Bryce. Or alternatively, just working with two FOG servers and using rsync or something to push the image files back and forth (or changing the fog replicator service to grab more than just the /images/ folder). But that way just seems like way more of a hassle in the long run, haha.
I might dig to see if I can find where the group selection is in the code, and see if I can hack it apart – assuming I can find the time.
I have a question to add on to this thread (which is related) – What about if the images for the remote office are the same as the images for the local office?
How does FOG handle which storage node gets selected to push the image out? Would there be a way to, say, force the client to connect to the remote storage node which is on the same subnet as the client?
I’m sure I could put together the code to determine IP/Subnet on the client, but I don’t know enough about how the storage node gets selected to move forward at that point, or if it’s even a reasonable possibility.
I’ll throw my hat in the ring here and suggest considering other options as well. I have a pi which I use at home, I manage a FOG server at work, and I think combining the two would be a relatively painful experience. Especially considering your point b).
Thread resurrection! This actually happened to a member of our IT department again, today.
Has anyone else ever run in to this problem? Some possibilities of causes:
Still pretty stumped. Anyone think any of those options would have temporarily caused the secondary drive to be read as /dev/sda?
That’s a good point - if you don’t care about them being registered in the FOG database, that should work great.
Try it without the tftpboot listed in the kernel line, maybe?
[CODE]LABEL ubuntu
kernel ubuntu/12.10/casper/vmlinuz[/CODE]
I’m just guessing because I’ve never tried booting to the ubuntu live cd, but the structure of my default file doesn’t include the tftpboot folder in the kernel line. I wonder if it’s looking for a file located at /tftpboot/tftpboot/ubuntu instead of /tftpboot/ubuntu because of it.
[quote=“BryceZ, post: 10239, member: 2”]As I understand it, 0.32 can handle both scenarios with and without the 100MB partition.[/quote]
Yup, I can confirm this. Currently we’re doing W7 with the 100MB partition, but we were doing it without the partition just a couple months ago.