Lenovo M700 won't Inventory or image
-
Folks - we just got a couple of Lenovo’s cute little M700 mini pc’s to play with and I cannot inventory them at the PC and when I create a record for them they won’t image. The ghost menu does show up. When I run the client system compatibility test it says that the hard drive is fine but the network is not. What do I need to do?
Thanks -
Library Mark
-
Lets get a little more info here
What version of fog are you using 1.2.0 stable or a trunk release (i.e. pre 1.3.0)?
Is this device in efi or bios mode? (I’m going to guess bios)
What version of the FOG (Fog OS) kernels are you using?
I can’t find a reference for a lenovo B700 on their web site, what is the real part number? -
@george1421 said:
Lets get a little more info here
What version of fog are you using 1.2.0 stable or a trunk release (i.e. pre 1.3.0)?
Is this device in efi or bios mode? (I’m going to guess bios)
What version of the FOG (Fog OS) kernels are you using?
I can’t find a reference for a lenovo B700 on their web site, what is the real part number?I tried fog 1.2.0, but I also tried 0.32 as I have both versions running on two separate networks. The behavior is the same on both. The kernel I just updated today. I used this one:
Kernel - 3.19.3 TomElliottUSB
Date : July 22, 2015
Version : 3.19.3
FOG Type: TomElliottUSB
Arch Type: (x86_64) -
According to google that motherboard has an Intel I219-LM network adapter on board.
You will need newer kernels than 3.19 to make that one work.
Any reason why you can’t upgrade that 1.2.0 install to the trunk release (i.e. 1.3.0 beta)? That release has the latest kernels including that intel driver.
-
Moved to Hardware Compatibility… and changed title so that people may find this.
George is absolutely right. Upgrading to the latest FOG trunk will most probably get your M700 to register/image. I’d highly recommend that you upgrade.
-
So I tried to upgrade to the beta, but it says this at the end then quits:
* Downloading inits, kernels, and the fog client..............OK * Comparing checksums of kernels and inits....................Failed init.xz * Attempting to redownload init.xz............................Failed!Am I doing something wrong? Or is there another issue here? I am using Ubuntu 14.04, and used git to pull down the upgrade. Also, there were a few PHP packages that failed to install, even though they installed manually just fine. They were php5-mcrypt, php5-mysqlnd, and php5-fpm. Plus, these two lines were in the list of package installs:
* Skipping package: php5-mbstring.............................(Does not exist) ... * Skipping package: php5-gettext..............................(Does not exist) -
@LibraryMark the packages likely failed because the Remi RPM failed to install. If you can install this manually, the packages will likely succeed. The issues with downloading the inits and kernels and client is most likely connection related. It could fail one minute, and then succeed the next when the path between you and the FOGProject is unstable or unreliable.
-
@george1421 said:
According to google that motherboard has an Intel I219-LM network adapter on board.
You will need newer kernels than 3.19 to make that one work.
Any reason why you can’t upgrade that 1.2.0 install to the trunk release (i.e. 1.3.0 beta)? That release has the latest kernels including that intel driver.
The trunk version did the trick. But - I had to restart the install at least six times until it actually downloaded everything.
I was able to pull an image off of the M700 this morning with no trouble. I really like the new web page and the PXE menu. It all looks newer and more professional now, although the new icons on the webpage threw me for a quick loop. Nice work, guys! Many thanks! But I am curious about one thing - how is it the NIC driver in the PXE boot works just fine, but the kernel that does the imaging does not? I would think they are one in the same, but obviously, I am wrong.
Thanks again!
-
@LibraryMark said:
The trunk version did the trick. But - I had to restart the install at least six times until it actually downloaded everything.
This concerns me a bit. Why did you have to download 6 times. Was there any error messages thrown or did it just stop working.
FWIW: The FOG PXE booting uses another FOSS project code call iPXE, which is not owned by the FOG Project. FOG uses its own custom linux boot kernels with its own drivers. iPXE uses its own kernels and its own drivers. They have similar origins but are different.
-
@george1421
See the error messages below. Someone said that they thought it was our internet connection. We have 50mbit fiber to the largest public institution ISP in Michigan. One thing that I was wishing for was a little more feedback during the install process. I had no idea why it was failing or where. -
@LibraryMark said:
The trunk version did the trick. But - I had to restart the install at least six times until it actually downloaded everything.
OK the context of this is not between the FOG server and the target computer (which is what I understood), but the FOG server, installer script, and the online repositories. (I didn’t look deep enough in the thread for the download fails)
-
@LibraryMark said:
The trunk version did the trick.
You were already on trunk. It was just a download issue. We too used to have a 1Gbps fiber connection to a major university provider. We moved away from it because it was too expensive, we now have a 1.5Gbps fiber link to a local ISP and it’s about 10x cheaper than the university provider as well as better quality.
The big and old uni providers often come under major dDOS attack.
-
@Wayne-Workman
With USF funding, our fiber connection is actually quite cheap. -
@LibraryMark Are you still not able to run the script (download error)? Please check if you can download files from the internet using
wgeton your FOG server! -
@george1421 I’m trying out 2 new Lenovo’s the Thinkpad T560 and the Yoga 260. They both use the Intel i219-LM for ethernet. I’m trying a fresh trunk build of fog. and i’ve tried 4.0, 4.1. and a fresh built 4.3 kernel. All behave the same way. They boot but they don’t get an IP, just trying in debug mode right now. If you run /etc/init.d/S40Network after it’s booted it will then give you an IP. I tried both BIOS and EFI didn’t make a difference.
-
@Brian-Hoehn While in debug mode please run
lspci -nn | grep Ethernetas well asifconfig -a.When you boot the client please pay attention to what the NIC LED does. Goes on? When? Goes off again? When? Back on? Or stays off?
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
Let me restate what you have told me to ensure I have it right.
When you boot your thinkpad, it will pick up a dhcp address in ipxe mode, but once the FOS (Fog Operating System) boots it doesn’t pick up an IP address. But you can boot in debug mode and then issue the start network command and it WILL pick up an IP address.
If I understand that correctly it sounds like a network switch spanning tree issue. With spanning tree each time the network link is dropped (as transitioning between ipxe and FOS, i.e. watch the link lights) it takes spanning tree several seconds (about 27) to switch from learning mode to forwarding mode. That might explain why during boot time you don’t get an ip address (because FOS is very fast) but after you get to the command prompt and start the network it works.
Can you ensure that the network port where these test devices are connected, are either configured for port fast, Fast STP, or RSTP (depending on what your switch manufacturer calls it).
Also you didn’t mention what version of FOG you are running [edit] Oops rereading your post you are on a current trunk build. That is good so the developers can help with this issue[/edit]. I know the current trunk build has taken steps in the inits to try to get around this slow STP forwarding issue.
-
@Sebastian-Roth said:
@Brian-Hoehn While in debug mode please run
lspci -nn | grep Ethernetas well asifconfig -a.Please post pictures or images of the output of these commands too. Pictures speak louder than words here. And Brian, you should start your own thread. I think these devices should warrant their own debugging.
-
@george1421 @Sebastian-Roth I have spanning tree portfast turned on , Also tried plugging directly into the server. Also the lights turn back on when it give me the error. So it’s hard to tell if the port is up or not when it’s trying. Still tells me
“Starting eth0 interface
/etc/init.d/S40network: line 56: Failed to get an IP!, Tried on interfaces(s): eth0 : command not found
Please check you network setup and try again!”lspci give me
“00:1f.6 Ethernet controller [0200]: Intel Corporation Ehternet Connection I219-LM [8086:156f] (rev 21)”ifconfig give me
"
eth0 Link encap:Ethernet HWAddr xx:xx:xx:xx:xx
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:659 (rest is 0)
TX packets:1 (rest is 0)
collisioins:0 txqueuelen:1"
RX and TX is 0
Interrupt: 16 Memory:f1200000-F1220000 -
@Brian-Hoehn As George already suggested I too ask you to start a new posting about your issue. Those kind network issues seam to be very specific to switch models / settings, ethernet cables and such things. Please open a new topic and I am sure we can help you out with that. It’s a lot easier if we don’t have two people talking about different setups in the same thread… Please post all the details from here in your new thread!!
The error you see in S40network is already fixed! Please upgrade to the latest version and you should not see that again. As well I think we improved the script since then! Maybe it’s working for you now?!
Good to know that we are talking about a NIC with PCI ID 8086:156f. As you see here this NIC is supported since kernel version 4.1! But there are newer revisions that are supported from 4.5 on. That’s why I asked you to run the lspci command.
Please see if your switch has energy saving capabilites (called EEE or 802.3az). We have seen problems with that. Try disabling this feature on the switch if you have it. Another thing we saw problems with lately is auto-negotiation. If all the other hints don’t help then try to configure that switch port to NOT auto-negotiate the link speed…
