@JJ-Fullmer Good to know, thank you so much 😎💯

@Tom-Elliott

No worries, all the help is appriciated!

199cd3f7-9311-4f08-80df-dd932845af2d-image.png

a6b999ce-4c5b-4462-9181-3746b2972f8a-image.png
a900cb0f-9abb-41fa-84b8-cef64c317cc6-image.png

6d685e25-ca2f-4c18-8a27-add58d1470e0-image.png

@45lightrain said in Issues with capturing an image with a raid0 array.:

Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?

FOG captures disks in block mode. It doesn’t care about partitions (mostly). Also make sure that md0 is the true device for these drives. When you are in the FOS linux shell you can / should create a mount point and then mount /dev/mdX partition to see if you can read the content. I have seen where sometimes md0 is created but the real raid array is /dev/md126.

Also FOG calls a script before imaging starts. Sometimes its needed to assemble the array in this postinit script. Or do other things to prep the system for imaging. So the postinit script (found in the /images directory on the fog server) is a the place to put that code.

Also when you start in debug mode (when debugging the imaging process) you can actually start the imaging process from the command line by keying in fog. The imaging will stop at each debugPause; command in the imaging code as a breakpoint. If you notice something wrong, you can hit ctrl-C to exit back to the command prompt. To restart the imaging process again just rekey in fog.

While it doesn’t exactly apply here I wrote an article 8 years ago about imaging using the intel rst adapter that may contain a nugget of help: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

@theyikes Well the first thing I would do is look to see what the kernel name is in the casper directory. Ubuntu does change this kernel name from time to time. I do think the file name listed looks suspicious. I would expect something like vmlinuz without the extension. But look to see the kernel name and adjust accordingly.

@Tom-Elliott said in FOG Update errors:

./installfog.sh -y

Thanks Tom! I am up and running again!

Disregard I was not selecting deploy image.

@Tom-Elliott said in Fog 1.5.10 Install error libcurl4 Failed during install:

@jaumeramos Would you be willing to test:

diff --git a/lib/common/functions.sh b/lib/common/functions.sh index b20b0e482..05f40d08c 100755 --- a/lib/common/functions.sh +++ b/lib/common/functions.sh @@ -725,6 +725,9 @@ installPackages() { if [[ $OSVersion -gt 17 ]]; then packages="${packages// libcurl3 / libcurl4 }">>$error_log 2>&1 fi + if [[ $OSVersion -ge 22 ]]; then + packages="${packages// libcurl4 / libcurl4t64 }">>$error_log 2>&1 + fi if [[ $linuxReleaseName_lower == +(*ubuntu*) && $OSVersion -ge 18 ]]; then # Fix missing universe section for Ubuntu 18.04 LIVE LANG='en_US.UTF-8' LC_ALL='en_US.UTF-8' add-apt-repository -y universe >>$error_log 2>&1

Changing the functions to this code?

I’m hoping to catch as 17-21 worked fine with lubcurl4, but 22 needs libcurl4t64

It’s ugly, I have pushed if you just want to pull from dev-branch

Hi,
The dev-branch worked well for me, thanks!

Ubuntu MATE 24.04
6.8.0-31-generic
All packages fully updated before running the FOG installer (for better or worse, haha)

Thanks again for all the work on this project, it has been great to see it continue on over the years,
Dave

@Tom-Elliott thanks for all !

@J-Redshaw I suspect yours is likely related to Bitlocker encrypting the free space of your drive.

https://forums.fogproject.org/post/134625

@TaTa Glad that worked for you! There hasn’t been any update to the github thread since 1/31, but I was able to compile binaries today using the original buildipxe.sh script without the additional line without error.

@Thierry-carlotti said in iPxe boot fails : Coud not boot :Permission denied (https://ipxe.org/0216eb8f):

iPxe boot fails : Coud not boot :Permission denied (https://ipxe.org/0216eb8f)

This really sounds like secure boot is enabled keeping ipxe from loading/running.

@45lightrain Lets cover a few things that I’m aware of that might help you get to the bottom of the issue.

When you have a ProxyDHCP server and normal dhcp server on your network you will get two dhcp OFFERS. Well I guess it would be the same if you had two dhcp server you would see two offers, but that is a bit off point. You can tell if an OFFER packet is a proxy dhcp packet because dhcp option 60 will be set to PXEClient in the ProxyDHCP OFFER. That is a signal to the pxe booting client to come back and ask about pxe booting from the ProxyDHCP server. The pxe booting client will ignore the pxe boot information from the main dhcp server. A properly formed dhcp packet will have both the fields in the header {next-server} and {boot-file} filled out for the bootp booting protocol part of the protocol AND should have dhcp option 66 and 67 set for the dhcp booting protocol. Both must be filled out because its up to the pxe booting client to pick either the dhcp or bootp protocol. Your ltsp files are correct. The last one you posted has the dhcp-range… commented out, that turns off the proxydhcp feature in dnsmasq.

SO if you have a pihole server that runs dnsmasq, why are you running an external dnsmasq server. Does your pihole server have pxe boot options? I know pfsense has built in pxe boot fields you can fill out that supports dynamic (bios/uefi) boot loaders.

When trying to debug this wireshark/tcpdump is your friend that tells you what is flying down the wire. Just remember that dhcp is based on broadcast messages so you can “hear” them from any network port, and proxyDHCP like other unicast messages must be captured at the source, destination, or via a mirrored port.

@Tom-Elliott I made a mistake – Our current FOG version is actually 1.5.9 but the php version is still 7.2.24. Would that change the possibilities of a PHP upgrade ?

@limbooface Is this still an issue? If not, I’ll close this issue.

@jfernandz
No.
I capture an image to the fog server and that works. I have several images on the server that we use. When we go to deploy an image we enable PXE boot save changes and go back into the BIOS. Using the Quick boot menu select the PXE boot on the NIC that is connected to the FOG server.

From here the PXE boots fine and I am able to select Quick deployment login using the username / password. Select any of the captured images. It will go through the whole deployment process with no errors posted. When it boots we normally go back into the BIOS and disable PXE boot. Save changes and restart. It will then post Reboot and Select proper Boot Device or Insert Boot Media in selected Boot device and press a key.

If I use clonezilla and restore an older image to the PC and then use FOG Server using the same steps to deploy it will then boot into the OS correctly.

@slawa-jad I don’t think grub_is_lockdown is the issue, just the message presented.

If you’re able to load up the original machine you captured the image from, look at your /etc/fstab file.

I suspect you’ll see something to the effect of:

UUID=a2476193-12cf-4601-a38d-6c798fc42708 /boot ext4 defaults 1 2 UUID=AACD-BEFE /boot/efi vfat umask=0077,shortname=winnt 0 2

If your file.

This is where things are breaking down.

Change the UUID= portion to the actual drive name.

The boot efi part, I’m not 100% certain what to change it to, but I would suspect probably

/dev/sda1 /boot ext4 defaults 1 2 /dev/sda2 /boot/efi vfat umask=0077,shortname=winnt 0 2

This is just my guess. I would not make these changes on the “originally captured” machine but rather make it on one of the machines that you deployed to and fix it there. Once it’s fixed, I’d then suggest re-capturing the image from that “now working” machine and deploy as freely as needed.

@matthewadams12 Why do you need the Fog Server to be offline?
Maybe there’s a solution where we can isolate just the part you want to isolate. i.e. if you are trying to remove internet access where images are stored you could setup a storage node and keep that offline after initial install. The storage node would also need packages and updates to fog, but you could capture them during updates on the main server and then sneakernet them to the storage node.

Storage nodes are just what I’m using as an example. If it’s not the images stored on the server you’re trying to isolate, then there could still be another solution. You could also firewall the server with your external firewall or the os firewall to only allow access to the fog github page for update downloads and then the repo sites that download the package updates?

Just thought I’d throw out some other possibilities.