@george1421 I try it to install several times but i have same issue with missing files(i try github version too).I also try re run install on existing FOG server but same results .Can you please advise most stable or more less problematic linux distribution ?Fog-install.txt

Thanks all. It makes sense why it was happening now. @Quazz Yes, it was a legacy 10 install that was converted to EFI.

I have 15 identical systems. All have the same size 120GB SSD drives and only one partition. All have the same W10 build. I have imaged roughly half of them, and the size of the image is always under 20GB. One of the systems is imaging at 119GB. I am doing the same steps each time. Don’t know what’s wrong with this one station! I have tried to upload a picture and I get “sharp” errors.

@Malte-Will bump

@jhumpf All I can say is that based on the two to three years of using that configuration for different fog admins, we haven’t needed to deviate from that configuration since dnsmasq is not giving out dhcp addresses the mask “should be” irrelevant. The remote subnets should just work as long as dnsmasq is being informed of them requesting a dhcp address. If you want to debug deeper into the matter, I would suggest that you reset the configuration back to what I have in the article then follow this procedure to see if we can capture a bad remote proxydhcp request and then capture a good remote proxydhcp request so we can compare. There also may be some value in taking a computer on the remote “bad” subnet and loading wireshark on it. Start the capture filter of port “67 or port 68”. That would capture what the dhcp and dnsmasq are sending to the target computer, from the target computer’s point of view. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue Upload those 3 captures to a share file site and share them as public. Either DM me directly or post the links here and I will review them. My gut feeling is that you have something not configured right in your infrastructure not related to FOG or dnsmasq.

@Matthieu-Jacquart said in Host Screen Resolution: I’ll make a try on another PC because this one is pluged on a KVM hub, so maybe screen is not well recognized… Give it a try but I am farily sure the code is still not right. The module was never ready for production and so it needs more work I think.

@hj104 said in Scheduled Tasks (Delayed / Cron-style) not working, but instant tasks are.: My only question now is whether restarting the server has the same effect on the FOGScheduler service as running systemctl restart FOGScheduler? I am pretty much sure this can be answered with yes. Sorry but I have no idea why this was wrong in the first place but working now. Seems like you have not changed anything.

@Lee-Rowlett That is a sound route, I’ll keep it in mind while I dig into it. Yeah, I was hoping it was some other reason than permissions, but somehow over the last week permissions changed on the server, so it is probably how I’ve got it setup. The main system is installed on a 512 GB M.2 Nvme, and the images are stored on a 2TB HDD that I have mounted to the images folder. The permissions didn’t have a date last changed, so I’m guessing something happened with that mount at some point, maybe a power outage or brownout and maybe it reset the mount long enough to fubar the permissions? Pure conjecture… but it was a permissions issue…

@alesser said in PXE-Booting a Modern Ubuntu live CD via UEFI mode: I simply want to boot a linux live CD in EFI mode when the option is selected, run a script, and then stop. Reading between the lines here, I wonder if another approach would be better/faster/greener? Let me tell you a bit how fog images computers. The iPXE menu in conjunction with the boot.php program send 2 files to the target computer with some kernel parameters that tell the target computer what to do. Those two files are bzImage (the kernel) and init.xz (virtual hard drive a.k.a initrd). Those two files make up the os known as FOS (Fog Operating System). FOG uses buildroot to construct the initrd as well as compiles bzImage. So one might wonder, do you need a full commercial OS run your script or just a linux OS? Do you need a persistent disk storage or once the script runs can the virtual machine just disappear? So the grey beard hacker in me wonders if you could take FOS Linux delivered by the FOG server to do your bidding? Unless you are doing something crazy (like vlans, wireless, packet filtering) FOG’s bzImage should do what you need. It supports both uefi and bios modes, as well as init.xz. FOG supplies both a 64 bit and 32 bit version of FOS Linux. So how do you hack init.xz to not image your target computer? Simply unpack the inits https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image Once you unpack the inits then look in the /etc/init.d directory for S99fog and delete it. Repack the inits and then pxe boot the computer again. Now you have a command line linux OS to play with that boots in under 15 seconds and disappears when powered off. The entire OS fits into 512MB of RAM, so its very VM friendly. If you need persistence memory just map an NFS share and grab your persistent data from there. You might want to look into the /etc/init.d/S99fog file a bit deeper since you want to run a script the S99fog to do your task. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S99fog Now what do you do if FOS Linux doesn’t contain the linux programs you need. Welp, then you need to turn to build root and build your own init.xz (initrd) file. No worries since the FOG Project also provides the buildroot config file and fs overlay you need in the github site. https://github.com/FOGProject/fos/tree/master/Buildroot

@Sebastian-Roth said in Development FOG not capturing image - PartClone update: @shruggy Would you mind telling us which version of partclone this is? It’s the latest git shapshot: https://github.com/Thomas-Tsai/partclone/tree/58d138da6e0f473acd80a7c9b8544d104377d50f with the fix you suggested: $ cd git/fos/Buildroot/package/partclone $ ls Config.in partclone-0.3.12.patch partclone.imager.patch partclone.mk $ cat partclone.imager.patch diff --git a/src/ddclone.c b/src/ddclone.c index 04f8775..cab5386 100644 --- a/src/ddclone.c +++ b/src/ddclone.c @@ -30,7 +30,9 @@ void read_super_blocks(char* device, file_system_info* fs_info) } strncpy(fs_info->fs, raw_MAGIC, FS_MAGIC_SIZE); fs_info->block_size = PART_SECTOR_SIZE; - //fs_info->device_size = get_partition_size(&src); +#ifdef IMG + fs_info->device_size = get_partition_size(&src); +#endif fs_info->totalblock = fs_info->device_size / PART_SECTOR_SIZE; fs_info->usedblocks = fs_info->device_size / PART_SECTOR_SIZE; close(src); I haven’t yet pulled the latest FOS, however. So it doesn’t contain the changes to func.sh by @Tom-Elliott i.e. no special case for partclone.imager. On the other note, when using unpatched Partclone 0.3.12 I also sometimes got segmentation fault, but didn’t report it. The case when Partclone finished successfully, but actually didn’t capture the partition was the more common outcome. I’d say, somewhere in the relation of 4 (empty) successes to 1 segfault, IIRC. And I didn’t notice any pattern to segfaults then (e.g. it could happen with or without compression).

I’ve removed Arch Linux from the automated tests due to complications within Terraform. These issues were sort of the final straw in my Arch testing efforts. The Arch community doesn’t supply an official AWS AMI. I had been relying on a privately built AMI that isn’t 1:1 with a manual Arch installation. For perhaps the last half year, my Arch tests were failing but the installer worked if you tested it against a manually setup Arch installation. This can only be due to differences between the AMI I was using and a manual installation. The Arch community is vehement about only providing help if you follow their installation instructions on their wiki exactly. Because of this, when I asked for some help sorting out the issues, they were not willing to help. Until someone with some Arch prowess can put some time into helping with this, Arch Linux will not be included in the automated tests.

@nextechinc I can’t answer that. If you can tweak 5.4 with the newer driver then go for it. 5.5rc may also work. I guess the question would be how many NUCs do you have and what would take the least amount of effort to do (probably 5.5). Understand that you can define a custom kernel for each host definition. SO what ever direction you go in keep the kernel name unique and only assign that kernel to the systems that need it.

@UWPVIOLATOR If you can’t get the application to behave with respect to the restarts, you could always create a snapin pack bundling the executable with a script. In the script, you could check to see if the application was already installed and of the correct version, then if it wasn’t perform the install. if you wanted to kick off the application and then do something like loop while the executable was running, you might want to play with the start command, something like start "" installer.exe -args. https://ss64.com/nt/start.html @george1421 the /k flag runs the specified command then leaves the command window open. https://ss64.com/nt/cmd.html

It appears (guess) that FOS or iPXE is seeing two different network adapters as nic0. It is possible to boot FOS Linux from a usb stick. The issue is that the deploy image function you use is a product of iPXE and not avaialble via the FOS Linux usb boot method. With that said there is a hack of the FOS Linux usb boot hack that can simulate the “iPXE Deploy Image” menu. I posted instructions on how to do this with graphical representation late last year but I can’t seem to find it at the moment. In this post it kind of explains how to do it with the FOS Linux grub menu. https://forums.fogproject.org/topic/12842/fos-boot-usb-quick-image-issue/12 Edit: Ah I found it, look at the last post in this thread: https://forums.fogproject.org/topic/13977/suggestion-please/66?lang=en-US&page=1

@explosivo98 Strange that kernel should boot because the only thing added was some apple hardware IDs and an apple disk patch. Nothing for non-apples should be impacted.

If I remember correctly the X90s was the first model to support uefi booting (not via the network) The x010s were the first models to support network booting in uefi mode. So a couple of things first for the x010s, while they will pxe boot in uefi mode, iPXE will hang initializing the devices and sit there forever. So this workaround will with for both the 790 and 7010s. You can image the machines in bios mode, but switch them back to uefi mode before the first boot into OOBE. The easiest way to do this is to have fog power off the device after imaging. So you will have a tech standing in front to power it on to go into the F2 bios screen and switch the mode to uefi before oobe runs. The second option is to boot FOS Linux from a usb stick with the hardware in uefi mode. FOS Linux (the OS that is downloaded via iPXE) boots correctly in bios and uefi mode. Since iPXE and pxe booting is not used there is no conflict. The third option is don’t use 12 year old+ hardware (which isn’t probably an option)

@cammykool I would search for bonding and your linux distro. Bonding or teaming (depends on which method you use) is setup at the OS level. You will also need to get with your infrastructure folks to setup the switch the fog server’s plugged into for bonding. I would suggest LACP also called 802.1ad. Both the switch and the server needs to be configured for the same bonding type. When you setup bonding on the linux side, it will create a new network adapter typically called bond0. That virtual network adapter will then talk to its slave interfaces (the real physical nics). You will apply the IP address to the bonding nic and not the physical nics. The bonding driver will manage the physical interfaces once its setup. When you configure FOG you will tell it to use bond0 (or what ever the bonding interface name that is created). Once you have bonding setup and WORKING at the linux level then you can forget about it and install FOG. Don’t install FOG without or before bonding setup.

Solved. OMG it’s so good to have another set of eyes on. Talk about not seeing the tree for the forest! I am watching first clone progress. This is far further than I was ever able to get with Symantec ghost - never could build their PXE client. Thank you so much Sebastian.

@Sebastian-Roth Yes, sir! My apologies for not doing this sooner. https://forums.fogproject.org/topic/14116/development-fog-not-capturing-image-partclone-update