@slawa-jad I’m not sure I fully understand your question.

The exact information you posted tells you what is needed for resizing linux images. So yes, it is possible.

@ecoele What version of FOG are you running? I presume “stable” which we learned of a problem with the report downloads.

Please checkout dev-branch and install it and you should have the ability to download the reports again.

Or wait until Oct 15th when the next release will be rolled out including these fixes.

@Fog_Newb Yep, it’s as I suspected:

The Line:

Subsystem	sftp	/usr/lib/openssh/sftp-server

should be changed to:

Subsystem	sftp	internal-sftp

Then restart ssh services: systemctl restart sshd

Then your Storage Node testing should succeed!

@Fog_Newb Yep, it’s as I suspected:

The Line:

Subsystem	sftp	/usr/lib/openssh/sftp-server

should be changed to:

Subsystem	sftp	internal-sftp

Then restart ssh services: systemctl restart sshd

Then your Storage Node testing should succeed!

@Fog_Newb 1.6 prefers using SSH access for SFTP connectivity to the Nodes:

Can you output your /etc/ssh/sshd_config file? I suspect the sftp line is screwy at this point.

@Richarizard504 I’m not really sure how to help:

Can you do a hard refresh in your browser and see if that helps anything?

(CTRL + SHIFT + R in chrome generally)

I have a screencast where i show you all I did, and all works, so I’m thinking maybe cache isn’t loading the updated Javascript elements necessary for this to function appropriately.

@MarkG Can you increase the Loglevel and see if the kernel is spewing out anything?

I believe on the GUI there’s a loglevel under FOG Configuration->FOG Settings->Kernel Loglevel or something like it.

It’s defaulted to 4, but if you increase it, it should make the logging a bit more verbose.

I’m not holding my breath, but it’s worth a shot at least. Hopefully there’s more information we might glean if there’s anythign hidden due to the lower log level.

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