Posts made by ENorum

Ok, found the problem. I didn’t realize that one of the other guys had setup the 2 boot options in the Superscope options and I was setting them in the Scope. This has been sorted.

Sorry to waste your time and thank you for the quick reply.

Then in the scope options we have the undionly.kpxe option set.

Fog Version 1.4.4 btw

So I am unable to get fog to boot using UEFI. I get the following error:

This comes up EXTREMELY quick, I had to record it in 120FPS with my phone to catch it and its only on the screen, partially, for a couple frames.

After that error, it just drops back to the boot menu, or continues booting normally.

I have tried multiple systems, and I have double checked the DNS settings, but if its getting the file, I don’t think the problem is there.

and I’d rather not give them access to the webui.

Sorry, I forgot to mention, their only access to these machines is via RDP, hence the reason I’m looking for a script they can run from Windows. Looks to me like the API is probably the best bet for now.

Server

• FOG Version: 1.4.4
• OS: Debian 9

Client

• Service Version:
• OS: Windows 7

Description

Is there any way to queue an image restore remotely?

This is what I’m trying to do, maybe you guys have a better idea of what I can do to achieve this.

I have 3 test machines that our techs are using, they test something, then restore an image from for further testing. I would like it if there was some kind of script they could run that tells fog to queue the machine up for image on boot instead of me having to go to the UI and queue up the drop.

That did it! Thank you guys!

Ok, fixed that and capturing a new image now, but I have to head home for the day. I’ll update tomorrow, but I bet that’s it.

Awsome guys, thank you. Especially you Sebastian for wracking your brain over it!

Had that problem, moved the server and added more diskspace 6 months ago.

Yeah, sorry. Not really familiar with Linux. I was able to move files and folders around in those folders.

@sebastian-roth Sorry, yes, using an FTP client.

And yes, I can perform all of those actions using the FTP client.

So went through and checked permissions on all of those folders, they were good.

Went through the FTP troubleshooting article, found that the FTP service was misconfigured, I was able to connect and authenticate, but not able to send files to the server. Found the vsftpd.conf had a line that we needed that was commented out:

Uncomment this to enable any form of FTP write command
write-enable=YES

So fixed that, so now I’m able to connect, authenticate and send files to all of those directories.

However, fog still fails with the same error message.

Server

• FOG Version: 1.4.4
• OS: Debian 9

Client

• Service Version:
• OS: Windows 7

Description

After not using fog for a time it will no longer capture images. It gets all the way through the capturing process and then fails with this error:

So, figured its a permissions issue, checked those, didn’t see any problem. Was able to FTP to the location and grab the specified file with the same credentials.

Got fed up with it, and set permissions to 777

Same error. I’m at a loss. At this point I’ve updated Fog (started with 1.4), updated/upgraded Debian (started with 8 ), messed with all kinds of permissions, including removing the account and re-adding it. I really don’t want to have to start over and reinstall everything.

Whats most frustrating is I had the same problem yesterday, and resolved it, but today back to this problem and now I can’t fix it.

Thank you for the response.

I ended up going back and comparing the file to another one I downloaded on another computer, and they were different sizes. Moved the new one in and it was able to mount fine.

Server

• FOG Version: 1.4.0
• OS: Debian 8.8

I’m following the Wiki on making a DBan option in the boot menu and I’m getting to the last line of getting the ISO mounted in the OS.

I’ve gotten to the line which is as follows:
mount -t iso9660 -o loop /iso/dban.iso /var/www/html/dban

When I try that, the error returned in:

dmesg | tail returns:

I’ve looked all over and haven’t been able to find anything that references a similar issue. Most of the time people point to a bad iso, but I’ve downloaded this one multiple times and have even burned it and used it. So I’m at a loss at this point. And it doesn’t help that my linux skills are weak at best.

Ok, so it looks like the default image engine was changed. Once we got the images added to the system and changed them from PartImage to Partclone Gzip they started deploying correctly.

Thank you Tom!

Thank you for the response!

https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG - So I did this, and ended up with a lot of problems, which is why we went the manual move of the images into a fresh, empty install.

https://wiki.fogproject.org/wiki/index.php?title=Migrate_images_manually - I didn’t see this one, and forgive me as I’m really not familiar with linux, but this looks to just move the images to the new server? If so, we’ve done that. They’re just not showing up in the management screen.

Server

• FOG Version: 1.4.0-RC-9.2
• OS: Ubuntu 16.10

Client

• Service Version:
• OS: Windows 7, 10

Description

So we’re migrating our fog server to a new VM. Coming from Fog version 1.2, haven’t had any luck with exporting and importing the DB, so we went with a fresh install and I was moving the images manually. However, I’ve been running into issues with this as well. Followed the instructions listed here: https://forums.fogproject.org/topic/6441/transfer-images-to-a-new-system however the images don’t restore. They do something, because the Windows install that was existing on the machine I went to restore to is no longer working. Exits with an error code 1, which, if I read the description right, means that the image is larger than the HDD, which isn’t the case.