Lenovo L13 yoga 'Maybe the usb cable is bad' error when trying to register
Just got a couple of these laptops.
I’m using Fog Version 220.127.116.11
Kernel version 5.6.18
I got into the fog pxe menu using a lenovo usb-c adapter.
I had the lenovo’s bios set to use mac-address pass through using the second address.
I hit the full host registration and inventory button.
It then repeatedly gave me this error
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
It attempted to bring the network up but failed eventually.
I have used this usb-c adapter for imaging in the past (it’s been a while, maybe even a year, but it did work before).
I was able to get it to image using a different lenovo adapter (there’s a proprietary one that connects to a special port, basically making it act as a normal ethernet port). So this problem only occurred using the lenovo usb-c adapter.
It’s weird that it got to the pxe menu without issue, but I saw another post from February for this model where there were issues too. I’m hoping the fixes from Feb are already built into the current kernel so I haven’t tried that one.
I have one more of these to image today, so if there’s something to test for it I’d be happy to give it a go.
@sebastian-roth Well yes I see that now. It just felt like a familiar problem from whenever I change kernels. Should have just restarted and tried again before assuming something was broken though.
Although you seem to have this solved through a firmware update I might add that this is not cause by the kernel itself but by iPXE downloading the kernel binary from the FOG server. So messing with the kernel binary doesn’t make any difference at this stage.
@jj-fullmer This appears more of it stalling out on the transfer of bzImage to the target computer than the kernel booting. At this points is still in iPXE realm because the kernel hasn’t started (what is inside bzImage) because the entire file hasn’t made it to the target computer yet.
@george1421 Well, perhaps it was a one time glitch or updating the bios solves the issue.
After surfaces image I have them install the latest driver pack that includes a bios update. After that happened and I tried to re-create the problem, the problem didn’t happen. I can share the video with all the log output if you still want it.
@george1421 I will got my log level to 7 and scheduled it to do an inventory task, I’ll take a video and we’ll see if it does it again on this 5.10.12 kernel
@george1421 well it got to
I actually had it sitting for a couple of hours. I just manually added the host in the gui and got it started imaging with the kernel you made here.
I’ll put it back to the default kernel and see what I can do.
it does not load up on a surface
Would you mind, when you have time create a video of how far its gets. I do have an older surface pro at home (circa 2015) that I could test on too. But I’d like to see at what point it freezes. Also if you change your fog configuration fog settings log level to 7 it will give us a bit more details on the FOS linux kernel startup.
Just as an fyi related to this post. I just updated to the latest kernel from Tom (5.10.12 64bit) and it does not load up on a surface. Trying to get it just to go to the full inventory screen from the pxe menu it gets to 1% after about 15 minutes and just sits there. The kernel has been fine for all other machines just the surfaces have an issue (thus far in my testing anyway). Perhaps we can add whatever George did to the default kernel build to make sure surface’s stay supported?
@jj-fullmer As long as you have that
bzImage5618RT3kernel queued up could you test what we are talking about in this thread: https://forums.fogproject.org/post/140103 I may have inadvertently fixed the requreiment to switch the computers from Raid-on mode to ahci to image with FOG. I know this might be a Dell specific setting, but its related to the Intel RST disk controller in raid mode. I think the lenovo systems should also have a similar setting because its an INTEL thing not a computer manufacturer thing.
Edit: Ignore this request, the 5510 I have has a sata disk in it. I just tested the kernel with a 7280 with an NVMe disk and the linux kernel does not work with this disk structure. So we are still no where in regards to a solution to this.
@jj-fullmer Great I’ll take bonus points whenever I can get them.
The keyboard thing has me a bit confused because that is native to the linux kernel. I made no adjustments in that area between 5.6.18 and 5.9.3 so it must be a “feature” of the linux kernel.
@george1421 I was also now able to use this lenovo usb-c adapter to pxe boot other non-lenovo devices I previously wasn’t able to.
So bonus points for that.
This is on the 5.6 rt3 kernel
@george1421 The weird keyboard issue still occurs in the debug session where I can’t do shift+page up/down scrolling. But the adapter is working to be imaged otherwise. So it does work for imaging, just may be getting the wrong keyboard layout on this lenovo l390 yoga keyboard. Not sure it’s worth diggging into.
@george1421 Well I’m doing it anyway, especially after it was so weird with the keyboard the first time, I figure it’s worth testing. I’m doing a debug test on one of these models with that usb-c adapter now
@jj-fullmer No worries on testing 5.9.3 since you have a working path forward. With 5.9.3 that is just a stop gap kernel until 5.10.x LTS branch is released and tested.
@george1421 Things got crazy last week, but I have 2 of these I intend to image by Wednesday, so I should have some tests results for this before I’m away for the holiday.
@george1421 I need to get this machine into production so I can’t test this right now. But I can image one of the other’s we have tomorrow and see if this kernel does the trick.
@jj-fullmer I just updated the 5.9.3 with the updated realtek driver. https://drive.google.com/file/d/1O-4tvx4DywWef75qfSxLRK9M6CoDS9pd/view?usp=sharing
For documentation purposes, for 5.9.3 the 8152/8153 driver version in the mainstream kernel is 1.11.11 and the updated (patched) driver I’ve been installing from realtek is 2.13.0 dated April 2020
Did you change anything else other than this driver and firmware for this kernel? Would it be safe to try using this one as default for all hosts? Or is there something else in there that might cause pause?
No that is the base image with the updated firmware for the realtek nics plus the updated realtek driver. Its possible that the 5.9.3 doesn’t have the patched realtek driver. I was working with 5.9.3 specifically for the realtek 8125 nic.
Yes it is safe to use bzImage5618RT3 kernel for everyday imaging.