@Clebboii You would need to assign the image with the groups you want to transfer between.

Having multiple groups is fine, but those groups also need nodes. Is this not working?

Basically find your image, associate the groups you want to it, and indicate which group is the master group, adn it should start replicating between groups.

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

@Fog_Newb Is this happening on all images you’re capturing or just this specific machine, or this specific model of machine?

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

@Tom-Elliott Just following up, any word on this?

@Richarizard504 dev-branch should now have all the necessary things to allow exporting of any report style thing properly.

Thanks for reporting and apologies for not catching this sooner.

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

@Richarizard504 there was a security issue that was fixed that is likely breaking this. Sorry, i dont work from the 1.5.10.x series so there are times simple things are missed. Can you try updating to dev-branch (this is where stable pulls from automatically) and see if that helps fix the export.php issue?

@Bearr1976 I’m updating the thing so that it will give the first lexilogical drive returned.

If an admin wants to have the largesize as the “primary” they can define it as part of the “Host Kernel Args” or the global (FOG Configuration Settings -> Settings -> Kernel Args -> largesize="1" to use it.

I have to wait for the files to build, but then I’ll ask for them to be pushed as the “Official” release which should do what you’re more used to and provide the feature as an admin choosable thing.

@Bearr1976 The reason I cannot give a version is it’s not specific to the FOG version, but rather the FOS version being used (which would pull the latest released FOS file regardless of which version of FOG you’re pulling.)

You can change the FOS (init) files to the one:
2025-04-29 or earlier.

@Bearr1976 This problem, in my eyes, is a feature.

In most cases, it’s generally assumed the larger the drive == the main drive.

Now you can force the /dev/sda to be the main drive for this machine by setting the ‘Host Primary Drive’ field on the host (or hosts) in question.

If this is something that shouldn’t be:

How should we determine which drive to use?

/dev/hd<x> vs /dev/sd<x> would be using the hd versions over the sd versions.

Of course each person’s things is different. I might suggest using the Host Primary Device field unless this is too unruly for you?

@Bearr1976 I’m attempting to rebuild as there was a potential bug where the drive lettering wouldn’t be followed.

Now it needs to be noted:

FOS will attempt to use the largest disk in the machine to determine the drive to use.

I may think about a feature to allow “smallest” drive to be used, but I think in most cases imaging is usually done on a single disk machine or is wanting the largest disk.

Now I could, I suppose, just return the first disk in the order as was done in the past, but I had to make the function a little more robust to account for link based lookups on the disk, serial, wwn, uuid, etc…

So I just added the bit to try to prefer the larger of the disk as the default writing disk.

@Bearr1976 is /dev/sdb larger than /dev/sda by chance?

@Clebboii Figured it out and should be workign without breaking security, in dev-branch. Please give it a shot or as I asked earlier, happy to have another tester on 1.6 branch

@Tom-Elliott This was not the proper fix, looking deeper.

@Clebboii Okay, I think I found a fix, though it’s probalby super ugly, but I do seem to see the log viewer is working once again.

please change to dev-branch and do a git pull then install, and hopefully your Log Viewer will be working and functional again.

@Clebboii This is probably true. We learned about a security issue and worked to solve that problem. I’m seeing what i can do to recover this feature, but it may take some time.

This feature is working on the working-1.6 branch if you’re willing to be a little on the bleeding edge (testing would be good for this branch. I’m pretty sure it’ll work for 99% of your needs without much issue, but without enough testers testing this, it’s a slow process.)

My testing shows with the security issue that was fixed, I’m still able to see the log viewer.

It’s difficult to simulate between the different 1.5.x and 1.6 for me.

I’m seeing if I can build a VM that would do the 1.5 side of things, but I’m not putting all my focus into that version of things any more. We are close to 1.6 finally, just need more people letting us know of anything they see.

If you’re unable to test that I understand, and I’m going to try to fix what I can if I can figure it out, but it’s not a top priority for me at least.

This feature is useful, but not a make or break thing for FOG’s operationality in my eyes. I hope that makes sense.

Often time,s this seems to be due to UEFI Secure boot being enabled when it should be disabled.

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