Thank you, I am not sure my first image was 433Gig and my second was 45Gig. I did nothing different. I am glad to see the file size has decreased.

Ben

Thank you!

Woot Woot.

Tom has fixed the issues and I am 100% up and functioning

@cml

Well, I tell them that I took the time to try the ISO CML … and the truth … it’s very nearly what I need … exept for a question … if I need to install 10 pcs at the same time, having this ISO on a flash drive … it could perform smoothly … nor any conflict with my dhcp ??? From what I saw, putting the direction of the mist, it goes directly to the …

I have to get the hat !!! Spectacular !!!

Surely … I will continue to consult for further progress and learning!

Thank you very much !!!

All links to the old wiki should properly redirect.

For future readers,

to test without using the debug deployment (just using a LIVE CD instead),

inside /etc/exports on the FOG server,
Set the fsid for /images to 0 and /images/dev to 1

Save that, exit that, then run this:
exportfs -a

(got all that info from Tom)

Expect a completed “Troubleshoot NFS” article soon!

And some of my terrible artwork for Tom, too. lol

Aha! Thanx Jbob. I swear I clicked on it before and it gave me a `you can not upvote your own posts’. I must have slipped onto the ^ voting symbol.

< edit >
… and the crowd goes wild.

@Wayne-Workman

They aren’t static, but they do retain leases for a long time. At the campus here, the ICT services department control the DHCP server that gives our machines their IPs and the DNS servers. We have some control (over AD groups and users and group policies and - to a degree - our switches and physical infrastructure) but not when it comes to DHCP/DNS operation. So we are stuck with IPs.

Which is fine, we can find which PCs are which IPs. I would have thought that a host could identify itself when the FOG service first starts and update its record that way, but I wouldn’t have thought NetBIOS pinging was really the way to go for communication with hosts when IP and MAC addresses are used for everything else.

It was adding the * that helped get these going, thanks Deastrom!

I get it. It’s just that there are some new features in Fog that many of us can’t use because they don’t have that stamp of approval.

[quote=“George Stewart, post: 47485, member: 29650”]Thank you for the responses.

I am using the location plugin, but I have only one location. I’ve named this “main”. I have a dedicated 10 gig connection between my sites ( fiber ). One site can see the fog menu, register a device but fails (just reboots) once the image starts to pull down. My other site can’t boot to the fog system at all. I’ve ruled out the patch cables or switches being a problem as they are the same at all of my locations (gigabit switches). Should I setup additional locations at these other two sites and push the location\replicate the images down to these other sites? Just don’t want to go that route if my dedicated fog server here at the main location can handle this for me already.[/quote]

You only have one PHYSICAL location, but do you have V-Lans, or seperate broadcast domains configured? Is your location sub-netted?

The location plugin only needs to be used if you have logically separated networks segments.

If everything in your organization is all in one nice-simple network and on the same broadcast domain, you can just configure storage nodes if you like, or just have 1 FOG server, and nothing more.

We managed to fix this. We had to go into the FOGClient config.ini which is located in the etc folder of the FOGClient installation folder. We had to change forcerestart under the taskreboot from 0 to 1. That’s all. If anyone has wiki access to change the Client setup page, please be sure to include this.

The new clients will need to reboot to cycle their encryption keys, but other than that should shouldn’t be an issue.

[quote=“Julianh, post: 47352, member: 24986”]Thank you Tom, I’ve been imaging 2008 & 2012 servers, using windows 7 as the OS. I was a bit puzzeled as to why it was working! All installs should be MBR.

Is there a way of taking a raw image of the BCD data?

The OS I’m Imaging is, not windows, and am prepared to “pay” in storage such that, I take an image of the server, then send that same image down to the same machine. I’ll repeat that for each server. I know it’ll be heavy on the storage. Some of the OS partitions are fat16, so I want to use the features of fog for,these partitions, rather than use a “raw” image

Thanks for your help

Yours

Julian[/quote]
OS “other” and non-resizable is what you’re looking for, by the sound of it.
out of curiosity, what OS is it?
fyi: fog has built in detection and support for ext 2, 3, and 4, ntfs, fat, hfsplus, and uses raw for what it can’t detect. so, you’ll probably find that the image takes up less space then you think.

Thanks, I will test this out incase this issue comes up again. My colleague was able to get a license from a reseller of the old application.

[quote=“Trevelyan, post: 47309, member: 7471”]Is it just avoiding possible data corruption, or certain data corruption? I haven’t seen any ill effects of not changing, to be honest. I’ll keep going without changing it but keep it in mind anyway. Thanks for explaining it! :)[/quote]

potential.

If the syntax is similar to yum, we could make a temporary alias to change out yum to dnf. I don’t imagine the installation of packages would change too much.

I’ve never used the reporting functionality in FOG…

I’d personally just fire up an SQL client, connect to FOG, do the query for the data I want, dump that into a Google Doc, and format it up nice and pretty.