@leonjv The FOG 1.5.9 installer was not smart enough to check for an exiting DB and tried to use whatever it considered right. This was fixed in the latest dev-branch version (github commit). You can wait for the next release or use the dev-branch version.

@george1421 Alright. Thank you very much!

@george1421 Hi, I`m sorry , i have attached wrong info and screenshot with video. It was a result of my attempts to boot from .tgz ubuntu which i found in an old sysadmin files, which very like a foreman tools.

@thebaz The number of times someone has upgraded the OS of their FOG server and broken FOG is a lot. So many that it prompted me to write this article about five years ago. The article is still valid. My advice is to not upgrade the OS of your FOG server, unless it’s in a VM and you take a snapshot before hand. If it’s not in a VM, your safest choice is to migrate.

@george1421 Hey George, sorry I didn’t reply yesterday. I did get everything running successfully. Captured an image and deploying image right now! Appreciate all your help! Not sure how to mark this is as solved but its working!

@alansmithee said in Proper way to install client on Linux hosts:

Actually I was wondering if it was feasible to install the client before capturing/deploying

That is how you typically would do that in the windows world. From a windows perspective the fog client is installed then the service is set to disabled. At the end of the winsetup process windows calls a batch file called setupcomplete.cmd that is used to issue the commands to the fog client to startup on every reboot. The issue with windows is as soon as the fog client starts it will start executing its tasks. If windows oobe/winsetup is still doing their bits the fog client may reboot the computer without oobe being done, thus creating a botched install. Linux first boot is nothing like windows, so it may be OK to leave the linux fog client configured to auto start at each reboot.

@wt_101 said in CentOS LVM Slow Imaging:

what do u mean by RAW image type?

This is a mode for partclone when it can’t determine the format of the disk, this is a default mode when no other disk format filters exist, such as with LVM. In linux terms partclone uses dd (disk dump) format to image the disk. This is the slowest and largest format since it copies all disk blocks. Partclone might change to this format if it detects and encrypted drive where it can’t read the partition information because its encrypted.

ref: https://partclone.org/usage/partclone.dd.php

fixed from me and working

kernel tftp://${fog-ip}/os/redhat/r9/vmlinuz
initrd tftp://${fog-ip}/os/redhat/r9/initrd.img
imgargs vmlinuz initrd=initrd.img root=live:nfs://${fog-ip}:/images/os/redhat/r9/images/install.img ip=dhcp inst.repo=nfs:${fog-ip}:/images/os/redhat/r9/BaseOS splash quiet
boot || goto MENU

@george1421 I finally got it working!

I ran fsck.ext4 /dev/sda2 and it fixed the partition layout.

Thanks again for your time 🙂

Thanks Wayne, I’ll get the the swap partitioned removed, recapture and try again!

@george1421

That was totally it! I was confusing myself with the /images directory for tftp. After changing the command to match the /tftpboot directory everything works perfectly. Thanks for your help!

@tudor said in Can I deploy a simple buildroot image with FOGProject?:

Having to copy the image to a machine and back again would be an extra unneccesary step since we already have the image ready to go.

Yeah I can see what you mean. Understood.

If you want to use FOG for this (e.g. because you like the multicast feature) you will need to start investigating the image format and see if you can make it work. We are open to help you find the right track but it’s up to you to actually figure it out.

FOG supports so called RAW image type with uses partclone.dd not (plain) dd. While I have used both extensively I never tried to deploy an image with dd that was created with partclone.dd or vice versa. Don’t think it’ll work but I am not sure. If it doesn’t then you might hack the bash script doing the deployment to just use dd (code reference).

@untouchedwagons Well I just copy&pasted this stuff. Now looking at the parameters again I think this part is not right: ... nfsroot=/${fog-ip}:/images/os... (remove the slash after the equal sign I would say)

@btphl Version 1.5.10 will be released later this spring.

To get the “current” version of 1.5.9 you can switch to the dev branch.

change into fogproject installer directory.

cd /root/fogproject git pull git checkout dev-branch git pull cd bin ./installfog.sh

When 1.5.10 is released to change back.

cd /root/fogproject git pull git checkout master git pull cd bin ./installfog.sh

@jack_chapman

As a personal rule (not from the FOG team). I would recommend sticking with LTS OSes when setting up servers unless you want to regularly be upgrading or migrating. Ubuntu Interim standard support from Canonical is SHORT (9 months).

See 21.10 vs 18.04:
https://ubuntu.com/about/release-cycle

@anisgh Which version of Debian did you try to install FOG on? I am really wondering what’s going on because the error we see in the output posted doesn’t make sense to me. The package named mariadb-client is available in all current versios of Debian: https://packages.debian.org/search?keywords=mariadb-client&searchon=names&suite=stable&section=all (for stretch, buster, bullseye, even bookworm and sid!)

Please try installing it manually via apt-get install mariadb-client and see what error you get.

So either you try to install on Debian 11 - then follow what George posted. Or you are using a really old version of Debian and need to update to a later one first.