Best posts made by Sebastian Roth

@abulhol FOG doesn’t check the free disk space before capturing an image. We consider this something the admin needs to take care of. As well we can’t be really sure how much space a new image would actually take.

@Wayne-Workman Thanks heaps for mentioning this here! We should really update that wiki page to help people fix this. Newer versions of MySQL/MariaDB behave very different and we have changed the old way of using an empty DB password.

@Chris-Whiteley said:

It looks like 1 of those 1.5.8mod’s was already done in the middle of the current truth table.

Yes, I mentioned earlier that you seem to have done this one already but I may ask you to re-do that one test as we pick this up again. Just wanna make sure we really get the tests consistent.

I will work on building a 1.5.7mod today.

@altitudehack To me it looks like you have found and fixed what was causing the error in your case. So I’ll mark this solved. Thanks for posting here. I am sure it will be useful for others in the future!

@Mightmar said in New computers- no configuration methods succedeed:

I got a new problem now

May I ask you to open a new topic for this? We try to keep things sorted here so others can find solutions to same or similar issues better.

@davide1611 This is a known issue. Edit the DHCP server config in your FOG server and swap out undionly.kkpxe with ipxe.pxe. That binary doesn’t have the reboot (warm boot) issue in VirtualBox.

@jmvela2x The default timeout when FOG proceeds form one partition to the next in multicast mode is 10 seconds (code ref). We have seen one topic in the forums where this caused a problem some weeks ago. You might want to play with that to see if it can fix your issue.

Cancel all multicast tasks. Then edit /var/www/html/fog/lib/service/multicasttask.class.php, go to line 662 and change the code from this:

                    (
                        $i == 0 ?
                        $maxwait * 60 :
                        10
                    )
                ),

to

                    (
                        $i == 0 ?
                        $maxwait * 60 :
                        30
                    )
                ),

Only changing the value of “10” to “30”. Save the file and restart your whole FOG server. Create a new multicast task and see if it’s any better.

@jmvela2x said:

I did notice the task is still showing in active tasks and has not cleared out. Is that an issue you are aware of?

This is a known issue in FOG 1.5.8 and should be fixed in the latest development version. You are more than welcome to update to 1.5.9-RC1 or even the current developer version as we are reliant on people actually testing the release candidate version to find bugs we can fix before the next release.

Best way is to use git:

sudo -i
git clone https://github.com/FOGProject/fogproject/
cd fogproject
git checkout dev-branch
cd bin
./installfog.sh

@j00k4 I suppose you use FOG 1.5.8, right? When we released this version Ubuntu 20.04 wasn’t out yet and while I have tried to get it right, Ubuntu decided to switch to a different PHP version just a few weeks before the final 20.04 release.

So please download the latest release candidate version of FOG and give that a try: https://github.com/FOGProject/fogproject/archive/1.5.9-RC1.zip

@jmvela2x I still have this on my list but have not had the time to dig into it… Will do and let you know here.

@foggystarz Hi and welcome to the forums.

I am guessing that the the fact I can upload and deploy images means the user/pass for the /images dir is fine but there is some mismatch somewhere with the /bin/fog.av dir.

The AV feature of FOG has been dropped some time ago but never fully been removed from the code. Find more information on this here: https://github.com/FOGProject/fogproject/issues/328

Now that you bring it up I might look into fixing this soon so new users like you don’t run into this again.

@jmvela2x I just pushed a commit that should take care of the task cleanup. Took a fair while because I ran into some other issues in that part of the code as well.

@jmvela2x Thanks for testing and reporting back. Too bad I still haven’t worked it out. It did work in my test setup but I think I had the code changes for the other issue I found in place too when doing the tests. I shall have merged them all in but I feared those would cause other problems.

Anyhow, merged it all into dev-branch (RC2.6 as of now) and it would be great if you’d want to give it another try.

@foggystarz I’ve just had a quick look at the bootloader in the Ubuntu 20.04 Desktop ISO file and found the following in isolinux/txt.cfg file:

label live
  menu label ^Try Ubuntu without installing
  kernel /casper/vmlinuz
  append  file=/cdrom/preseed/ubuntu.seed initrd=/casper/initrd quiet splash ---
...

The preseed file does not yield much helpful stuff I reckon. So I am wondering what kernel (files linux / vmlinuz) and initrd (files initrd.gz / initrd) you used?!

The other thing I just noticed is that you don’t use the initrd= kernel parameter. I am not sure what exactly it does but I remember that we had to add this parameter to our FOG boot loading at some stage (kernel version new than X or since UEFI came up??) to make it work properly.

And third, you might want to remove the kernel parameters quiet splash to see more information on screen any maybe spot something that might lead us to understand what’s on.

@xburnerx00 Ok, here is what I would do in this situation. I am going to explain it and you can decide weather you want to go that route or not. Before you proceed I need to say that those kind of operations can have caveats that I might not be able to foresee not sitting in front of the machine myself but giving you the commands as this. Please be cautious when doing this and take a backup of it all first as in the worst case of the scenario data can go lost if there is something going wrong. I will triple check all the commands I post here but can’t be absolutely sure as I don’t have the same setup here to test with first. Although I don’t think it will go wrong I just wanted to make sure you are aware.

So please make sure you save all the commands you run and resulting outputs for us to be able to diagnose and help you if anything goes wrong. We won’t be able to help you if we don’t have detailed information on what has been done and what the outcomes were!

• Backup
  Take a backup of you FOG server. Either a full image backup if you want/need to be able to get back to that state quickly or a full dump of the FOG database along with the two images directories.

• Move date from /images2
  To be able to add this extra space to your FOG server a different way we will need to empty that disk first. Make sure non of the images is being used by someone else for imaging at the moment as we will be moving some of those around. Go to the FOG web UI -> images view -> pay attention to the “Storage Group” column here and edit one image definition after the other that is being set to storage group ImageStoreGroup2 at the moment -> go to “Storage Group” tab, click the checkbox “Check here to see what storage groups can be added” to see the storage group called default, add that to the image, reload the page to see it, make it the default by setting the checkbox in the second column of the table and remove ImageStoreGroup2 at the end. Check you have all the images in the list set to Storage Group default and then run the following commands as root to move the images on disk (do not say yes if asked to confirm a folder to be overwritten - say no and investigate first):

mkdir /images/tmp
mv /images2/dev /images/tmp/
mv /images2/postdownloadscripts /images/tmp/
mv -i /images2/* /images/
ls -al /images2

• Prepare disk
  If you see anything left in /images2 other than a file called .mntcheck when running the final ls command above you need to stop and take a closer look. If in doubt you can post commands and outputs here in the forums so we can help. Now I would think there is no trouble and we can proceed. The following commands (run as root) will remove the extra NFS share and fstab entry (vi commands - just put a # sign in front of the /images2/ definitions and save the files), unmount the disk and prepare it for usage as a logical volume (the last command will wipe anything from that disk and you will probably need to confirm a warning here):

systemctl stop nfs-server
vi /etc/fstab
vi /etc/exports
umount /images2
pvs
pvcreate /dev/sdb1
pvs

• Adding space to the LVM
  Now as a last step we want to add this volume/space to the existing logical volume group to add to your /images directory - run as root and always pay a close look at the pvs/vgs/lvs commands output to validate the operations done:

vgs
vgextend centos /dev/sdb1
vgs
df -h | grep images
umount /images
lvs
lvextend -l+100%FREE /dev/mapper/centos-images
lvs
xfs_growfs /dev/mapper/centos-images
mount /dev/mapper/centos-images /images 
df -h | grep images

• Reboot and check
  After you’ve confirmed the images directory is now extended, I would reboot the server instead of just starting nfs-server again just to make sure it comes up all fine again. If everything seems fine (output of df -h also after reboot and free space in the FOG web UI, doing a test deploy and capture) you may want to review the things that we moved to /images/tmp/ directory. I would hope that there is nothing much of value in there but please run ls -alR /images/tmp/ and post output here.

@jmvela2x said in Multicast without registration starts OK, but hangs and disconnects clients due to timeout.:

I did see one error in the FOMulticastManager status output that may be a cause for concern. Expected?

Thanks, found and fixed in latest dev-branch.

@jmvela2x Thanks very much for sticking with us on this and doing the tests!

@george1421 said in Latitude 5410 No Legacy boot:

You can technically leave dhcp option 67 in place since proxydhcp will override any values that come from dhcp/bootp.

While this works with many PXE boot firmwares there are also some that get confused by that and don’t properly boot up. Just saying so you have been warned in case something seems wired.

@hancocza We need more information to be able to help.

The certificate that we use for this server was updated

Please tell us more about this certificate. Is this a cert generated by the FOG installer or one that you get from a different certificate authority?

Are there steps on how to get everything working with it?

What were the exact steps you took to make it work in the first place?

@browlry Looking at the information provided I also find it surprising that you seem to be left with an MBR partition layout on the destinations machines! FOG uses the information in d1.partitions, d1.minimum.partitions (only when image is of type resizable) and d1.mbr file to re-create and adjust the partition layout. The contents of d1.partitions you posted clearly show a GPT style partition layout and I suspect d1.minimum.partitions to be the same! I reckon the d1.mbr file to still have some old style MBR information in it that is confusing FOS.

Possibly it’s those commands from your scripts that create the “mess” but I am not sure.

select disk 0
clean
convert gpt

Why do you actually need to convert to GPT at all I wonder? Make sure the disk is being properly cleaned (I don’t know if MS diskpart is doing a good job) and create a fresh new GPT partition layout from scratch. George is right about the first partition being “abnormal”. I would not think this is causing the issue as described but that’s just me guessing.

If you don’t want to mess with your master image we can still take a look at the d1.mbr file (it’s binary, upload to a file share and post a link here) and see if we can help you fixing it.