@SusejNatas Thanks for providing your solution, Welcome to the Forums, welcome to FOG, and Welcome to LINUX!

We are happy to have you here! We are sorry no one got to answer you before you solved your own issue, but please don’t let that deter you from making suggestions, modifications, or asking questions!

I have marked your post as solved. If you feel this is in error, please let me know. Feel free to provide further details on how you determined, and solved the issue, as it will help others with similar issues in the future.

@Jaymes-Driver
It’s already the best !!! 😉

@Quazz http://www.thewindowsclub.com/offline-scan-using-windows-defender
https://www.deskmodder.de/wiki/index.php?title=Offline_Scan_beim_Booten_mit_dem_Windows_Defender

@FredG This is typically a spanning tree issue. We have also seen green ethernet (802.3az) cause an issue similar to this. But typically it is spanning tree at fault.

@Tom-Elliott Thank’s a lot!

@amo862 said in EFI Chainloading Failure - Venue 11 x86:

However, is there a way that I could write a separate boot.php file that only called i386 boot files and specify it in the TFTP x86 efi files or DHCP boot options or something?

Do what JJ Fulmer below said, that’s the best advice.

@x23piracy If it’s system wide, it shouldn’t matter, but that doesn’t mean much. System wide still is not “system wide” in the case of curl/wget/apt/yum unless you make sure the default configuration files with the same information.

@george1421 The changes have been made.

@Wayne-Workman Yes, it was confirmed.

I realized the problem, but was on a meeting call. I asked him to test the “fix” and he confirmed with me on chat.

thank’s Wayne !!

I’ll do it and comment results here later!!

@Wayne-Workman
I will build a test system using the newest versions of Debian and Fog today. I’ll post back soon with the results and maybe attempt to fix the older system later.

Thanks

@Tom-Elliott
Thank you, it work fine! Here my po file, it is perfectible but better french than google trad 😉
0_1486735555898_messagesFR3.po

@FredG That would also explain the “Waiting a long time to run post init scripts”. It mount’s the NFS store to perform the post init scripts running, if it can’t mount it it has a timeout value.

@x23piracy Do you have wiki access yet? You should be putting all these fancy pictures you make into there.

@AndrewC The menu entries look perfectly sound to me.

I would ask you to try this exact configuration on any machine you can get your hands on that is capable of UEFI mode (not mixed mode, turn that off). If it flat-fails across the board (which I doubt), that’s one thing. But if it works on any at all, then it’s likely something to do with the hardware or with the boot ROM ipxe.efi.

That error from your first post “Could not boot: Result too large” really sounds like it’s boot ROM related, or a hardware issue.

It could be resolved as simply as trying different .efi files. Your options to try are on your FOG server in /tftpboot. Just change your DHCP UEFI policy’s option 067 to a different file name, try them one at a time. Do a complete power-off on the computer you’re trying to boot with for each try.

@palloquin said in Passwords, I broke 'em...:

Why can I change the ‘fog’ user’s password through the web interface if this just breaks it…

I should clairify something here - the web credentials you use to log into the web interface are not the same credential-set as the storage node’s default ‘fog’ account. These are two completely separate and independent things. The wiki article called “Password Central” explains every single password in the FOG Server, how it’s used, what it’s for, where to change it. You might look through it if you’re really interested in learning more linux-config-dark-magic-stuff

@Zaarin Looking into this a bit. I dug around and found my old syslinux pxe menu. Here is a fragment of that menu

label Clonezilla Live MENU LABEL Clonezilla Live kernel /drbl/vmlinuz append initrd=/drbl/initrd.img boot=live live-config union=aufs nolocales edd=on noswap nosplash nomodeset noprompt vga=788 ocs_live_keymap="NONE" ocs_live_run="ocs-live-general" ocs_lang="en_US.UTF-8" fetch=tftp://10.96.150.59/drbl/filesystem.squashfs label undis3c MENU LABEL Universal PXE NIC kernel memdisk append initrd=unattended/undis3c.imz keeppxe label Centos52 MENU LABEL Centos52 kernel bootimages/centos52/c52vmlinuz append initrd=bootimages/centos52/initrd.img label dodshort MENU LABEL DBAN Drive Eraser DOD 5220-22m (short) MENU PASSWD #SoftKitty1# kernel dbkernel.bzi append initrd=bootimages/dban_ird.gz root=/dev/ram0 init=/rc nuke="dwipe --autonuke --method dodshort" silent label dban MENU LABEL DBAN Full Package MENU PASSWD #SoftKitty1# kernel memdisk append initrd=bootimages/dban.imz

The notable thing here is that I was using memdisk to boot (at the time) was a bootable 1.44MB floppy disk image file (.img)

Now if you have the Tasktypeedit plugin installed. There is also a memtest function listed there and you can inspect how that task is invoked. The notable fields are Kernel and Kernel Arguments. One could blend my syslinux menu and the memtest menu to be able to send a bootable floppy image file to a target computer.

According to the syslinux wiki you can also do the same concept with an iso image.
ref: http://www.syslinux.org/wiki/index.php?title=MEMDISK

The only 2 caveats I see here are:

your target computer must have enough ram to hold the iso image completely and enough remaining ram to run the application on the iso image. Since this is not a FOG generated task, there is nothing to clear the task from the active queue. Here is the warning from the memtest task
Memtest86+ loads Memtest86+ on the client computer and will have it continue to run until stopped. When you are done, you must remember to remove the PXE file, by clicking on "Active Tasks" and clicking on the "Kill Task" button.

@x23piracy

We have Kaspersky. Apparently the System Watcher module was blocking the client from communicating with the server. When this was disabled, the client installed. However, the Firewall module in Kaspersky also blocked tasks from the server to be executed on the client (remote shutdown for example). The bottom article might help other Kaspersky users, though we haven’t tried this yet as of this posting.

https://support.kaspersky.com/7914

@Tom-Elliott
Hello,
Thanks for your answer, I will wait for 1.3.5 release.

@scouseboy99 Just to be clear here, you built two complete FOG servers and then assigned one as a master node and one as a slave node? If this is the case you have a non-standard setup. There are valid reasons for setting up this configuration and it does work well with one caveat.

The typical setup would be to setup the remote server as a FOG storage node from the installer. A fog storage node is a full fog server but without a local database. In this configuration the storage node uses the database from the master node so its aware of all images that is replicated to itself.

In your setup you have two independant FOG databases. The replicator will still copy the images from the master node to the remote fog node just like with a remote storage node. The problem comes is that there is no (current) way for the master fog server to update the database on the remote fog server. There is a way to manage this. You can export the image definitions from the master FOG server and then manually import them into the remote fog server to synchronize the image definitions in the remote database. It sounds a bit complicated, but its not. You just have to remember if you add a new image to the master node, the image WILL be replicated to the remote fog server, you just need to manually add/import the image definition into the remote fog server’s database.