Fog_Newb

Fog_Newb

SOLVED

I was on 18.04 and ran “sudo do-release-upgrade -d”, It finished, I rebooted and was able to access the FOG web interface and deploy an image. I am running the latest stable version: 1.5.8

UPDATE: I had some issues when I upgraded to 20.04 on a different FOG box. It has been resolved.

Thanks

Fog_Newb

@sebastian-roth The error during the FOG install on 21.10 is related to installing php 8.0 mysql

Error

If I try to manually install php8.0-mysql it appears to be installed already

Already installed

The GUI works fine and capturing an image goes smoothly until the end where the database needs to be updated

Wow, so I ran the FOG installer again, this time there wasn’t an error when it came to the mysql install.

All good?

Going to try capturing an image now.

Hmm. It still fails to update the database.

Failed

Fog_Newb

@Sebastian-Roth

Yes.

I just want to add real quick, the DC 7800’s can boot to the menu with any kernel and without and kernel parameters. They fail when deploying.

Fog_Newb

I installed the leaked dev version 21996/21996.1 on bare metal and in a VM. Secure Boot didn’t have to be enabled . UEFI and TPM (which requires CSM to be disabled) had to be. Secure Boot - the option only had to be present.

After more testing. I found I could install it in a VM as Legacy. I guess MS laxed on the VM requirements?

I also found on metal, I could disable TPM and enable CSM which should make secure boot completely unavailable. Then I deploy a sysprep-ed Win 11OOBE UEFI image on it without any problems.

I will try pure legacy on metal next…

This was with that leaked dev build so who knows if it was modified or what not and how close it is to the actual dev build release or the final release.

Fog_Newb

3.13 that comes on the latest dev-branch as of today has issues with APFS on my laptop.

3.20 x64 does not

Fog_Newb

@Sebastian-Roth

Hell yeah dude, that cleared it right up.

Fog_Newb

@Sebastian-Roth

Not sure if this has been resolved or if this helps -

I’ve created a Win 10 UEFI VM using the 2004 ISO. VMware Workstation 15 Pro 15.5.6 build-16341506. All the settings were default except I went up tp 8GB of RAM. I installed it, ran all the updates, activated it while waiting for updates, rebooted twice then captured the image with FOG dev-branch version: 1.5.9-RC2.11 running on Ubuntu 20.04 LTS

It deployed fine to a similar VM.

Fog_Newb

@sebastian-roth Thanks. I just updated to the latest. So far it is capturing an APFS drive on a hackintosh no problem.

Fog_Newb

@Sebastian-Roth

So yes, this is a perfect solution since Primary host disk can now be set by size. I have one image for the OS disk, and one for the “D” drive. I just switch the Primary Host disk setting depending on which image I want to capture or deploy.

Fog_Newb

@george1421 I boot from a FOS usb stick that pxe boots to the FOG server. So I am thinking put the T2 Kernel on the server and specify that kernel under the “host kernel” setting for the macs, then on the the FOS stick put the t2 kernel as well?

Fog_Newb

@Tom-Elliott All good with 1.5.10.1629

Thanks

Fog_Newb

After updating from 1.5.10.1622 to 1.5.10.1625, I went to capture and image and got error message in the subject. Then I saw After updating from 1.5.10.1628 was available so I updated to that, same thing.

What do?

Fog_Newb

@JJ-Fullmer @Tom-Elliott

I’ve found a work around. I now have /images on USB HDD passed through the to VM. When I run a standard back up of the VM via the VM software (Virtualization Station), it only back-ups the OS VM drive.

For the /images drive - I use a sync program to back-up the files, not the disk .

Fog_Newb

I thought I’d posted about this before but it doesn’t show up in my post history. After capturing an image, Image Size ON SERVER shows as 0 or sometimes 1GB/MB. All the partitions and other information were captured successfully in /images/[imagename] and are the correct size. Once the FOG server is rebooted, Image Size ON SERVER displays correctly.

Thank you

Fog_Newb

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

How big of an issue is this disk size inflation for you?

It’s not a big deal. I’ve since stopped capturing non-OS drives and now use file sync / mirror program to back those up. I actually like that better than huge image captures once a week. Currently, FOG is just capturing 2 relatively small OS drive images.

All this is running on a QNAP box someone gave me and QNAP’s Virtualization Station software is lacking features to cleanup/shrink or compact virtual machine disks.

This all started out as a Feature Request

https://forums.fogproject.org/topic/17651/local-time-and-alternate-temp-directory-for-capture-option

It’s odd that linux/php are having this limitation but that’s where we’re at.

Is this something the devs would change if it was brought to their attention?

Thanks

Fog_Newb

@Tom-Elliott

Ok I think I have it set up how you asked

New mount points

see

see1

see2

Symlinks

see3

see4

Gonna try to capture will report back

Same thing.

err

Fog_Newb

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

@Fog_Newb I think I found the problem.

Normally the ftp_rename command successfully handles moving the captured image from /images/dev to /images but for some reason that command ( a built in php/ftp thing) doesn’t like it when the directories are mounted on separate disks. Not sure why, doesn’t make a ton of sense, but that’s the issue.

That makes sense to me especially if that command is only able to rename.

Basically I think you may have found a bug in a failsafe method for uploading a captured image.

Cool cool?

Fog_Newb

@Tom-Elliott said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

I will definitely try this. Just to make sure I understand how you want these new directories mounted…

sudo mkdir /images1
sudo mkdir /imagesdev1

Then adjust fstab so ‘/images1’ is a mount point for one drive (where /images was mounted), and ‘/imagesdev1’ is a mount point for the other drive (where /images/dev was mounted. Mount them, once mounted then I do…

After mounting these, new mount points, everything that was in /images and /images/dev is now in /images1 and /imagesdev1

sudo rm -rf  /images
sudo rm -rf  /images/dev
sudo ln -s /images1 /images
sudo ln -s /imagesdev1 /images/dev

Then capture an image and see what happens

Fog_Newb

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

@Fog_Newb I am able to recreate the problem in the latest stable version (1.5.10.1615). Working it out. it looks like the image does stay in dev on my end.
I’ll debug this when I can this week.

Awesome. Thanks.

Then you could at least manually move the image from dev to images to workaround the issue while we work this out.

I have another FOG server set up where /images and /images/dev are on the same drive so I can continue using that until things get sorted.

Fog_Newb

@JJ-Fullmer said in FOG has issues if the temp image location is on another drive. FOG 1.5.10.1612 Ubuntu Server24.04.1 LTS:

@Fog_Newb Fog is creating NFS shares from your 2 disks at those mount points. If they were not shared, imaging would not work. On the server the paths are mounted to different disks. And then each of those paths are shared, you can see this if you run cat /etc/exports where the shares are defined.

Oh I see
see