@eliaspereira I’m not fully sure what is wrong or where it’s wrong at and I don’t really have a means to test.
I’m presuming you posted the issue on github which is a good place to start.
If that is the case it sounds like something missed a step during updating the database potentially?
@John-L-Clark can you try with snp.efi or snponly.efi?
@mashina You may have to make appropriate customizations but here are the basic steps:
https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
@robertkwild There’s only one “stable” one “major/master” and then the one we’re working toward.
Technically there’s also “nightly” so 4 main versions:
master branch = 1.5.10 (Currently) - Baseline for stable and current updates of the master.
stable branch = 1.5.10.1634 (Currently) - This is considered (if you will in linux terms) LTS (we’re wanting 1.6 to come out but in the mean time we still need to keep things up and running of the stuff most people are using.)
dev-branch branch = 1.5.10.x >= 1634 (currently) - This is where we do updates for issues found/reported/ and hopeful fixes to go into the next release of stable. This is what I would call “nightly” but it’s not quite bleeding edge either as this is just holding fixes for hte 1.5.10 and later versions.
working-1.6 branch = 1.6. This is what some might consider alpha/beta (all working branches will be intended in this manner at least) in that it is where it’s the fully latest bleeding where we hope and want to get to with fog.
@mckayj Ewww CentOS 7.5 
I’m only kidding. While CentOS 7 is no longer supported and I would (also) suggest moving a a newer OS at this point this isn’t really an issue. Sorry strange mood for me this morning (for me).
Can you give us the output of your /var/log/php-fpm/www-error.log file? This likely is where the actual errors are showing and we can help provide more information.
@robertkwild If you have the git installation method:
cd /opt
git clone https://github.com/fogproject/fogproject
cd fogproject
git checkout working-1.6
cd bin
sudo ./installfog.sh -y
Should do the trick.
(You don’t have to copy paste and everything, it’s just how I think of it all).
I don’t know how you installed originally or how you stay updated.
I am of the mind git is the easiest method as to get the lastest items you just have to cd to the install and run git pull
But that’s one developer’s opinion 
Hope that helps?
@robertkwild I, unfortunately, don’t have any news as I don’t quite understand why it’s creating a file instead of a folder.
If I recall, this used to be a file based system when Windows 7, and earlier were used (it’s been a long while though) and has long since been moved to folder based.
I’m not sure what answer I can say or give here.
Is there any way to know what actual version of FOG you’re currently running?
I can’t say I’ll figure out what’s wrong, but maybe somebody else has thoughts as well.
I’m 90% certain there’s something to do with the FTP statement, but unsure exactly what or why.
The other thing I think would help fix this would be to move to working-1.6 branch if you’re willing, but I realize that’s a huge ask, and may not really help fix the problem at hand.
I can say, with relative certainty at least, that if this was a completely widespread issue we’d have heard about this exactly issue many many more times. I am thinking there may be a PHP-FTP issue on your machine. Working-1.6 is setup, now, to attempt using straight SSH statements to copy and move files around, rather than FTP which should work more consistently (in theory.)
I realize the ask is large and probably overly much for the time being if this isn’t an approach you’d like to take.
@miyaqub I’m going to go on a limb and suspect you have 2 recovery partitions potentially?
it seems that’s what was wrong in the case of this thread you’ve posted.
@aurfalien Hmmm, I suppose and probably need help in this regard (anyone with ideas to fix)
The issue isn’t the UUID direclty, though it is definitely a play into it. I always forget.
The /etc/fstab is using UUID’s inplace of the drive lettering. This makes perfect sense when you have to consider NVME/SSD/USB drives not always getting the same label since it’s a first come first serve issue.
The “fix” in it’s simplest form, used to be to edit /etc/fstab file so that you use the right labels instead of the UUID.
However, this may or may not vary depending on the system but we have funcitons that could help automate that.
I apologize for overlooking that bit as well.
Ultimately:
We can get the uuid using blkid command.
An example script (thanks Chat GPT for the assist 
)
#!/bin/bash
echo "# Generated fstab using UUIDs"
echo "# <file system> <mount point> <type> <options> <dump> <pass>"
# Get UUID, Device, and Type
while read -r device uuid type; do
# Get the mount point using lsblk
mountpoint=$(lsblk -no MOUNTPOINT "$device" | head -n 1)
# If mountpoint is empty, use "unmounted"
[[ -z "$mountpoint" ]] && mountpoint="unmounted"
# Print fstab-style entry
echo "UUID=$uuid $mountpoint $type defaults 0 2"
done < <(blkid -o export | awk -F= '/^DEVNAME/ {dev=$2} /^UUID=/ {uuid=$2} /^TYPE=/ {type=$2} dev && uuid && type {print dev, uuid, type; dev=uuid=type=""}')
Basically this is probably more than what’s wanted, but I would impore you to test something like this and use a post-download script for testing.
If you’re willing/able to adjust a bit. It likely will require getting the Harddrive you imaged (getHarddisk from funcs.sh) and testing the d1.partitions against what was actually deployed ot update the internal /etc/fstab of the drive to use the UUID’s in a more dynamic approach.
In the mean time, if you know your system is consistently booting with the same file label (/dev/sda or /dev/nvmen0 or whatever) then modify the UUID items appropriately for your filesystems and it should boot just fine.
@tatanas FOG can change the hostname at the client in a multitude of ways.
Why do i say this?
The whole point of FOG is to manage the machine, not let the machine manage FOG. We get some details from the machine during the registration, and at this registration you are defining what you want that name to be.
It doesn’t work the other way around. FOG UI was intended to be the central and mostly hands off approach to managing your registered machines up to and including hostname definitions.
Since you do not use the FOG Client (or at the least the hostname changer) I would note that it would make more sense to just put in your process to update the FOG UI for the host when you have to change it on the machine, just so the next time you have to image the machine, it has the “current” name automatically (as best it can) applied.
While a feature like this is technically possible, I believe in most use cases, the feature you’re requesting is not something I’m willing invest time into. There’s a lot of variables that go into this.
Now I’m not saying this isn’t a feature that is or isn’t worth completing or doing, just that I’m not (at least at this point) willing to put the time and effort into. If anyone else has any ideas and would like to work on such a feature I implore you to think about the structure and I will even help if asked.
@robertkwild Is what I asked correct?
You have one drive mounted for /images, and another totally different drive mounted for /images/dev?
This used to work I suspect, so something changed and I’m going on a limb suspecting the issue is the inclusion of a secondary drive for the singular mount point.
@aurfalien so ext filesystems are supposed to be able to be shrunk and expanded as required. They are, at least as of right now, the only Linux Filesystem capable of this and (as much as can be with FOSS) supported by the FOG team of things.
LVM support would be something I’d love to be able to add. There was a program that mimicked FOG (mimicked and used FOG’s open source nature in their system) but also had support for LVM detection, expansion, and (as far as I recall) shrinking called CloneDeploy a few years ago. I don’t know if that program is still being supported by its developer(s) but I was never able to sit down long enough to figure out how it was operating. I did use their baseline to start trying to incorporate some segments but never really got it out the door or tested. So as of this time, no LVM is not really supported for resizable drives at this point. The underlying filesystems (ntfs if you could, ext, etc…) are, but reading LVM is pretty dynamically prone which is part of how I couldn’t wrap my head around how best to do it.
That’s a lot of words to say, yes, EXT should work for both expansion and shrinking and last time I knew, this works and has for quite some time.
@aurfalien I’m not sure what you’re asking.
Are you sseein git say that it’s going to make the disk and resize the partitions? Or does it ahve something like ‘Not expanding’?
It should be noted we can only expand XFS partitions, but it’s a best effort thing and if memory serves a relatively new addition at that.
You could try a deploy debug and get us the /tmp/xfslog.txt file from the client machine that may give us more information.
This is the code (lines 322 - 369) that deals with xfs on deploy and resizable:
xfs)
if [[ $type == "down" ]]; then
dots "Attempting to resize $fstype volume ($part)"
# XFS partitions can only be expanded when there is free space after that partition.
# Retrieving the partition number of a XFS partition that has free space after it.
local xfsPartitionNumberThatCanBeExpanded=$(parted -s -a opt $disk "print free" | grep -i "free space" -B 1 | grep -i "xfs" | cut -d ' ' -f2)
local currentPartitionNumber=$(echo $part | grep -o '[0-9]*$')
if [[ "$xfsPartitionNumberThatCanBeExpanded" == "$currentPartitionNumber"a ]]; then
parted -s -a opt $disk "resizepart $xfsPartitionNumberThatCanBeExpanded 100%" >>/tmp/xfslog.txt 2>&1
if [[ $? -gt 0 ]]; then
echo "Failed"
debugPause
handleError "Could not resize partition $part (${FUNCNAME[0]})\n Info: $(cat /tmp/xfslog.txt)\n Args Passed: $*"
fi
if [[ ! -d /tmp/xfs ]]; then
mkdir /tmp/xfs >>/tmp/xfslog.txt 2>&1
if [[ $? -gt 0 ]]; then
echo "Failed"
debugPause
handleError "Could not create /tmp/xfs (${FUNCNAME[0]})\n Info: $(cat /tmp/xfslog.txt)\n Args Passed: $*"
fi
fi
mount -t xfs $part /tmp/xfs >>/tmp/xfslog.txt 2>&1
if [[ $? -gt 0 ]]; then
echo "Failed"
debugPause
handleError "Could not mount $part to /tmp/xfs (${FUNCNAME[0]})\n Info: $(cat /tmp/xfslog.txt)\n Args Passed: $*"
fi
xfs_growfs $part >>/tmp/xfslog.txt 2>&1
if [[ $? -gt 0 ]]; then
echo "Failed"
debugPause
handleError "Could not grow XFS partition $part (${FUNCNAME[0]})\n Info: $(cat /tmp/xfslog.txt)\n Args Passed: $*"
fi
umount /tmp/xfs >>/tmp/xfslog.txt 2>&1
if [[ $? -gt 0 ]]; then
echo Failed
debugPause
handleError "Could not unmount $part from /tmp/xfs (${FUNCNAME[0]})\n Info: $(cat /tmp/xfslog.txt)\n Args Passed: $*"
fi
echo "Done"
else
echo "Failed, XFS partition cannot be expanded"
fi
fi
;;```@robertkwild I think you’re okay to delete the folder /images/dev/00505692a681 But I leave that trigger totally up to you so long as you tested your copy of the W11_24H2_GI folder is good
@robertkwild I don’t know why it did this.
There was some showing if this exact type of thing happening where/when
/images is one mount, and /images/dev is another individual mount
For example:
2TB HDD (SSD or otherwise) drive that /images is tied to in fstab.
Another 1TB HDD (or something like it) that /images/dev is tied to in fstab.
When the file gets moved from /images/dev/<mac_of_host> to /images/<image_name> for some reason the system moves it and makes it as a file instead of moving it as a directory.
You might (though I’m not holding my breath) still have the image in /images/dev/<mac_of_host> that captured?
@robertkwild Did you actually capture an image to deploy?
It looks like you should expect an image in: /images/w11_24H2
Based on the message, it seems like if you had captured this before, it may not have completed or maybe was not written to /images/w11_24H2?
@sega Not a clue to the issue without more information.
THat said it almost sounds like a probable “secure boot enabled” type of situation?
@robertkwild So this isn’t an issue any longer?
The reason I asked the question I did is that certificates have a timing component. Since iPXE loads before any “system” time is available besides CMOS/BIOS/Hardware clocks, I was going to have you check your bios and set the system time at the hardware and see if that helps.
Glad it’s not all stop broken though.
Thanks
@robertkwild I don’t know. Did this work at any point in time? Is it only this one machine or all having this issue?
@robertkwild I don’t have a very specific set of steps, though generally speaking running the FOG installer completely should recompile the binaries into IPXE for you.
You could try to force this with re-installing fog with the -S argument, but if you have a custom certificate it may be a bit more difficult (though not impossible.)
I don’t know your specific environment.
https://forums.fogproject.org/topic/14095/setting-up-trusted-ssl-certificate/6
this is one example of set of instructions that should help.
If you installation directory (fogproject/utils/FOGiPXE) I believe is where you would run the informed ./buildipxe.sh script.
hope this helps.