@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.

@robertkwild It seems the ipxe files you’re using are not compiled with your certificate?

@jfernandz No, it’s not being implemented at all currently. If you want to take a stab at it, please feel free. I don’t know what it would entail and I am fairly confident no one else within the FOG Dev team is currently trying to implement such a feature.

@guyfox 1.5.10.x and forward adjusted permissions from /images (recursively) to use fogproject

So I might suggest:

chown -R fogproject:fogproject /images
chmod -R 775 /images

This is to make sure security is much better than it was in the past.

@jfernandz Technically anything is possible, if you want to take a go at it sure. I doubt this will fix the issue for bitlocker though.

You would have a postdownload script of something like:

osdiskpart=“/dev/sda2”;

mkdir /ntfs 2>/dev/null

mount.ntfs-3g “${osdiskpart}” /ntfs 2>/tmp/mntfail

mntRet=“$?”;
if [ ! “$mntRet” = “0” ]; then
echo “Failed to mount C:”;
cat /tmp/mntfail;
sleep 12;
exit 1;
fi

unattendfile=“/ntfs/Windows/Panther/unattend.xml”;
sed -i -e “s#<ComputerName>([^<][^<]*)</ComputerName>#<ComputerName>$hostname</ComputerName>#gi” $unattendfile

Of course this assumes that /dev/sda2 is the windows main partition.

@jeje3346 it looks correct, yes.

You could test it by creating a simple example of the file and running the sed statement itself. Ultimately, though, it should work properly.

@jeje3346 Technically speaking, anything is possible.

These postdownload scripts are customizable to your hearts content, so yes it’s possible, technically, but as far as getting support for your own scripts, we’ll try, but it’s still all best case.

The FOG Client will do so in a well standardized method but if you don’t want to use that, that’s perfectly fine as well.

We will still attempt to assist as required.

Thank you,

@dejv Please try using snponly.efi instead of ipxe.efi?

What version of fog are you using?

@ZipfelK The images you provide show us the dhcp configuration options but doesn’t really tell us anything or show us anything of what “doesn’t work” about your FOG UEFI PXE?

Is something freezing? Is it permissions? Is it not finding the next-server/bootfile to download?

What isn’t working?

What things have you tried? I see most of your configurations are trying to use ipxe.efi, what about trying UEFI with snp.efi or snponly.efi?

@Erika So if the older BIOS appears to work:

BI0S Version 1.07.05
KBC/EC Version 1.09.10
ME FW Version 18.0.5.2133

Then chances are something that was updated firmware wise is causing the problem rather than the kernel. Unsure what we could do to fix this, though if you’re okay with trying kernels still.

Can you try various kernel versions?

I see you may have tried 6.1.22, what about 6.1.89, whatabout older?

If there’s a version that the new bios version works with, that helps lead us to a point that there is something in the Kernel that isn’t working right. It won’t get us closer to fixing the issue entirely but should help us narrow where in the Kernel there is a problem so we can try to figure it out.

@aurfalien I’m sorry, I am generally working in working-1.6 and even there I was mistaken.

The file you’re looking for is likely /var/www/fog/lib/fog/host.class.php.

It follows similar rules though the line you’d want changed would be at 2199 I think.

Hopefully this helps?