Posts made by Fog_Newb

@AUTH-IT-Center

Thanks -The fstab paste is below. The parameters are correct as far as I can tell and they were added by Ubuntu during the install. And it appears both /images and /images/dev are mounting correctly and accessible since FOG was able to capture to /images/dev and create a file in /images. I was also able to manually create files and directories in each mount location without any problem. If you see something out of place feel free to let me know.

On my other FOG server, where there is only the 2nd drive, and it’s is a mount point for /images, it uses the same fstab parameters (albiet different UUID) and it has been working fine.

@Tom-Elliott

Yes, I even spun up a new FOG VM where the mount points were created before FOG was installed to makesure the FOG installer created all the files and set permissions.

edited - words

@Tom-Elliott

Quick TLDR. incase my word salad OP doesn’t make sense.

If /images/dev is on a different mount point than /images, captured images will remain in their temporary location in /images/dev and a directory for the newly captured images with not be created in /images

Thanks Tom,

Everything you mentioned is what I did on my existing FOG server. And the same problem occurs on a freshly spun VM I set up just to make sure I didn’t miss any files or permissions from the original /images/dev location

The images in the OP are from the new VM. All mount points were specified at the beginning of the Ubuntu install - fstab created by the Ubuntu installer (see code below). The files and permissions on the /images/dev mount were created by FOG.

I still have it up if any logs could be of help.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/vda2 during curtin installation
/dev/disk/by-uuid/078f54eb-340b-41fc-ab34-1494cd59e4e4 / ext4 defaults 0 1
# /boot/efi was on /dev/vda1 during curtin installation
/dev/disk/by-uuid/DD22-44A9 /boot/efi vfat defaults 0 1
# /images was on /dev/vdb1 during curtin installation
/dev/disk/by-uuid/d61ab2ae-b79a-4b07-bfc5-4678ab0902f4 /images ext4 defaults 0 1
# /images/dev was on /dev/vdc1 during curtin installation
/dev/disk/by-uuid/3d7874cb-8c59-4e6d-8735-fb8361994590 /images/dev ext4 defaults 0 1
/swap.img       none    swap    sw      0       0

This is long. My FOG server has /images as a mount point for a 2nd drive. Everything was working fine. The /images mount was set up prior to installing FOG.

With FOG storing temp images in /images/dev, it was really inflating the disk space on my VM drive. As some of you know, with VM drives, the size of the drive increases as data is added to it.

So I decided to make /images/dev a mount point on a 3rd drive. I made sure to copy all the exiting files and permissions from the original /images/dev.

After re-capturing an image, I noticed something peculiar, The temp image remained in /images/dev and the directory where that image was initially stored (/images/NAMEOFIMAGE), was no longer seen as directory. But it wasn’t a symbolic link either. This only happened after trying to capture the images using the new mount.

Just to make sure it wasn’t something I messed up copying and setting permissions on the newly created /images/dev mount, I spun up a new VM specifying the mount points during install. Then installed FOG

But… the same thing happened.

It’s looking like FOG has issues if the temp storage location is on a different volume than the images.

I know this isn’t a big deal in the grand scheme of things and most users will never run into this but would be cool if there was an easy fix/change that could be implemented in the next release.

Quick TLDR. incase my word salad OP doesn’t make sense.

If /images/dev is on a different mount point than /images, captured images will remain in their temporary location (/images/dev) and a directory for these newly captured images will not be created in /images

Thank you

@AUTH-IT-Center

Yes, the reddit post is the way the drives were mounted. Just to make sure it wasn’t user error, I spun up another FOG VM really quick and during the installation specified the mount points

Same thing

It’s looking like FOG has issues if the temp storage location is on a different volume than the images.

@AUTH-IT-Center Something weird happened after mounting another drive as /images/dev I made sure to copy everything from the original /images/dev and copy them to the new mounted /images/dev

Then

sudo chown -R fogproject /images

sudo chown -R fogproject /images/dev

After doing this and capturing an image. The tmp image remained in /images/dev and the usual directory where that image was stored, was no longer seen as directory. But it wasn’t a symbolic link either. This only happened after trying to capture the images using the new mount.

Just to make sure it wasn’t something I did when mounting the new /images/dev storage drive, I made sure the directories for the remaining pre-existing captured images were still being seen as directories. They were. I then captured one of those those images and just like that, the directory for that image was no longer seen as a directory and the tmp image for that capture remained in the /images/dev. Weird.

@AUTH-IT-Center

Thanks. I currently have a 2nd drive mounted as /images. That’s is the one that keeps blowing up. I thought about mounting a separate drive as /images/dev (that’s were FOG seems to create the temp files). I may do that and see how it goes.

Hi,
It would be cool to have an option that shows image capture and deployment using local time of the FOG server (not UTC). Another would be an option to specify a alternate temp directory for FOG to when capturing images. This would help keep VM drives from blowing up in size.

Thank you

@Tom-Elliott

Ok thanks

@Tom-Elliott

I’m not. But 8.3 is the only subdirectory in /etc/php

@Tom-Elliott

Thanks. I edited the php.ini under /etc/php/8.3/cli/php.ini and apache2/php.ini. I added

date.timezone = 'America/New_York'

Under the [date] section, saving then restarting and it is still the same.

Like this

Random time stuff related to box

@Tom-Elliott

The one located in /etc/php/8.3/apache2 ?

If so under the [date] I’ve tried adding

date.timezone = "America/New_York"

date.timezone = America/New_York

and just now tried

date.timezone = 'America/New_York'

Saving and restarting each time but it’s still showing captures in UTC time.

Here is a screencap

Thank you

Hello,

I have local time set correctly on the Ubuntu box and TZ INFO in the FOG settings is set to the correct tz. Is there another time settings I need to change?

Thank you

@Tom-Elliott Thanks. Updating to 1.5.10.1581 worked fine.

Any ideas how to resolve this? Nothing was changed on the FOG server since updating to the previous build.

• Setting up and starting NFS Server…Failed to get unit file state for nfs.service: No such file or directory
  Failed!

!!!
!! The installer was not able to run all the way to the end as !!
!! something has caused it to fail. The following few lines are !!
!! from the error log file which might help us figure out what’s !!
!! wrong. Please add this information when reporting an error. !!
!! As well you might want to take a look at the full error log !!
!! in /opt/fogproject/bin/error_logs/fog_error_1.5.10.1580.log !!
!!!

Aug 13 16:35:48 fogger rpc.nfsd[35204]: rpc.nfsd: unable to bind AF_INET TCP socket: errno 98 (Address already in use)
Aug 13 16:35:48 fogger rpc.nfsd[35204]: rpc.nfsd: unable to set any sockets for nfsd
Failed to enable unit: Unit file nfs.service does not exist.
Failed to start nfs.service: Unit nfs.service not found.
Unit nfs.service could not be found.
srossi@fogger:/opt/fogproject/bin$

I ended up restoring a VM image from a few days ago. I am back up on 1.5.10.1578 but not sure how to continue getting newer builds.

@Tom-Elliott Thanks, it seems to be sorted

Last night I did re-clone fresh. After deleting the /opt/fogproject directory then

I did

sudo git clone https://github.com/FOGProject/fogproject.git /opt/fogproject

sudo git checkout dev-branch

Then ./.install - This installed the latest stable release

Just a few minutes ago, I did a git pull and some files were updated and when I ran the install this time, I got the latest dev-branch version: 1.5.10.1566

@george1421 @Tom-Elliott Something is going on with the repository/branches

@JGeear I was getting stuff like this.

https://i.imgur.com/zdqF4q8.png

@JGeear Yeah something is messed up with the branches or something. I got that too. Tons of conflicts and a message about not a trusted repository or something. I figured it was on me because I had just restored a snapshot of the FOG VM.

I wiped the fog installer directory, in my case /opt/fogproject then I re-downloaded,

sudo git clone https://github.com/FOGProject/fogproject.git /opt/fogproject 

set to dev-branch but it ended up installing the latest stable version: 1.5.10.1565

sudo git checkout dev-branch

Tells me - Already on ‘dev-branch’

@Tom-Elliott

Thanks Tom, that fixed it right up. I guess I overlooked that file when copying everything from the original /images.

Yeah, that fdrive number… It is the serial number of the drive.

The NVME drives initialize differently each time during boot. I guess that is a thing, so nvme0 would sometimes be nvme1. It was a mess. Then I learned drive size could be used to differentiate between drives under Host Primary Disk. Now that both of my NVME drives are the same size, I have to use the drive serial number.