It’s completly dumb i just didn’t created the image entirely so i couldn’t upload anything ^^"
But thanks anyway for your help and your work !

Issue solved, yet we have now version 1.5.9 RC and there is new problem with node offline

@scosta Sorry but I don’t get what you mean by that quoting the term ClusterSSH as well. Please rephrase your question.

Thanks for your time and response.

Yes, any of those 3 commands didn’t work.

Based on information from that topic in REAR GitHub - the user after using PXE mode, they had pxelinux config and probably as you mentioned kernel (kernel file) and maybe file system (initrg.cgz) for BIOS, not UEFI.
I guess i have the same and trying to boot on UEFI system.

How to determine which file is for UEFI? I guess it should be part of ISO which works fine on BIOS and UEFI system.

I have this content of ISO:

Then I have this content in ISO:
EFI G:\EFI
boot G:\boot
isolinux G:\isolinux
BOOT G:\EFI\BOOT
fonts G:\EFI\BOOT\fonts
locale G:\EFI\BOOT\locale
BOOTX64.efi G:\EFI\BOOT\BOOTX64.efi
embedded_grub.cfg G:\EFI\BOOT\embedded_grub.cfg
grub.cfg G:\EFI\BOOT\grub.cfg
grubx64.efi G:\EFI\BOOT\grubx64.efi
grub G:\boot\grub
efiboot.img G:\boot\efiboot.img
grub.cfg G:\boot\grub\grub.cfg
boot.cat G:\isolinux\boot.cat
chain.c32 G:\isolinux\chain.c32
hdt.c32 G:\isolinux\hdt.c32
initrd.cgz G:\isolinux\initrd.cgz
isolinux.bin G:\isolinux\isolinux.bin
isolinux.cfg G:\isolinux\isolinux.cfg
kernel G:\isolinux\kernel
ldlinux.c32 G:\isolinux\ldlinux.c32
libcom32.c32 G:\isolinux\libcom32.c32
libgpl.c32 G:\isolinux\libgpl.c32
libmenu.c32 G:\isolinux\libmenu.c32
libutil.c32 G:\isolinux\libutil.c32
menu.c32 G:\isolinux\menu.c32
message G:\isolinux\message
pci.ids G:\isolinux\pci.ids
rear.help G:\isolinux\rear.help
reboot.c32 G:\isolinux\reboot.c32
vesamenu.c32 G:\isolinux\vesamenu.c32

UPDATE:
Checked permissions fogproject:apache user has full rights to all snapins, why it is the apache group I don’t really know.
also changed the www.conf file.
No change unfortunately.

@george1421 said in High load average when capturing image:

@benjamind Some additional questions/tasks.

How is the virtual machine host server connected to its storage, over iscsi or nfs. I’m talking about the proxmox server connected to the VM’s storage.

Over NFS.

Will you capture another process capture just like you did for the static load but capture it while the target is still acquiring the image. The partclone screen should be on the target computer.

Here is the capture :

2020-06-29 15_52_21-pc5053b.png

The top processes do not seem revealing to me because they change very regularly.

@UWPVIOLATOR said in Interface not ready, waiting for it to come up FOG 1.5.8:

I could not do grep php /opt/fog/.fogsettings as I tried a fresh install. fogsettings-firstInstall

I think we are mixing up way too many things in this one topic. It was about FOG on CentOS 7 and upgrades. Now we are talking about Ubuntu 19.04 fresh install. May I please ask you to open new topics for new issues to prevent confusion and missunderstanding? Please open a fresh topic for the Ubuntu fresh install and I will move the posts over.

While I am not sure yet it seems like there is an issue with PHP version numbers when using FOG 1.5.8 on Ubuntu 19.04. The later is end of life already and we won’t backport fixes to FOG 1.5.8 either. So you might want to think about giving the most current versions a try as it seems to be a fresh install anyway.

That’s a bingo.

However I found this topic: https://forums.fogproject.org/topic/13172/how-to-create-a-fog-ipxe-menu-entry-that-deploys-a-specific-image
A nicer representation with of args through pictures. That topic does go into creating a new iPXE menu entry, which is what I plan to do in preventing fog.deployimage from getting mucked up.

Oh this topic too: https://forums.fogproject.org/topic/8760/pxe-boot-menu-advanced
Though it’s a little dated.

@george1421 you provided some good keywords to help me find those topics.

 

For those that find this post. The steps to my solution:

Use the link george provided, though you don’t need mac:
http://<fog_server_ip>/fog/service/ipxe/boot.php?qihost=1&username=<fog>&password=<password>&imageID=<image_id> To get a better understanding of what you are copying and what is all defined and how they are reprosented read this post:
https://forums.fogproject.org/topic/13172/how-to-create-a-fog-ipxe-menu-entry-that-deploys-a-specific-image In your iPXE menu Parameters text box you just need the long line that starts with kernel making sure to replace bzImage32 with bzImage and init_32.xz with init.xz
Next line: imgfetch init.xz
Then boot as the last line

Thanks again for the help @george1421

@babouche said in Force bios to PXE boot after task:

Start PXE…
Check media presence…
start pxe over ipv4 on mac: XXXXXXXXXXXX (stuck 30 seconds a this) Maybe it’s because i have radius authentification+dhcp.

This bit is part of your infrastructure. As you suggested it appears your NAC/NAP system is running a bit slow at this point. I think I would focus on understanding why this is slow, especially since during the boot process of the FOS Engine it queries for a DHCP address 3 times (once for PXE ROM, once for iPXE (fog boot menu), and once for the FOS engine). If you are getting a delay each time I can see why you have a slow booting process.

And then the tftp begin (it takes then 20 second to begin the deployment)

This sounds normal from my experience. The iPXE boot manager (program that creates the FOG iPXE menu) is small in size, about 1MB and the FOS engine (the OS that clones the hard drives) is about 28MB in size. These files should transfer really fast. The FOS Engine takes about 15 seconds to boot and start doing things.

@Sebastian-Roth that’s good news! I can test it out once it’s wrapped in. I tried what John did, but didn’t have any luck. Also tried following the wiki post on HTTPs/custom certificates that you shared in the other thread, but was still getting the overlength error. I decided to just use the certificate that FOG creates on install instead of my custom one for now.

@Tom-Elliott Perfect ! Thank you.

@eseo-fcolas Unfortunately this is a known issue but needs major work which we don’t have time for at the moment: https://github.com/FOGProject/fog-client/issues/116

If you are keen to get this to work you are more than welcome to join in and work on this part of FOG/fog-client.

The other thing I might suggest is that most Linux systems can be configured to pull hostname settings via DHCP. You might want to look into this. Or you can use FOG post-deploy scripting to modify hostname config files on the destination system before doing the first reboot.

@TBCS You are right, can’t do debug in multicast mode. I should have stated more clear. The debug was only meant to figure out the sgdisk .... issue. Not the multicast one. This happens when we talk about different issues in the same topic…

Logs are always welcome. More information is always better than none.

I set up a new virtual machine using Microsoft’s new scripts.

Then I captured an image from the virtual machine with FOG and multicast it to four computers, and they all UEFI booted fine.

The new CreatePartitions-UEFI.txt puts the system partition first, instead of the recovery tools partition. This supports @george1421’s theory that FOG was confused when it found the recovery tools in the first partition, instead of the EFI (“System”) partition.

Thank you for your help!

rem == CreatePartitions-UEFI.txt == rem == These commands are used with DiskPart to rem create four partitions rem for a UEFI/GPT-based PC. rem Adjust the partition sizes to fill the drive rem as necessary. == select disk 0 clean convert gpt rem == 1. System partition ========================= create partition efi size=100 rem ** NOTE: For Advanced Format 4Kn drives, rem change this value to size = 260 ** format quick fs=fat32 label="System" assign letter="S" rem == 2. Microsoft Reserved (MSR) partition ======= create partition msr size=16 rem == 3. Windows partition ======================== rem == a. Create the Windows partition ========== create partition primary rem == b. Create space for the recovery tools === rem ** Update this size to match the size of rem the recovery tools (winre.wim) rem plus some free space. shrink minimum=500 rem == c. Prepare the Windows partition ========= format quick fs=ntfs label="Windows" assign letter="W" rem === 4. Recovery partition ====================== create partition primary format quick fs=ntfs label="Recovery" assign letter="R" set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac" gpt attributes=0x8000000000000001 list volume exit

@El_Pagrxn27 I guess I’m doing a terrible job explaining what I see.

If we refer to the picture you provided. You see /dev/sda is exactly as you say the 1TB hard drive connected to sata5. Also you see that /dev/sdb is exactly as you say the 256GB drive. Now what I’m saying is the partition layout for both the 256GB and 1TB drive are exactly the same. So something happened here. I would expect /dev/sda3 to be ~900GB in size, not 256GB unless this is how its configured on the source computer. I would say the layout that is on /dev/sdb is a typical windows boot image format.

disksize.png

I’m suspecting some how the image for disk /dev/sdb was overwritten onto /dev/sda. This is why the target computer will not boot.

While I understand this is how your fleet of computers are currently setup, the configuration is a bit uncommon. The more common approach is that the boot/OS disk to be on /dev/sda (i.e. lowest sata port number) and the storage disk to be on some sata port number higher than /dev/sda (5 in this case). Now understand that it is possible to have the OS disk setup like you have it and work, but FOG may be making an assumption that you have a default design. I don’t know this bit yet. Right now I’m having a hard time understanding why both disks have exactly the same partition layout.

@hancocza Ah sorry, I thought you’d know how to do that.

Go to the directory where you usually run the installer from, I’ll just use /root/fogproject her in the example but make sure you use what you have on your system extracted already.

cd /root/fogproject/utils/FOGiPXE/ ./buildipxe.sh /etc/ssl/certs/Certs/gd_bundle-g2-g1.crt cd ../../packages/tftp/ find -type f -exec cp -Rfv {} /tftpboot/{} \;

This is partly outlined in the wiki but still needs more consideration: https://wiki.fogproject.org/wiki/index.php?title=HTTPS#Custom_CA_and_certificates

@Tom-Elliott
Ok, thank you for you answer.

@george1421 Thanks again