@Tom-Elliott The first test I did was with a multi-disk image that I made from a vm and it went back to the behavior it did before where it acted like it was working but never gets into partclone.
I’ll do a debug session for that one since it happened to fast to snap a picture.

@Sebastian-Roth Just an FYI, I ran into this again on different hardware. An HP Z2 G4 Workstation did the same thing.
There may have been more to it though, still troubleshooting a bit. My failsafe in the postdownload script to have it still join the domain through the unattend file was injected into the file, but the computer did not join the domain through that method, there may have been a different reason for that though.

Point being, there could be other hardware that weirdly doesn’t get all the variables. I sadly can’t super test on this hardware as I discovered it when imaging a production machine that I can’t take out of production for testing. But I can probably find a chance to get the fos level device info or something.

@jj-fullmer I haven’t done a full thorough fog windows 11 test. But it seems that some of the cpu and bios security “requirements” aren’t hard requirements. As long as your cpu supports TPM 1.2 you can do a clean install of windows 11, you just can’t in place upgrade (without a registry change).

I am also posting this on a computer with windows 11 on it, with an i7-6700. I didn’t use fog, and secure boot got enabled by the windows 11 installer (it might have already been enabled, I didn’t double check sadly). However I just disabled secure boot and could still boot.

So the concerns about a secure boot requirement may be unfounded. This is my home computer and I don’t have a fog server at home, but I’ll come back here once I get a chance to test creating and deploying a windows 11 image to see if there are any issues with secure boot. If anyone wants to test this out @testers before I get some time, you can download a windows 11 iso here https://www.microsoft.com/en-us/software-download/windows11?ranMID=24542&ranEAID=0JlRymcP1YU&ranSiteID=0JlRymcP1YU-aILwA1rXpThxrraz01AUgg&epi=0JlRymcP1YU-aILwA1rXpThxrraz01AUgg&irgwc=1&irclickid=_2cqgd3xf9kkf6xflm1yfj9km9e2xoz2ov3bwz2yp00

@Tom-Elliott I’m giving it a go now!

@ramone As far as I am aware, no one ever volunteered to take up the docker image maintenance. It’s essentially dead.
I think it’s possible in theory, you would just need volumes for the fog directories that need to be static between updates like the database and images, though there would surely be other fun issues with ports to work out. I personally see the desire for it if you’re in an environment where you already have lots of containers as a standard in your infrastructure, but I like having it just on its own server.
Is it not an option to start with a docker image that doesn’t already have a database on the default port? Or are you saying the docker host already has a database on said port?
I’m also sure we could figure out using an external database as storagenodes already connect to an external database. I would think that using docker for adding storage nodes might make some sense as you could put them all on one server and use volumes to mount disks from different sources.
However, the more virtualization and containerization you add, the more complication arises. Already once just on a virtual server you may not be able to use multi-cast imaging unless you’re able to add igmp snooping in your virtual networking. I don’t know if containers have that same limitation or other limitations that could be introduced.

This isn’t really a great answer I realize, and I apologize for that, but there’s a lot to consider with changing infrastructure.

Anyway, something you might try is to create a /opt/fog/.fogsettings file before installing and put in these settings

snmysqlpass='password'
snmysqlhost='remoteHost'
snmysqluser='fogmaster'
mysqldbname='fog'

Then try the installer, no idea if it would work, but something to try as far as using an external database.

@Arrowhead-IT ummmm, I just did another test to be more thorough and discovered a problem.
After mps successfully downloaded I tried downloading a resizable image and it failed to recreate the partition table.
Sorry for the false hope

@Tom-Elliott It shall be done.

@Tom-Elliott said:

@Arrowhead-IT if you can would you be willing to test upload and download again for the resize and multipartition image types?

I will edit this post like before as I test each scenario.
If there is a scenario I’m missing here let me know and I’ll test that too.
I will try to be thorough as I can.

Download of existing image created from vm

Resizable (Windows 8.1) - Success! No Issues!

Resizable (Windows 10) - Success! No issues!

Multi-partition (Linux CentOS Ext4 and LVM) - Failed - New Error

I think this indicates a problem with the image file itself not the imaging process. I’ll reupload this one and test a different mps image in the meantime.
Edit Reuploaded the image, this is centOS vm that has no mbr apparently. So this is a different problem entirely related linux lvm images. normal mps images work fine

Multi-partition (Windows 7) - Success! Edit No Issues!
before
Note: Changing hostname said failed after imaging in debug mode.

Upload from nvme

Resizable (Windows 10 ) - retesting

Multi-partition -

Download of newly uploaded image from nvme

Resizable (Windows 8.1 ) - Failed - Could not find hard disk on system - getHardDisk function

Multi-partition

@Arrowhead-IT said:

I’m about to test upload on the updated version.

Great success, forgot to post that this worked.

All is working as of 6050

@Tom-Elliott Yes, I just did. I marked it as unsolved when it broke again.

@george1421 The developer has replied, I have quoted it below

Thanks for the bug report. Upon reading the thread, I think the bug may be related to changes I made to work around problems caused by changes to the way macOS stored its files on APFS volumes, as noted in the release notes for version 0.11.1:

: As a follow-on to the preceding change, I discovered that compiling
: rEFInd with GNU-EFI resulted in a failure to properly track some
: files on APFS volumes. I don’t know if this failure reflected a bug
: in Apple’s EFI, in GNU-EFI, or in rEFInd; but I changed the way
: rEFInd tracks boot loader files internally to work around the
: problem. Although I’ve tested this version on an unusually wide
: number of computers, it’s possible that this change will introduce
: new bugs. Thus, if you upgrade and have problems with boot loaders
: not being detected or not launching, dropping back to version 0.11.0
: may be worth trying. (Be sure to contact me with a bug report, too!)

I can look over these code changes for any obvious bugs, but tracking this down may require testing with debug versions that display debugging data. If you or somebody else who’s affected can help with that, it might speed up the process.
FWIW, some of the reports mentioned HP EliteDesk computers. I happen to own an EliteDesk 705, and I have NOT seen the problem on it. Thus, I suspect that the problem appears as an interaction with a very limited set of EFIs and/or something quirky about the partition table, filesystem, or other system-specific setup. This isn’t to say the bug exists in some other component, but it’s likely manifesting only in some rare circumstance.

In the meantime, using version 0.11.0 makes sense as a workaround.
–
Rod Smith

@george1421 I meant to put that I volunteered as tribute when I quoted his reply.
I’m sure he’d appreciate more testers as well if anyone’s interested.

@george1421 That done did it!
It imaged correctly as expected, huzzah! No problems at all.

@george1421 I’m making it my default kernel now then, I backed up the old one of course. I’ll report back if there are any problems, but I would assume all will work as expected.

@george1421 On it! Going to try it still using your test kernel

@george1421 I need to get this machine into production so I can’t test this right now. But I can image one of the other’s we have tomorrow and see if this kernel does the trick.