Lenovo 7303

[Wayne Workman]

@Sebastian-Roth
On r6717, with a debug task, the system ends up with just a blinking cursor and is unresponsive.

It does the exact same thing but just slightly different behaviour.

adding dns 10.51.1.6
adding dns 10.51.1.1
ssh-kegen: generating new host keys: blah blah
starting sshd: OK

Then immediately after that last line, “starting sshd: OK”, the entire screen goes black with just a blinking cursor.

This has been tried on two Lenovo 7303 computers with the same results.

[Wayne Workman]

on r7001 with debug mode, the little help page is displayed with available commands

[Tom Elliott]

@Wayne-Workman So it’s working now?

[Wayne Workman]

@Tom-Elliott oh wow. no lol. I could have sworn I typed much, much more lol.

I’m told when the fog command is given, the screen turns to a blinking cursor, probably much like what’s been previously described.

[Wayne Workman]

Here is the variable dump before the fog command is given.

I don’t see anything particularly wrong with it, other than the image format being missing.

[Tom Elliott]

@Wayne-Workman imgFormat is not needed. If it is set, it will use partimage. If it is not set, it will use partclone.

[Sebastian Roth]

@Wayne-Workman Please let your colleges run bash -x /bin/fog instead of just fog and see what you get…

[LPetelik]

Working with Wayne Workman: In a debug session the file /usr/share/fog/lib/funcs.sh line #31 (wget call that fails) causes the blinking cursor.

We’ve tried eliminating the options but it still fails but the url does work in a browser.

[LPetelik]

Also, having it set as a debug session does not alway give a prompt. Sometimes, it’s just a blank screen with a flashing cursor.

[Sebastian Roth]

@LPetelik Maybe try adding -v (verbose) option for wget??

[Sebastian Roth]

@LPetelik said:

Also, having it set as a debug session does not alway give a prompt. Sometimes, it’s just a blank screen with a flashing cursor.

Thanks for pointing that out as well. To me this sounds a bit like a “random error”. Maybe a hardware issue? As you see this on two different laptops it might be a kernel panic?!? Just an idea. Can you please get us the full output of dmesg - plug in a VFAT/FAT32 formated USB key and then:

# dmesg | tail
...
[1571962.482081] sd 24:0:0:0: Attached scsi generic sg1 type 0
[1571962.482902] sd 24:0:0:0: [sdb] 1992704 512-byte logical blocks: (1.02 GB/973 MiB)
...
[1571962.488602]  sdb: sdb1
[1571962.491966] sd 24:0:0:0: [sdb] Attached SCSI removable disk
...
# mkdir -p /media
# mount /dev/sdb1 /media
# dmesg > /media/dmesg.txt
# umount /dev/sdb1

Please upload to the forum!

[Wayne Workman]

@Sebastian-Roth said:

@LPetelik Maybe try adding -v (verbose) option for wget??

I’ll try as soon as it boots into debug again.

Doing a download deploy and using the check box for debug seems to create a regular deploy task. Going into the advanced tasks and choosing debug deploy schedules correctly in task management but it doesn’t go into debug every time.

[Sebastian Roth]

@Wayne-Workman said:

Doing a download deploy and using the check box for debug seems to create a regular deploy task.

Is this only happening for those hosts or every one of your hosts?? I usually do debug deploy with the checkbox but haven’t tried with r7001 yet I have to admit…

[LPetelik]

It can’t wget the version number on the main server which is on a different subnet. We changed the Web Server setting to the nodes IP and it was successful. This affects the background image for the boot menu also. It’s ARP related. It seems to only effect the older models (7303 and 6073).

[LPetelik]

@Sebastian-Roth We only tried this on two 7303s and a 6073. It failed on both models.

[Wayne Workman]

@Sebastian-Roth said:

@Wayne-Workman said:

Doing a download deploy and using the check box for debug seems to create a regular deploy task.

Is this only happening for those hosts or every one of your hosts?? I usually do debug deploy with the checkbox but haven’t tried with r7001 yet I have to admit…

It was happening with every 7303 we tried, which means it’s not host specific. Something to do with the web interface. I can’t say I paid attention with other models.

[Wayne Workman]

I guess this is solved since we found a work around.

The work-around is changing the FOG_WEB_HOST setting to the local node temporarily.

Web Interface -> FOG Configuration -> FOG Settings -> Web Server -> FOG_WEB_HOST

[Sebastian Roth]

@LPetelik said:

It’s ARP related

Nice find! Packet dump would be very interesting. Why would the 7303s and a 6073 not be able to send HTTP requests (actually connect via TCP) to a host in a different subnet? Possibly firewall/access list issue?

[Wayne Workman]

@Sebastian-Roth The issue has been there for a month at minimum. Here is the exact same issue, but it’s causing another problem in this thread: https://forums.fogproject.org/topic/6754/pxe-e11-arp-timeout

But in this particular situation, only older computers are affected…

In that older thread, I could not replicate the issue from my location. I’m going to try to find/borrow a Lenovo 7303 and see if I can network boot it from my building and see if it has issues or not.

I’m convinced this is a network issue.

[Sebastian Roth]

@Wayne-Workman said:

I’m convinced this is a network issue.

+1 from me!