@george1421
What’s odd is that it doesn’t work in legacy mode on my laptop but does work in whatever the other mode is. I wouldn’t call it UEFI mode because the laptop has both UEFI and BIOS modes and is permanently set in BIOS mode. It is indeed UEFI mode. The other odd thing about all of this, is that it works in both UEFI and BIOS modes when booting as a virtual machine in ESXi 6.5 which is where I have been doing most of my testing since it is much easier than rebooting my laptop over and over. I am going to continue to play around with it. I can always fall back to booting any systems that fail PXE booting by booting from the GRUB4DOS USB harddrive and/or flash drive which accomplishes the same thing. I was just trying to avoid having to have the USB drive available at all times. Plus since I have ethernet throughout the entire house, it was a fun project to work on.

@sourceminer We don’t have restrictions on opening new threads. There is no need to post in an old one, especially if your issue is quite different! So please open a new thread for your issue and tell us more about your setup as this is most helpful in most cases: OS version, FOG version.

Beside that: See I am not a graphic wizz but do you know about things like alpha channel, color depth and stuff like that. Maybe that image you exported can’t be handled by iPXE, maybe.

Don’t try to mount it on your FOG server (it won’t work), just configure the Storage Node page with the relevant info of the NAS itself. (ip, FTP username and password, images location) and it should work fine.

@wayne-workman Everything still seems fine for this. Still can’t figure out how to mark as solved, but someone should do that if they can.

I guess it is. Marking this solved.

@barnzy said in HTTP 500: Internal Server Error:

I went to /var/www/fog/lib/fog/config.class.php to find that there was a password that I had set in the setup, once I had cleared this password I checked the mysql connection again and it was working!

Ofcourse that file is editable, but we don’t recommend people to edit it. Set the correct parameters inside of /opt/fog/.fogsettings and then re-run the installer. ELSE, the very-next-time you run the installer, it’ll be broke again because the installer will set the settings inside of /opt/fog/.fogsettings.
See this as a reference: https://wiki.fogproject.org/wiki/index.php?title=.fogsettings

However, kudos to you for using the troubleshooting article in the wiki!

@unknownhost99 From what you are saying I understand that you installed debian and FOG as a master node in the USB key (which is fine). Right?

Now you want to add a storage node to the setup? A storage node by definition has to be a new node/PC/machine/VM/system (you name it) but cannot be on a second hard drive on the same system!

By the way, which version of FOG do you use?

@m-fitzgerald Can we mark this solved?

@JGallo Interesting suggestion…

@wayne-workman That should be it

IP address The name of the new card as known by linux.

Fix the .fogsettings file and rerun the installer.

I might just look at the webgui in the fog configuration as well as the storage node settings for this fog server to ensure the name of the network interface matches what is now defined in linux.

Just throwing my 2 cents worth in because we also have 2 domains, but segmented networks with the exception of FOG talking over both networks. But that shouldn’t matter for this.

I have set up my primary domain information in FOG as a default. I then created Locations (Using the Location plugin) and host groups for each remote location. I then placed the machines into each of their respective host groups and applying the specifics there.

Once you have the machines you want on one domain placed into the host group for your Old domain, you can apply the AD information to that group allowing the Host that needs to remain on your Old domain to re-join it. You can do the same for the New domain as well.

Simply put: Create 2 Host Groups. “Old_Domain” and “New_Domain”. Place the hosts you want to keep on the old domain in the “Old_Domain” group and apply the AD information to that group. Then Place the hosts you want to be on the New Domain in the “New_Domain” group and apply the AD information to that group. Your hosts will stay on the domain you specified to each group.

Re: Can’t image from storage node
Not sure what happened but it seems to be working now. Well imaging from the storage node works when I tried it last week in another group of computers from a separate image that’s stored on the server. I saw the storage node IP on the client computer when imaging.
I have not touched or updated neither the main or node servers.
I have not tried to image from LABGEN from storage node. so 50% working from the main issue. Will follow up or capture a new iamge for LABGEN image soon.

thank you everyone!

@george1421 said in Uncompleted multicast:

This fix is interesting too.

$ sysctl -w net.core.rmem_max=16777216 $ sysctl -w net.core.rmem_default=16777216

rmem* changes helped when I was testing directly with udp-sender/receiver and when the received data was directed to /dev/null. Successful test deploy with 1 vCPU VM hosts (additional writing to the disk) that I mentioned in previous posts was with half-duplex mode which I forgot to change back to full-duplex. Full-duplex on Xen VM host is still problematic, high number of re-xmits and aborted multicast.

Xen servers’s internals switches are difficult to debug and I’m not sure where the packets are being dropped but there are some lost packets on Xen servers’s internal switches too. Xen VM booted in debug mode was still dropping RX packets too when full-duplex multicast was used. I’ll try to consult our Xen Server support to check settings on the Xen Servers. From few posts I have seen, Xen’s Open vSwitch has very small queues by default which could be a problem for UDP cast.

On the physical host, before changing rmem*, there were dropped packets on the Extreme switch on the port connected to the PC so my conclusion was that the problem was (mainly) on the receivers.

In my environment, I think I’ll stick to half-duplex mode which allows receivers to sync more often so that buffers are not maxed out. I did not find another udp-sender parameter which would allow control of how many packets are sent without the confirmation from the receiver.

After creating the /home/fog directory, run the mkdir /home/fog
chmod 755 /home/fog
chown fog: fog /home/fog
and fix the FTP passwords, everything went back online.
Thanks Sebastian

@sjensen said in Selected boot device failed:

So basically i need to try the different bios setups combined with the different binaries in order to capture an Image of this Dell XPS13?

As I said, it’s probably a lot easier than debugging why undionly.kpxe doesn’t work at all and undionly.kkpxe has transfer issues…

So it’s all about the combination of Laptop, firmware and USB dongle. Here is a forum thread where someone was able to PXE boot in BIOS legacy (undionly.kpxe) with a USB dongle also based on the RTL8153 network chip. But as I said, it’s always a bit different as soon as you change one component in the equation.

And here Dell is saying that “The XPS 13 with BIOS A05 or higher, supports PXE boot with LAN7500 chipset based USB NICs.”

Just want to show you that there are many different ways and people were able to PXE boot the XPS13 but you can only know for sure when you test with the components you have at hand.

Edit: Hope this is not causing too much confusion. Just wanted to show you that there are different solutions out there and trying to do plain UEFI might be the easiest one or at least worth a try. Here is a thread where the same issue as yours is described and was solved by switching to UEFI.

I found the mistake. The service configuration of FOG contained the fully qualified name as hostname. I replaced it with the IP address and it worked and the menu looked different too.

@dsloan-ethra So just to recap what was done here to adjust Debian 9 (where the referenced article also implies it is an issue for any Debian variant like Ubuntu) for others that might find the thread:

Edit /etc/mysql/mysql.conf.d/mysqld.cnf
vi /etc/mysql/mysql.conf.d/mysqld.cnf Insert the following line in the [mysqld] section
max_connections = 8000 Copy the systemd service descriptor file so you can customize it
cp /lib/systemd/system/mysql.service /etc/systemd/system/ Append the following lines to this file: /etc/systemd/system/mysql.service LimitNOFILE=infinity LimitMEMLOCK=infinity Reload systemd processor
systemctl daemon-reload Reload the mysql service
systemctl restart mysqld Login to mysql as root and run the following command.
mysql> show variables like 'max_connections'; The response should be something like +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 8000 | +-----------------+-------+ 1 row in set (0.01 sec) Done.

These are not my words, only restated from the accepted solution here that Sebastian found and referenced: https://www.rfc3092.net/2017/06/mysql-max_connections-limited-to-214-on-ubuntu-foo/

I was also facing the same problem from a long time and I was not getting any solution for this.
But after visiting this forum, I get my questions solved, answers shared in this forum are very good and very easy to implement.

[Moderator’s note: removed link to commercial website]

@NatLanis Have you deployed that image to a machine yet?

@greventlv said in How do I FOG my FOG server?:

I know that’s something that I can do, but I have a bunch of other stuff on the server and during production breakdowns, it would be a lot faster to hit a few buttons and get everything back to the original state without having to deal with a new install, restore and etc.

Then really you should build a fog server in a VM and just snapshot it. That’s literally ‘a single button click’ to restore from a past state.