Lenovo ThinkCentre M70a
-
@george1421 Hi,
This Lenovo is brand new.
M70a Desktop (ThinkCentre) - Type 11CK
Machine Type Model: 11CKS03900For now, I will try testing my way up the different kernel versions and see what is the most recent kernel version that works with this model and hard code that one into the host definition as you suggest.
Thank you again so much for your help.
David.
-
@sebastian-roth We can surely try it. But I would think the nic wouldn’t work if it needed the firmware. BUT that may be the nic firmware that is missing/needs to be patched. I guess what I’m saying is we should try it to see if it fixes the problem with the current kernel. We know now rolling back to 4.15 also fixes it, but that is not a good long term strategy.
-
@dmaret Please give this kernel a try: https://fogproject.org/kernels/bzImage-5.10.19-rtl8168fp-3 (not saying it does help but will be interesting to see if adding the firmware blob makes a difference)
-
@sebastian-roth Hi,
I have tried but it does not resolve the issue.
So since I successfully imaged with 4.15.2, I have also tested the following successfully: 4.16.6, 4.17.0, 4.18.3.
And I will continue to try to identify the most recent version which works with this Lenovo model.
Thanks again.
David.
-
@dmaret said in Lenovo ThinkCentre M70a:
So since I successfully imaged with 4.15.2, I have also tested the following successfully: 4.16.6, 4.17.0, 4.18.3.
Wow, didn’t expect that! Good to know. Are they all going full speed or kind of slow as you said with 4.15.2?
-
@sebastian-roth I think 4.16.6 was also slow, but the following were back to usual rate. 4.19.1 and 4.19.6 do not seem to work.
David.
-
@dmaret Do I get this right, 4.18.3 (and maybe 4.17.0) is the best candidate we have so far. Error not happening and normal speed?!
Did you test 4.18.11 yet? The closer we get the more chance we find what change in the kernel is causing this and we might be able to provide a patched up to date kernel.
-
@sebastian-roth Hi Sebastian,
Let me recap my findings:
- 4.15.2: working, slow
- 4.16.6: working, slow
- 4.17.0: working, normal speed
- 4.18.3: working, normal speed
- 4.18.11: working, normal speed
- 4.19.1: not working
- 4.19.6: not working
- 4.19.36: not working
NB: I am using realtek.pxe
Thanks.
David.
-
@dmaret said in Lenovo ThinkCentre M70a:
NB: I am using realtek.pxe
So this computer is in BIOS mode? Does undionly.kpxe work for the boot loader or will only the realtek.pxe get this system to the iPXE menu?
-
@george1421 Hi George,
This computer does not offer Legacy BIOS, only UEFI. It does not work with undionly.kpxe
There was a typo in my previous message, I actually use realtek.efi not realtek.pxe
Thank you.
David.
-
@dmaret said in Lenovo ThinkCentre M70a:
I actually use realtek.efi not realtek.pxe
So then let me ask the question with this new info. Does ipxe.efi work as well as the hardware specific realtek.efi?
-
@george1421 Hi George,
Yes it works with ipxe.efi but with a message which I do not have with realtek.efi, see screenshot:
https://drive.google.com/file/d/1eupCfc1Z5FROhi45pLlSWJsOk-AdtHt_/view?usp=sharingThe 2nd line on the screenshot starting with r8169 does not appear with realtek.efi
It is why I thought it was better to use realtek.efiHowever it does not change anything when it comes to the kernel versions: same results as with realtek.efi, i.e. working up to 4.18.11, and not working after that.
NB: the first line with the error message starting with “db_root: cannot open: /etc/target” appears with both realtek.efi and ipxe.efi
Thanks
David.
-
@dmaret said in Lenovo ThinkCentre M70a:
The 2nd line on the screenshot starting with r8169 does not appear with realtek.efi
Interesting, because the error message in the picture comes from FOS Linux and not iPXE. As soon as FOS Linux start, iPXE is moved out of memory. This tells us that FOS Linux is not configuring the network adapter right where iPXE configures something in the network adapter and leaves it behind for FOS Linux to use, where in version 4.19 the kernel reset the network adapter cleanly but doesn’t init it correctly. At least that is what I think I see.
-
@dmaret Will compile a few more kernels for you to test soon.
-
@dmaret Just build and uploaded some more 4.18.x versions:
https://fogproject.org/kernels/Kernel.TomElliott.4.18.12.64
https://fogproject.org/kernels/Kernel.TomElliott.4.18.15.64
https://fogproject.org/kernels/Kernel.TomElliott.4.18.20.64Please give those a try and let us know how well those work.
-
@sebastian-roth Hi Sebastian,
I tried all three. I did not see any difference, no better no worse, imaging works, normal speed, except for the last one (4.18.20.64) which was slow.
Thank you.
David.
-
@dmaret said in Lenovo ThinkCentre M70a:
I tried all three. I did not see any difference, no better no worse, imaging works, normal speed, except for the last one (4.18.20.64) which was slow.
Hmm, interesting. I did not expect the slowness to come back in a later version. Mainly because a kernel usually stabilizes over the lifetime of one version branch. Would you mind re-testing with 4.18.20.64 again? Any chance the slowness comes from other network traffic?
There are more for you to test. I would expect the 4.19 kernel to show the initially reported issue but let’s see.
https://fogproject.org/kernels/Kernel.TomElliott.4.18.17.64
https://fogproject.org/kernels/Kernel.TomElliott.4.18.19.64
https://fogproject.org/kernels/Kernel.TomElliott.4.19.64Can’t promise you that we’ll actually find the root cause of the issue. But it’s still worth a try.
-
@sebastian-roth Hi Sebastian,
I tried 4.18.20.64 again, and I got normal speed this time.
4.18.17.64 and 4.18.19.64 worked just fine as well (normal speed).
4.19.64 did not work as you expected.
Thanks again!
David.
-
@dmaret So the issue starts with kernel version 4.19. I had a first look at the changes between 4.18.20 and 4.19 but it’s hell of a lot of code changes even when just looking at the Realtek driver alone.
Are you keen to go ahead and test 4.19 release candidate versions (those between 4.18.20 and 4.19)? I have to say that it’s very hard to say if we will find the exact code change between kernel major versions that is causing the initial error. When we first started this I was still hoping a change in the 4.18.x series might be it. That would be more easy to nail down because of less changes in between.
-
