I read everything written here and thought about this: If earlier such manipulations were possible, is there a chance that Windows still did not provide for something. Is it possible to hack the system and change the memory size for updating? How is this even possible? I used to contact raid data recovery to recover the data I lost during the system update process and thought that even if they can retear the data, is it impossible to change the amount of memory used by this data?
@dashwell Well you said you updated from an older version and you think the update is causing this problem. While I still don’t think the update caused this I still was wondering what version you used before.
Back to the problem: The error is pretty clear. The image was taken from a larger size disk. Probably using an older version of FOG which did only shrink but not rearange partitions (to fill the empty gaps). The version you currently use (20220203) is capable of rearanging partitions but you need to re-capture the image with that version to make use of it. So I suggest you grab a machine with a disk large enough, deploy that old image to it. Then create a new image definition within the FOG web UI (to keep the old one as backup), set this new image for the machine you just deployed the old image to, schedule a capture to the fresh image definition and then try to deploy this new image to smaller size drives.
@c4c@george1421 I can assure you that there should be nothing special that build.sh is pulling or doing. While we have different branches like master (latest official) and dev-branch (development) in the fogproject repo this is not the case in the fos repo. I always use fos master to build stuff. If I do really fance new things I create short temporary branches but merge those into master again as soon as things are ready to go.
One thing I just noticed in George’s desciption is using make -j4 to build. The official manual states that “Buildroot does not support top-level parallel build” (reference). Though I can’t really think of this causing the problem described.
When a package is removed from the configuration, Buildroot does not do anything special. It does not remove the files installed by this package from the target root filesystem or from the toolchain sysroot. A full rebuild is needed to get rid of this package.
@dgux Will be interesing to see if you can get this to work. Though iPXE is just the starting point. You will need to set Linux kernel parameters for serial console as well. That’s pretty easy within the specific host settings. But I am not exactly sure if we have serial console driver compiled into the official kernel yet. Not a big deal though. See how far you get and keep us posted.
At step 16, I do not get this printout from df -h as listed above. The directory /image and /snapin are linking to the /opt/fogdisk which is mapped to the new disk partition, but for some reason, the /opt/fogdisk/images and /snapin are mapped to the root partition. Any recommendations? Did I miss something?
When I run mount, I get the following:
/dev/xvdb1 on /opt/fogdisk type ext4 (rw,relatime)
/dev/mapper/ubuntu–vg–1-ubuntu–lv on /opt/fogdisk/images type ext4 (rw,relatime)
/dev/mapper/ubuntu–vg–1-ubuntu–lv on /opt/fogdisk/snapins type ext4 (rw,relatime)
Is it built for scenarios like this, or is it better to use it only with an active VPN? But in this case, remote wipe would be impossible.
FOG was not designed with that scenario in mind. I would not suggest to run a FOG server facing the internet unless you know what you do - being able to secure the whole setup.
I don’t think remote wipe will work because it needs PXE boot to start into such a task and it’s very unlikely someone sets things up in their own network after stealing a device.
Using FOG behind a VPN is good practice if you have different locations. But you might think about using separate FOG servers as well because imaging across the internet can be a pain if connection speed is limited.
I would like to know about the “Searches: Limit the range of the search to the resources of one or more locations. The restricted user only can see the hosts, groups, images that are link or associated to his/her location/locations.”
How is it possible to do it? In the Location plugin, we can only put informations about Storage.
@primofamilia In general when storage node #3 comes back online all changed images will be resynced to the #3 site from the master node. This will happen all automatically. You will have to do nothing more than bring storage node #3 back online.
With that said if your new site #3 will have a different IP address range, or more specifically the storage node will have a different IP address than at the legacy site you will have a little fixing up to do to bring the node back online. But its not that hard to do.
I realize its 4 year old information but its still accurate and works for Win10. The thing you have to remember is that linux is case sensitive so you need to make sure your data path to the drivers is in the case format that is known and expected. You can surely debug your setup and make it work.
That is correct you should not find pxelinux.cfg because that is for the syslinux boot loader not iPXE. To add items to the iPXE menu you do that via the web ui in FOG Configuration -> iPXE Menu, menus. There is no need to hand edit the boot menus.