@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.

A reinstall helped correct the problem with the password.

I just started over with a fresh db and imported hosts from old environment. No need to look into the issue any further unless someone else has it.

@thopman 1.3.5 RC 3 was released today, if you wanted to try that out. Otherwise you can wait for the official 1.3.5 release.

@Tony-Ayre

Thank you very much, This may help someone in the future with a similar issue 😉

I appreciate you taking the time to explain your issue and your resolution!

Moved to “FOG Problems”.

@Lenain I can’t understand how/why this is a fix. I’m going to update my prod instance fro 1.3.4 and see if I can duplicate it. I’m currently on 1.3.3.

@jamcdonald120 said:

if we assume that the DHCP setting of the router are correct (they worked before) …

I am sure I have heard phrases like this more than a hundred times and it quite often turns out …

Asking the web to see what other things could cause this issue I see that the error message you posted is not quite the same most other people report - which is: PXE-E53: No boot Filename received (see the difference between ‘File’ and ‘Filename’?). Your positive test of trying to load the undionly.kpxe (how do you know your server is using this file and not ipxe.kpxe which we also use sometimes?) binary file makes me believe that your TFTP and the files on it are fine. This would emphasize even more that something is wrong with the DHCP! The message essentially says: “I got an answer from a DHCP server but no information on what file to load for PXE booting”.

You need to understand that DHCP is always a bit of an issue. This is because even if neither you nor any colleague changed the “original” DHCP server you can still run into problems if someone added another DHCP server answering requests in your network.

Please try this: Make one of your clients ready for turn on and PXE boot. Install and run tcpdump - a tool to capture network traffic - on your FOG server.

sudo -i apt-get install tcpdump tcpdump -w /tmp/dhcp_traffic.pcap port 67 or port 68 or port 69 or port 4111

Leave that command as is and start up the client till you see the error message on screen. Then stop the tcpdump command (Ctrl-c) and upload that packet dump file (/tmp/dhcp_traffic.pcap) from your server to the forum here.

@rbasart Well, that certainly could do it I suppose.

As far as it “partially” working, the switch IS the IP address, and FOG had “listeners” on that IP.

As the switch received the data, the FOG Server would perk up as well.

Glad you figured it out for sure there. Sorry I didn’t recognize this, but hey one more thing to “look” for.

how i mark solved?

Sounds like your hdd might be full. You can check with df -h look for partitions with 99% or 100% use.

In addition to what Jaymes asked below, also look through your apache error logs.

@craigcoulson said in Debian + svn = error:

nevermind all - i rebuilt the server with only minimal packages and re-ran the svn install of Fog and it worked fine - go figure.

Glad to hear you got it working 😉

@Tom-Elliott This, this is why we love you.