Posts made by Seb B

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.

@george1421

I know it’s not what you’d expect, though it’s the same result as the last time I tried.
The test iMac and both the fog server and dhcp server are in the same server (normally a server dedicated vlan).
It acts as though, once the the ipxe file is downloaded and “launched”, the network interface is unable to send anything out.

As I said, I think it would be tricky to launch an unfiltered tcpdump request on the server vlan and get comprehensible results.

I’m willing to give it a try but I won’t be able to understand the results…

Thanks again for your help.

@Sebastian-Roth

Hi.

We did try a tcpdump both on the fog server and the dhcp
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 411
and got this answer on both :

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel 

It is not going to be easy to have a readable unfiltered answer as the fog server is in use with several dozens of fog clients and the dhcp server is not only a dhcp a dhcp server but has some other roles as well.

I’m sot sure I understand where you are going with the network hub thingy, could you give me more details as to what you want me to do please?

@Sebastian-Roth

sure thing. It’s this one.

As for the screenshot, here it is (it’s in french, I can switch the system in english if you need)
![alt text](

Thanks again

So I was able to launch tcpdump on the dhcp server while running a dhcp net0 command on the ipxe kernell command prompt.

There is no result which can be linked with our host (some dhcp requests but from another subnet with diferent MAC addresses).

@george1421

Hi George,

the venID:devID of the ethernet card is 14e4:1686 (there’s no lspci command on osx but I had if already written down somewhere).

I’m still waiting for the dhcp server to be available for the tcpdump but I reckon you could be right about the ipxe kernell not supporting this device yet …

@george1421

George,

I ran this command on the Fog server while running a dhcp net0 on the client and got no result

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

With a 24ko wireshark file with no visible data.
I also tried with another efi file with no difference in the tcpdump results.

I can’t try on the dhcp sever right now as it is in use for something else. I’ll give it a shot tomorrow morning.

Thanks again to both of you.

Hi,

let me sum up the tests so far, so that it’s clear for everyone (me included) :

• With the host and servers on a different vlan

  • while booting ipxe from the mac startup menu, nothing is detected by tcpdump on the fog and dhcp server
  • while on the ipxe kernel command prompt, after waiting 30 secs and launching dhcp, dhcp net0 , or dhcp net1 , nothing is detected by tcpdump either on the fog or the dhcp server

• With the host and servers on the same vlan

  • while booting ipxe from the mac startup menu, nothing is detected by tcpdump on the fog and dhcp server
  • while on the ipxe kernel command prompt, after waiting 30 secs and launching dhcp, dhcp net0 , or dhcp net1 , nothing is detected by tcpdump either on the fog or the dhcp server

We also tried with the default .efi file but didn’t get any more result in tcpdump…
It doesn’t seem it can use the NIC properly once in ipxe, we might try a tcp dump without filter except the source to see if anything is sent once the ipxe is loaded, which I doubt at this point

To address your other question, yes it is a built-in NIC in a desktop computer with no dongle whatsoever…

@george1421

Ok so we tried that and ran tcpdump on both the dhcp server and the fog server and didn’t get any result pas the bootp part where we get to choose ipxe from the mac boot menu.

The tcpdump command we ran:
tcpdump 'host 172.16.xxx.xxx and (portrange 67-69 or 4011)'

The result :

17:13:53.000214 IP 172.16.xxx.xxx.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 38:c9:86:12:xx:xx (oui Unknown), length 295
17:13:53.000463 IP Server.DOMAINNAME.bootps > 172.16.xxx.xxx.bootpc: BOOTP/DHCP, Reply, length 303
17:13:53.000569 IP Server.DOMAINNAME.bootps > 172.16.xxx.xxx.bootpc: BOOTP/DHCP, Reply, length 321
17:13:53.000643 IP Server.DOMAINNAME.bootps > 172.16.xxx.xxx.bootpc: BOOTP/DHCP, Reply, length 321

And as soon as we click on the ipxe option, nothing is received

@george1421

Actually no, the dhcp and fog server are on a dedicated server vlan while the host is on another vlan.

However, we have half a hundred stations on this configuration and never encountered any trouble so far.

We did a test where we check on the dhcp server while running dhcp net0 and get no request on the dhcp.

We tried with several efi files and never got anything showing up on the dhcp.

@george1421

Ok, I’ve done that after waiting 30 secs and still got the no configuration method succeeded message.