Lenovo T14 Gen 2
-
I’m having trouble ssh’ing into this thing.
I even put them on their own little network, and I can ping from the Linux session to my Windows device, but I can’t ping the PC we’re troubleshooting.The bash shell doesn’t recognize “iptables” or “systemctl”
It feels like we’re now troubleshooting something else, so I apologize. But I’m not able to do the steps you outlined.
(Incidentally, I can ping and SSH to the FOG server from the same Windows PC.)I’m not sure if this is just the same network driver issue we’re facing in general. Any thoughts?
-
@mmarquis Well that’s interesting. I suggest you schedule a debug deploy task for another host which doesn’t have the network problems to make sure all the steps outlined really work in your setup. We have done this with many other people over the years and it usually works.
The system booting up to so the actual work is a lightweight custom Linux OS based on buildroot.org. We call it FOS. No iptables tools and no rules set. It’s still based on old school init.d scripts instead of systemd. To check if SSHd is running:
ps ax | grep sshDo you see a proper IP address being assinged in the
ip a soutput? On the one hand I could imagine the network issue to be a problem but then I think a task would fail way earlier in the process if network is completely down because at the beginning of a task it checks into the FOG server and errors out on failure. Why would that work but not SSH? Possible but kind of unlikely.Edit: Now that I read your post again and think about it I wonder if it’s just inbound traffic that is problematic on the Lenovo. But still, response packets from the task checkin obviously make it through. Can’t imagine that inbound TCP SYN packets are dropped because of a driver issue.
The other option you have to get the dmesg outputs over is using a USB thumb drive (best format with FAT32). Plug that in, use
lsblkto find it’s device name, mount and copy over the text files. In this case you only have one command shell in the device itself. So take the first dmesg output and copy to USB drive before starting the task (commandfog). Step through the task and when you have enough of waiting in a slow partclone screen you should be able to cancel that with ctrl-c to get back to the shell and grab another dmesg output. -
dmesg_bootup.txt
dmesg_deploy1.txtCan’t say I know what I’m looking at, but I hope you find something cool in there.
Thank you!
-
@mmarquis said in Lenovo T14 Gen 2:
Can’t say I know what I’m looking at, but I hope you find something cool in there.
Unfortunately not. It’s an Intel network chip using the Linux e1000e driver from what we see in the outputs. I was hoping to find some messages that point to network driver issues but there is nothing in the dmesg output. Looks all clean.
Did you try my suggestion on using a dumb mini switch to connect the Lenovo T14 Gen 2 to your normal network switch?
-
@sebastian-roth
Hi Sebastian,Today I put the PC and FOG server on an even dumber switch than they were already on. (Just kidding, but this one is a 5 port un-managed Netgear switch we all know so well.)
Same behavior on the dumber switch unfortunately.
I’m about to send out my last one, the one I’ve been testing with. I don’t know if we’ll ever get this model again, lol. I really hope the next time I image with FOG it goes back to normal. I’ll have new machines in next week, so I suppose we’ll see what happens.
I appreciate the help, at this point it’s just the mystery of the thing for me. Let me know if you have any other thoughts or ideas.
-
@mmarquis Well too bad we can’t fix this easily. As a next step I would grab a Linux Live boot ISO with a recent Linux kernel and see if networking is slow there as well. Maybe use Arch, burn a CD/DVD or write the ISO to a USB key drive and boot it up. When it’s up check if you have an IP and can ping the FOG server. Then mount the FOG NFS share and copy one of the image files over:
mkdir /images mount -t nfs -o nolock,proto=tcp,rsize=32768,intr,noatime 192.168.x.y:/images /imagesTo get some stats when copying you can use different tools but I am not sure if those are part of the Arch Live ISO. See which one is working for you:
pv /images/IMAGENAME/d1p3.img > /tmp/test.img rsync --progress /images/IMAGENAME/d1p3.img /tmp dd if=/images/IMAGENAME/d1p3.img of=/tmp/test.img status=progress -
Not Hijacking this post, but just wanted to “upvote” this and say I am having the same exact problem with the same exact model , Lenovo T14 Gen 2. I narrowed it down to what you guys have found so far before finding this post (that the nic driver in the kernel is most likely the issue). Using a lan adapter as a workaround, but if I find anything I more I will let you guys know.
Dustin
-
@dustindizzle11 Nice! Let us know what you find.
We have new FOS Linux kernel version released since then. Though it’s only just minor update you might give it a try. Also try out older kernels (e.g. 4.x) just in case.
Also you might test Live Linux ISOs with different kernel versions. If you find a more recent kernel (newer than 5.10.53) is fixed, then let us know.
-
@mmarquis
I had the same problem with these Gen 2 laptopsProblem:
It seems like these laptops are coming with bad driver for Wired Intel I219-V Ethernet adapter
Wireless, USB to LAN or USB-C works fine for meSolution:
- First Update BIOS on freshly out of the box laptop and then deploy your image as usual (using Ethernet LAN)
- Use USB-C or USB-to-LAN adapter to deploy your image and update BIOS afterwards
I have tested them on couple of laptops and after BIOS are updated then Ethernet LAN will work fine and you can deploy your image again using Ethernet LAN
-
Thank you guys both for the heads up!
Just got more of these models in stock.
Didn’t think about it until the imaging hung. (I have not updated FOG kernel…)Using USB-C LAN adapters and those are helping to get the job done.
I may try updating the FOG kernel, in which case I’ll post here about results.
-Maurice