Posts made by Tom Elliott

r1136 released.

Partclone upload tasks (multi-part) uploads the correct (hopefully) for the partition.
ext{2,3,4} = partclone.extfs -c
ntfs = partclone.extfs -c
fat{16,32} = partclone.vfat -c
anything else (for now) uses
hfp,btrfs,xfs=partclone.dd
(It’s important to note that partclone.dd does not require -c option in upload, which is why I’ve labeled them as you see above.)

Should help with the Win 8 differences in partitions.

Deploy tasks are done with:
partclone.restore rather than partclone.${fstype} so we know it restores using the correct type, rather than having me guess which are which.

blkid updated in the init.gz to allow displaying of the partition types/uuid/etc…

Minor changes, again, to fog.css to allow display of the kill icon’s. I must have made an accidental edit to the file, but it broke something. It’s fixed now.

I have not, yet, implemented gpt stuff, but will get on it. I don’t have anything to test with, so I’ll be guessing, using of course other people’s suggestions.

If that’s the password you’re referring to, Shane is absolutely correct. This is the password that asks as soon as you make a selection on the PXE Boot Image? Meaning the menu is displayed behind it asking for the password?

Or is this the password it asks for after you’re in the menu and it asks you for the username and password? If it’s the one asking for User and Password, it’ll be your fog web gui information as I stated before.

@Shane
The queue system does more than just mc. Multicast may have a queue, but not that I’m aware of. If you have, lets say, 10 computers to image (Unicast) and you’ve only got 5 slots, the last five in the task list will wait until the slot’s reopen spawning the Checking queue.
That, however, can also be created by a misconfiguration in the file system. Though you’d have to be watching the error log on the fog server to be sure.

The quick image password should be your fog user from the database. (The same one most people use to log into the FOG Web GUI.)

r1134 released. Fixes many service things. All seems to report properly now and supports the hosts that have multiple nics. As long as the macs are registered with the host in the fog gui, all should work properly. (Meaning wireless stuff should work as well.)

On the client, there is the one I think is more a problem with how fog determines the directory structure. It tries to find the alo-bg.png file from c:\program files\fog\images\alo-bg.png, but on 64 bit systems the real location is:
c:\program files (x86)\fog\images\alo-bg.png.

I’m still working on the other errors, though I think they’re ok, for now. Still trying to figure out how Usercleanup is supposed to work.

access_log is not an error. It expected so you know what people are accessing. It’s how I figured out snapin’s weren’t working.

It’s also how I was able to determine you had multiple NIC’s on that system.

Yeah, sorry still tweaking things out so i didn’t post the release.

Have you given this a shot? it seems to work on my end.

Don’t worry about it right now. I’m reuploading another revision which should separate the file.

Let me guess, you have multi nics on the system?

No prob with the language, it’s fine. It says Permission denied.

Make sure the storage nodes /images directory contains the .mntcheck file, and is recursively owned with 777 perms.

[code]touch /images/.mntcheck; touch /images/dev/.mntcheck; chmod -R 777 /images[/code]

What’s your fog servers accesslog display for the snapins.checkin.php stuff?

r1132 released.

Rewrite of the servicemodule-active script. Multiple snapins in deploy job works now. Error codes should be fixed.

No, if you look at the access.log on your fog server, you can actually see the command being sent. I think, in my testing late last night, I set up different error tags to see if I could get things working, or see where they were failing. #!im was the error as it was easily identifiable. I may have forgotten to remove it from the snapins.checkin.php. I’ll be updating here shortly.

That probably won’t work, but I’ll add it to the init.gz when I get a chance.

I don’t know, what kind of errors are you getting now?

I’m currently working to fix multiple snapins to be deployed, so it could be that’s broken at the moment. I only got individual snapins working.

xz -C crc32 -z -c init > init.gz (I think)

That said, I don’t think that command will work.

extfs, ntfs, hfsp, btrfs, xfs are the partclone binary names. so if i read your script right, if it comes up as ext4, it’s going to try partclone.ext4 which is wrong.

Snapin tasks now works.

r1131 released.

r1130 released. Should fix snapin tasks. Changes title for Pending Macs. More service fixups.

You are not wrong, I just had my order wrong.