Hi everyone

has anyone had any more luck so far? Not that we have but maybe some of you…

Good luck all

Hi,

so, we did try to revert a machine to El capitan but while the OS was no problem, the firmware didn’t downgrade on the way.
We looked for a way to force the firmware downgrade but couldn’t find any so far…

The search continues…

Salut!

I’ll continue in English so that everyone understands.

It may be dumb but can’t you just edit the default profile on your laptops (as a part of setupcomplete.cmd) as there probably is only one user on the laptop?
And then configuring the desktops through GPO?

I’m just tossing ideas here, just in case you didn’t think of that…

@sebastian-roth

HI Sebastian,

I’m not sure either about the firmware, but it would seem strange to me that it would be reverted at the same time as the OS, but as I said we’ll try just to make sure.

“Make a FOG backup of a machine that is known to have this PXE boot issue”
well, I’d certainly love to be able to do that wouldn’t I

Seriously though, the clients are in use in a another building and have quite a load of heavy applications on it, so I would have to wait for one to be inoccupied for at least two days (one for the test, one for reverting to a usable state). I’ll chack the occupation planning of these room and try to get this done as soon as it can be.

@sebastian-roth

Hi there,

we just tried resetting the PRAM on the imac, sadly it didn’t change anything.

It’s going to take some us time to try and revert to an El Capitan OS and I think it was established in the ipxe forum that it has to do with the firmware installed with Sierra (which will not be reverted if we switch back to El Capitan) so I don’t have much hope for that. I’ll still try as soon as I can though, and keep you informed.

HI!

In our case, we already tried going through an unmanageable switch when it was tought to be a spanning tree error, but I can’t remember if it was a 100mbps or a 1Gbps. I’ll give it another try with a 100Mbps ASAP just to be sure.

I’ll keep you in touch.

@sebastian-roth

Hi sorry, I couldn’t answer any sooner.
“Nevertheless we ought to try out using the SNP binary (debug enabled - DEBUG=snp:3,nii:3 to start with). So find 01_snp.efi here. Just give it a try and post pictures or video. Make sure when you take those to place the camera or phone on a stack of books in front of the screen so we have a good picture.”

Here you go, not much to say from my side but here goes: video

Thanks!

@george1421

Awesome! It works!

Thanks a lot.

I’ll have a look at dmidecode when things settle down a little thanks.

Server

• FOG Version: 1.4.3
• OS: Debian 8.8

Description

Hi everyone,
Not really sure if this is the right section but there goes:
up to a few days/week ago, we had our modified version of driverinstall.sh copy the drivers according to the model of the host as seen in the fog inventory under system product.

we used to get this info through a wget command in the script (found somewhere on this forum I think or maybe the wiki)

 wget -q -O /tmp/hinfo.sh "http://${web}service/hostinfo.php?mac=${mac}"

Now it won’t return anything…

I tried to run the command with a hard coded server and mac address

http://myfogserver.mydomain/fog/service/hostinfo.php?mac=48:4d:7e:fa:XX:XX

and the resulting hinfo.sh is an empty file. When I run this same command through a browser I get a “Cannot view from browser” message and that’s about it…

I also tried replacing the driverinstall.sh script with a backup one from two month ago to no avail so I,m almost sure it’s not someone tinkering with the script.

I’a at a loss here, I’m not sure if this is due to the last update as I don’t manage server updates here and can’t seem to remember when the las update was.

Maybe upgrading to 1.4.4 will fix this, but as I said, I don’t manage the upgrades.

Thanks and have a nice day.

Seb

Hi,

I’m going to try and clarify the test setup because I feel we don’t really understand each other here.

• We have on the same vlan which we usually use as the server vlan (172.16.0.xxx/24) :

  • an ISC dhcp server
  • a FOG server
  • The problematic iMac

• The iMac is plugged on a non manageable switch

• there is no firewall enabled on any of these

• Other hosts work just fine with fog and/or the dhcp

Now for the TCPDump request itself :

• We wait for a quieter part of the day (around 5 pm usually) so as not to be “polluted” by other dhcp requests

• we boot the iMac while pressing “alt” which gives us the choice of the boot device

• we choose to boot on the ipxe kernel

• Once on the kernell we get an error message which varies according to the efi file used (it’s either “link status: down” or “no configuration method succeeded”) and get prompted to press a key to get to the ipxe shell

• At this point we launch the tcpdump -w output.pcap port 67 or port 68 or port 69 or port 411 command on the dhcp or the fog server

• back on the iMac we launch a dhcp command from the ipxe shell

• when this dhcp command is over (and has failed) we stop the TCPDump.

At this point, once again, neither the dhcp nor the fog server receive requests. However, if we launch a ipconfig /release and /renew from a windows box, the dhcp does get requests.

I hope it makes all this more understandable. We’re trying to do what the post from the ipxe forums asked us to do as well but we’ve had some difficulties with time management so far.

Once again, thanks to all you who try to help us there.
Have a nice day.