Topics created by Jarli

@ITSolutions said in Adding larger partition:

Edit: Sorry but I am not a linux “expert” and not great with fedora in general, usually on debian/ubuntu distros. But I think I see what the issues seem to be.

So I am assuming you have /run/media/root/fedora-expanded/images and /run/media/root/fedora-expanded/images/dev?

Have you tried this article https://wiki.fogproject.org/wiki/index.php?title=Adding_Storage_to_a_FOG_Server?

If you want all of your images moved to this new spot and not have the original location it maybe best to set it up like this and make sure the mount points are /images and /images/dev otherwise you need to make many more changes to make everything work. It sounds like just changing your mount point would be easiest and best now that everything is moved to your new drive.

That did the trick.

Thanks.

Thank you @Tom-Elliott

Got it fixed.

The Storage Management password was goof’d.

Corrected it to match, and it completed the TFTP upload.

Update,

Appears to be the cable, yet we’ve been using this same cable to image all of our other machines. And the device is still capable of pulling DHCP using this ethernet cord. . .

Nothing like a bad cable

[quote=“Wayne Workman, post: 46752, member: 28155”]Also, if you used user-based enumeration shares (windows server 12 and up), you can specify encryption of the redirected user data on the server itself, and have the user files NOT EVEN EXIST on the local machines. That’s how my environment is set up. It’s done through GPOs.[/quote]

That too is how we have ours set up. I really, really love not worrying about someone’s files when a drive dies anymore.

the default size for jumbo frames is 9000. So you send 1/6th the number of packets, less headers and tail relative to the amount of data being sent. The real saving is the time it takes to get on the cable, as you’re transmitting a 1/6 of the number of frames for the same data, you save on the time to transmit. you also do 1/6th the number of mac checks, so it lowers CPU usage, unless you have a TCPIP off load card.

Always enable it with iSCSI, but check the “path” all support jumbo frames.

Hope it helps

Network boot does work from the local drive on the server.

It fails to work from the iSCSI drive though. We’ve copied, and confirmed the permissions, confirmed the drive settings Master and active etc.

It continually times out at TFTP. swapping the master drive back to the internal hard drive, imaging works. (within the fog storage node administration)

the image folder would apply to one image. the images (note the ‘s’) would be all images.

It can be yes.

You could make a NAS or SAN that automounts to the FOG server in the /images location as well.

Now the million dollar question Junkhacker, is it worth setting up a GParted iso to boot into so that I can format drives automatically.

Or just keep a cd for it… 😛

Well my thought to this has a few folds.

Firstly - If we don’t have a fog server that is functional I can deploy to new hardware from another machine.

Secondly - This backup fog server could be used to create regular “Server backups” so that I have a fail-safe to our existing DRP.

Third - It gives us a piece of mind that if we screw up our production environment that all we’d have to do is reimage our current server and be back up and working, and able to image any of our devices with minimal interruption.

if you have it enabled or disabled is up to you

We are now looking at these, thank you for the guide.