I need to deploy the image I created from the virtual machine (legacy) onto uefi is that possible or do I need to create another image?

@george1421 Okay so 19.1 seems to work great, on my desktop. The only thing I had to do different was change the permissions on the 19.1 folder since it locked it down to root but that was most likely from me running the terminal in “su” I’m guessing.

For some odd reason the laptop I’ve been using to test these does not want to boot it still and I am not sure why, it boots the Windows and Debian installers fine which is odd. It is plugged in with an ethernet cable the same as the desktop. I’m guessing this may have been giving me some of the issues in the past but I did double check on my desktop before posting and it was not going in my case.

I must be missing something in Mint 19 v2 but I’m not going to worry about it at this point since 19.1 is working great. I am doing the install right now and it so far is having no issues.

Thank you for all your help and if I figure out what the issue is with the laptop I’ll be sure to share in case anyone else happen to come across a similar issue.

Cheers
Ben

SOLVED
Thanks guys, once the certificates were copied to the fog2 server, AD join started working

Yay 🙂

@Sebastian-Roth yes, the esxi host has a NIC on each network. I am attempting to get the network to allow access to an single IP in the management for each lab so I can just use the 066 DHCP option to point to the interface that works for TFTP which I believe is the way the guys that are doing similar setups are making it work.

@jameto333 I have a little experience in installing similar programs with snapins and am familiar with Sketchup Pro. May I ask which file format you have the installer (exe or MSI)? Also, may I ask which type of licensing you have?

Hi @linuxba ,

I have the same esnario in my university. I can tell you a workaround to solve this or how we solve this problem in our university.

Create a complete image of your dual system:
Imagen name: Dual_Image
Image type: One disk not resizable
OS: windows 10
Partitioning: Everything Upload it to the server. FOG will create you a new folder in /images, in this case:
/images/Dual_Image
This folder has the different partition files, for example: d1.has_grub d1.mbr d1p1.img -> UEFI or boot partition d1p2.img -> windows system d1p4.ebr d1p5.ebr d1p5.img -> Ubuntu parition d1.partitions Now we will create a new image definition:
Imagen name: Ubuntu_Partition5
Image type: One disk not resizable
OS: windows 10
Partitioning: Partition 5 This step in not necessary but I recommended you. Assign this image to your PC and upload this image. In this way FOG will create you the folder in the server, /images/Ubuntu_Partition5. Connect to the server via ssh cd /images/Ubuntu_Partition5. If you don’t do the 4 step, you need create the folder and give permission 777. erase the file d1p5.img and do a soft link:
ln -s …/Dual_Image/d1p5.img .
You can do, if you want, more soft links to the other files: d1.has_grub, d1.partitions, …
With this method, is a little rustic but practice, you only manage one image, Dual_Image, because with the links the Ubuntu_Partition5 is updated automatically.

In our university we have windows images and dual images, with different disk sizes but, at last, the d1p2.img and d1p5.img files are always the same. Updating the windows images and ubuntu images, I update all images versions (for small disks (160GB), big disks (500GB)).

If you want to recovery only the linux partition in one PC, assign the Ubuntu_Partition5 image to the PC and deploy it.

@elementalwindx said in First time FOG user needs help:

I’m used to just uploading a couple .wim files

Well we were spot on until I hit this line. WIM files are windows only (there are wim file readers for linux but they are not as efficient as Partclone that FOG uses). To use FOG you need to capture your reference image with FOG if you want to deploy with FOG.

The core differences between MDT/WDS and FOG is that FOG is a (disk) block level cloning tool where MDT/WDS is a file level cloning tool. Both have their advantages and disadvantages. Generally block level cloning is faster than file level cloning. For reference I can push out a 25GB fat image to a target computer is under 4 minutes. Or to say it another way I can go from a bare metal system to a computer running windows setup/oobe is about 6 minutes. Then depending on the system OOBE runs for about 11-16 minutes. So roughly more or less 20 minutes from bare metal to a workstation ready to move to the user’s desk. Try doing that with MDT/WDS or SCCM. Understand there is a lot going on here outside of FOG (which is involved with imaging for only 4 minutes of the 20)

I have a tutorial that shows how to boot most other OS kickstart images (ISO). There ARE posts in the FOG forum that show how to boot Hirens iso images too. For your windows deployment its best to build a golden image and deploy that instead of trying to load windows setup via fog (which can be done). The rest of your requirements are already built into FOG’s base code.

ref: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

I would admit you are absolutely correct. I should not have put the local admin into the group…

I was finally able to get back in. I appreciate all of your help!

@NT_Tech Access control is a plugin now which has much more use than the “mobile” vs “non-mobile” account.

FOG was indeed a single user system, from it’s original startup. The only thing that kind of made things different was the mobile interface.

I want you to understand, mobile interface was it’s OWN element from the main interface. This meant having to update two GUI platforms to ensure all functionality was maintained. When moved to a single interface that could do both mobile and full screen usages, I removed the “mobile only” user type.

I want to stress, while it wasn’t necessarily intuitive, even in 0.32 a “mobile only” user had exactly the same level of usage as the full admin users. The GUI access was limited and didn’t allow a mobile only user to see anything, but a mobile user could delete items, change things, etc… if they knew the url pathing and calls. They couldn’t see it, but it was not “limited” in the way you thought it was. As the access control plugin was created and managing a single interface made updating and keeping things in a more testable and common way, I decided to remove the “mobile only” option. This was not intended to hurt people who were using the element, but rather there were better things in place that did far better at controlling the scope of things and in a more granular and appropriate fashion.

@george1421 Thanks, with this commands above i was not presented to enter password, thanks.

@Sebastian-Roth Sorry, I completely forgot about this. Just updated to latest kernel on my server and tested on 1803, worked perfect. Thanks for the update.

Your dnsmasq configuration is not complete. It only addresses bios based systems. My recommendation would be to follow and use the dnsmasq configuration from this tutorial exactly. Don’t just patch your’s to match: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

I just tested using my api token for slack running the working-1.6 version of fog and am not seeing an issue.

Hi,
I want to add that I have done some changes in the reports, imaging log report too, to make pre-filters and not shows all the registries.

For example, in the imaging log report you can do a a prefilter by image name, user name or hostname. In this way, the result is more small and you don’t need erase registries in the database.

The new version of the reports are available in the “working” branch

@6rilT Just creating the rule isn’t enough. You need to assign the rule to a role. Users and rules are associated roles.

Name them with the number they require in the group.

Eg 01-snapin, 02-snapin, 03-snapin

@deckerta As well you might want to check out this wiki article: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

It’s all not a click by click thing but I’d say you can learn a lot of things if you are keen to. We’ll definitely help you. Just ask specific questions, post error messages and we sure will be able to guide you the way.

@lepage said in Is it possible using fog to restore only part sda2 ?:

I am not sure if you can see it … but from the filesystem when I do ls d1p* I see
d1p1.img d1p2.img d1p3.img

Absolutely. I know exactly where you are coming from. Yes it would be possible to implement. But can you see it from my perspective as well? Why implement it to enumerate the image files if it holds the truth only in case the image is still captured? Don’t get me wrong. I am not saying it wouldn’t be nice but as of now we have so many other things to fix in FOG and not many people helping that I can’t see us doing this. Sorry!

If you have time and knowledge you are most welcome to add the feature and send a pull request on github. 🙂

@george1421 Mixing up TFTP and HTTP URL here? Might be confusing.

@GrandIQ said:

... http://${fog-ip}/fog/images/...

Please make sure those URLs really work! Simply open them in your web browser and see if it would start the download. I fear it doesn’t because we have some URL rewriting in FOG active for the API backend to work. You probably need to move your images to a different folder further up, like /var/www/html/images/win7/... (URLs: http://${fog-ip}/images/win7/...).

@Fernando-Gietz I like that idea. Even if it is still error prone, it’s make things simpler overall. That could open snapinpack for tarballs too I would suppose.