its working, thank you!

@george1421 said in Wrong Partition is mounted during deployment. (FOG 1.5.7.56):

@Greg-Plamondon You might want to update your partition detection script to the one used here:

#!/bin/bash . /usr/share/fog/lib/funcs.sh [[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/" case $osid in 5|6|7|9) clear [[ ! -d /ntfs ]] && mkdir -p /ntfs getHardDisk if [[ -z $hd ]]; then handleError "Could not find hdd to use" fi getPartitions $hd for part in $parts; do umount /ntfs >/dev/null 2>&1 fsTypeSetting "$part" case $fstype in ntfs) dots "Testing partition $part" ntfs-3g -o force,rw $part /ntfs ntfsstatus="$?" if [[ ! $ntfsstatus -eq 0 ]]; then echo "Skipped" continue fi if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then echo "Not found" umount /ntfs >/dev/null 2>&1 continue fi echo "Success" break ;; *) echo " * Partition $part not NTFS filesystem" ;; esac done if [[ ! $ntfsstatus -eq 0 ]]; then echo "Failed" debugPause handleError "Failed to mount $part ($0)\n Args: $*" fi echo "Done" debugPause . ${postdownpath}fog.copydrivers # . ${postdownpath}fog.updateunattend umount /ntfs ;; *) echo "Non-Windows Deployment" debugPause return ;; esac

This one uses a bit more intelligence to find which partition actually has windows on it. I think your script is just picking the last partition and calling it good enough.

ref: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Thanks, That fixed it!

@Sebastian-Roth

Now that I have the necessary MAC addresses at least associated with the machine I am good for now. I will wait for a final release before I move. This isn’t a deal breaker kind of issue for me.

@Trev-lchs said in HP 250 G7 fails to upload image:

This is now resolved, on checking it appears that the kernel downloaded was the ARM64 instead of 64.

Interesting the ARM kernel gets as far as that on a HP 250 G7…

@NSD_Network_Admin @neodawg Just in case anyone of you is interested in this. The bug was fixed by this commit: https://github.com/FOGProject/fogproject/commit/66fa6f074c4662098ea38b811077f2ad25c09a46#diff-f21fb2470403477fe0c412911d1227f1

@EZY4 I think we both have different problems.
I would suggest that you open a new thread on this.

As a tip: Install VirtualBox + ExtensionPack and set up the network boot only.
VirtualBox has iPXE, which gives you more information.

Furthermore you can use wireshark to check what exactly your machine receives from the dhcp-server.

@george1421 Good to know. Thanks for the information and help!

I actually brought my laptop in from home, this I know is a uefi BIOS, on testing it, it booted into Fog with no issues ( it has been imaged in the past with FOG. So i then knew that UEFI boot was working. I have to hold my hands up on checking the HP 250 G7 it had not had secure boot switched off in the BIOS, this is a silly error and for this I blame my technician lol, (well i should have checked myself) on checking this morning i saw it was still on, I was lead down the FOG path after the kernel update failed. however i now have a different issue which i shall post.

@george1421 Yep thanks for your help George, we have it pixie booting now, unfortunately, on checking it this morning the Tech had not switched secure boot off in the laptop bios. due to the other issue i had been having i thought it was FOG, FOG is blameless in this instance.

@george1421 I was able to edit the Grub.cfg and add our Fog server IP in and then boot with USB and register and capture and deploy. Thank you again for all the help.

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.