@BrightPipe Can you post the snapin?

This isn’t something FOG is doing, though you already suspect that as well.

So seeing the snapin file, I’m guessing it’s using some method that’s effectively saying “set all the things” and the snapin is set to only set “specific” things.

Since the action is effectively “setting all the things” it’s resetting the other things you didn’t intend.

Seeing the snapin and the actions involved will be most beneficial at least to understand what’s happening. We may not be able to fix the issue but at least we could all better understand the problem and maybe think of ways to troubleshoot and hopefully narrow down whats wrong.

At cursory glance, it feels like the snapin is misconfigured in someway. Thought you did say it worked in Windows 10, but not in Windows 11, so it’s also just as possible there’s some functional difference that needs to be adjusted for in the Windows 11 side of things.

@rhysb92 We need more information.

i ask because I have just built a new VM, and installed dev-branch/stable and it completed and I was indeed able to login with the fog/password combination where i then changed the PW.

So I feel like we’re missing some key information.

@mr-Twister Can you please try this:

http://forums.fogproject.org/post/122702

effectively your boot menu likely needs to be:

params param mac0 ${net0/mac} param arch ${arch} param qihost 1 kernel bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 web=http://${fog-ip}/fog/ consoleblank=0 rootfstype=ext4 mac= ftp=<storageIPHere> storage=<storageIPHere>:/images/ storageip=<storageIPHere> irqpoll chkdsk=0 capone=1 type=down img=<imageNameHere> imgType=n imgPartitionType=all imgid=2 osid=<imageOSIDHere> imgFormat=<imageFormatHere> imgfetch init.xz boot

Replacing as appropriate:
<storageIPHere>
<imageNameHere>
<imageOSIDHere>
<imageFormatHere>

with your relevant information.

Ultimately finding these pieces of data relevant to your specific image will be the hardest part, but once done I believe this will do what you are wanting/hoping.

@Bearr1976 If you use the latest init, the primary drive is supposed to be /dev/sda automatically (technically the first in alphabetical order) so by setting Host Primary Disk, may be forcing it to use that specific drive. In your case, if you’re trying to capture multiple disks, I suspect you would need the Host Primary Disk unset. If there’s something else not working right after unsetting please let me know and I’ll try to see what I can do to replicate the issue.

@Tom-Elliott
Of course, it’s disabled. 😉

All issues have been resolved by the latest kernel . Best regards, this thread can now be closed. Solved. 😉

@rodluz Updating the kernel to the latest version helped; the computers are finally being restored at full and consistent speeds, for both unicast and multicast deployments. Thank you for your help.

Well, I have to admit, I opened this issue a while ago, and then didn’t really have time to play with it. I only have a handful of these machines, and while it’s a pain when I have to reimage one, I didn’t have time to spend a lot of time trying to figure this out. Well, today I had to reimage another one of them, and so just out of curiosity checked this thread again, and wouldn’t you know it, it seemed like the issue might be resolved…I updated the kernel, started imaging, and it is going in 5 minutes again!

Thanks so much for an amazing product and community!

Q

@eoli3n Versions are impossible to give because they keep changing, so we do try to have the version that are supported between masters/dev-branch/etc… for the os’s at that point in time (and backward)

Debian Based (Mint, Ubuntu, Debian), Redhat Based (Redhat, Rocky, Alma, Fedora).

The versions, dev-branch is more likely going to be in line with latest/greatest. Some what of a delay of course, but there’s no list that clearly spells out what version of specific OS is supported.

In my opinion, Redhat based OS’s are the best as we don’t have to continually update the installer code to support future versions. Most will just work right out of the box.

Migration process? No, if you’re moving one machine to another that’s one thing of a migration and there is a process for that, but if you’re meaning “I’m on bookworm and without moving anything, I’m going to do an in place upgrade?” I don’t believe there will be problems but what I would suggest is re-installing FOG once the upgrade is complete as any services or config files that got changed would need to be rebuilt for the new OS. It’s not hard and I don’t think there will be any issues. If there are, please let us know.

@Petrushka hello!!

In our firewalld rules we have

services: - ftp - http - mountd - nfs - rpc-bind - tftp ports: - { port: 20048, proto: tcp } # nfs - { port: 20048, proto: udp } # nfs - { port: "35350-36350", proto: udp } # tftp - { port: "49512-65532", proto: udp } # multicast

I completly reinstalled the dev_branch software in an new Debian 12 guest and now it seems to work fine.
Thank you

@Tom-Elliott that seems to have solved it. Thanks yet again for speedy service! Cheers

@Tom-Elliott
That was it, Tom. Thank you so much for helping me with this. I was starting to lose some hair!

@Tom-Elliott
The upgrade to stable version completed successfully.
I’m now on fog 1.5.10.1673
Thanks again