A simple test environment did not make things easier. All 6 computers have deployed via WOL in multicast without difficulty.

Previously, when multicast with about 25 computers some have failed at the WOL, and I can´t say what it might have been. All computers have identical settings in the BIOS, all had the same image history etc.

I’ll keep working on it.

Maybe it´s still a 1.4.0 problem. I’m a little bit scared to update the FOG, because failure would have serious consequences and work, and there’s really no time for it.

So, the mysql-fix postet by Tom Elliot helped. No need to rerun the fog installer.

@tom-elliott said in Ubuntu is FOG’s enemy:

TLDR; … or run the ALTER USER syntax shown below.

As a note, it seems this problem is specific only when the mysql account is the 'root' user AND the password is blank.

The “fix” if you must do it manually is to open a terminal and obtain root:
Super (Windows Key) + T then sudo -i (in most cases).

From there, open mysql with mysql -u root

NOTE: MySQL MUST be run with ROOT.

Run:

ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY ''; AND
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';

It’s okay if one of them fails. This is going to fix Most people’s issues.

I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.

To prevent this problem from happening in the future you could run:

apt-get -y remove unattended-upgrades (AS Root again).

@wayne-workman said in HTTP 500 Internal Server Error:

I’d suggest any new fog servers that you build use Debian 9 or whatever the latest Debian is. FOG has the simplest installation on Debian, and over the time that I’ve been monitoring - Debian has had the least amount of problems with FOG.

Thanks for the quick response. So, just running the install.sh again will help? The data is retained?

FOG 1.4.4, Ubuntu 16.04.

I cannot connect to the WebUI. The browser returns the following error message:

This page does not work

10.XXX.XXX.7 can not handle this request right now.
HTTP ERROR 500

I have no idea. Never had this before and we are running five active FOG Servers at the moment (since 2014).

@sebastian-roth said in Multicast Wake on LAN with Fujitsu Lifebook E556:

Just bumping this so we don’t loose track of it. @Deimos Let us know when you have new information on this.

Jap, I will. But now we have other FOG problems. “HTTP 500 Internal Server Error”. I will make new thread.

@sebastian-roth said in FOG 1.5.0 RC 10:

@loosus456 said in FOG 1.5.0 RC 10:

But you can’t blame people for thinking that it’s dead when there is zero communication for over two months.

This is just not fair! Why would we still answer questions on the forums on a daily basis if this project would be dead?! Can’t believe you just said that. About the rest see Tom’s announcement…

150/5000
FOG lives, evolves and we can all be grateful for this free, easy and reliable method of cloning. That has to be said.

@sebastian-roth said in Multicast Wake on LAN with Fujitsu Lifebook E556:

@Deimos Trying to nail this down at bit more… Can you connect a machine that does not wol to the switch port where the machine wakes up properly?

As well a question. Do I get this right. Machines waking up do this fine every time you try. And machines that don’t never do wol at all. Or is it a random thing, sometimes works and then not for the same machine?

I’ll test that as soon as the stressful exam time is over. In February I will start a comprehensive test and report the results.

@george1421 said in Multicast Wake on LAN with Fujitsu Lifebook E556:

@deimos So you say they all have the same version of bios installed. Are there updates available that may fix wol? I’m running out of ideas here, I don’t think its a fog issue at this point.

I´ll report, if I figured out the reason. I now do not think its a fog issue, too.

@george1421 said in Multicast Wake on LAN with Fujitsu Lifebook E556:

@deimos What about bios/firmware versions. Are they all the same?

The other thing we are seeing is if they are win10, windows shutdown sometimes stop WOL. We have seen that if the computer is shutdown by removing power and then repowering the computer WOL works, but if you shutdown from win10 running no WOL on the same computer. It has to do with the win10 fast startup feature. This would cause the condition that sometimes WOL would work and other times not work on the same computer.

I have to say that originally there was a windows 10 OS on board (retail original packaging), but we installed win7 and captured image from this.

BIOS has to be the same. They are student devices. I took a look at the bios settings from a device WOL is not working, but there are equal settings to a device working well.

@george1421 said in Multicast Wake on LAN with Fujitsu Lifebook E556:

@deimos said in Multicast Wake on LAN with Fujitsu Lifebook E556:

Fujitsu Lifebook E556

Just for clarity “only” that computer fails to WOL where you have other models that do WOL OK?

Yes, also other models, e.g. HP ProBook 650 G1 are working well.

@george1421 said in Multicast Wake on LAN with Fujitsu Lifebook E556:

@deimos said in Multicast Wake on LAN with Fujitsu Lifebook E556:

Fujitsu Lifebook E556

Just for clarity “only” that computer fails to WOL where you have other models that do WOL OK?

YES. That´s the miracle.
Some start in single deploy, some do not. Some start in a multicast session, some do not.
Configuration is: WOL enabled in all devices.

0. I will update to 1.4.4 later (after this great january deployment)
1. Same VLAN
2. No routers
3. I will check this --> even if all clients should be set up equally
4. Fujitsu Lifebook E556

Hello everybody,

I have the following problem: When I start a multicast session with about 25 computers, the WOL does not work on some computers. I have to start them manually. Sometimes non of them boots, sometimes all. I can´t figure out, why. The fewer computers in the group, the sooner it will work.

FOG 1.4.0

By the way: can I safely update to the current version?

I think the hostname policy of our company is the problem. We use year numbers and consecutive numbering as names for the hosts. And exactly in the query with one of the consecutive numbers results in several results of the query. Just there.
If I enter the entire name, it will only display that one host.
The case can be marked as solved.
Thank you for your cooperation.

The “problem” still exists. As far as I can tell, I have examined all possibilities. But e.g. if the timestamp is converted from milliseconds to YYYY-MM-DD hh: mm: ss or something, then that´s just the way it is.

It is not a real problem, the search results are clear and not so many, I always find the right host.

I think there is data that compares with my query (it´s always a number like 1234) and I can´t find it in the Web GUI output. e.g. I can´t figure out product key.

I understand that quite well. But the results do not make sense. The hosts are all the same devices. There are a total of about 500 computers. They only differ in name, mac, serial numbers and maybe in different first imaging date. So I checked the searching string in the serial numbers but no match at all. I searched meticulously and found nothing.

There is no other match in this string but the name (and for this I was searching for). Especially as the number I enter, depending on which, always different hosts are displayed. I can´t make head or tail of it.

As you can see in the photo, the search for a specific string yields a variety of results that I do not understand. Is there a reason for that?

Thanks to your great help, @Sebastian-Roth and @george1421, it has come out that the error was actually in our bootfile pxelinux, which was only linked to undionly.kpxe. On the FOG 1.4.4 I have also linked to undionly.kpxe and now everything works fine. The first image is also captured. Great! And again, thanks for your competent, helpful and friendly support.

I could not understand it - because of the existing and functioning FOG servers, which were set up by someone else - why the pxelinux.0 should no longer work, since it was evidently so arranged. But you professionals immediately realized that it would have to be a link. It was like this.

@george1421 The shaming is ok for me. We have several IP-Ranges (some important) and I just mask any of them just because of habit.

YES, they are on the same subnet.