Lenovo ThinkCentre M70a

[dmaret]

@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.

[Sebastian Roth]

@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?

[dmaret]

@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.

[Sebastian Roth]

@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.

[dmaret]

@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.

[george1421]

@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?

[dmaret]

@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.

[george1421]

@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?

[dmaret]

@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=sharing

The 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.efi

However 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.

[george1421]

@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.

[Sebastian Roth]

@dmaret Will compile a few more kernels for you to test soon.

[Sebastian Roth]

@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.64

Please give those a try and let us know how well those work.

[dmaret]

@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.

[Sebastian Roth]

@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.64

Can’t promise you that we’ll actually find the root cause of the issue. But it’s still worth a try.

[dmaret]

@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.

[Sebastian Roth]

@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.

[dmaret]

@sebastian-roth Hi Sebastian,

Yes, we can try!

Thanks

David.

[Sebastian Roth]

@dmaret I have done some more reading on topics that show the same error messages (1, 2) and the more I read the more I can imagine the messages from the Realtek driver not to be the cause of the problem but maybe just one of the symptoms of a kernel issue (even a soft crash) just before that.

Do you have more than one of these Lenovo ThinkCentre M70a? Have you tried deploying to different ones? Do all show the same issue? Just trying to rule out this is not a hardware issue on one of the machines.

I am not too sure how to take this further. We don’t see other error messages on screen. Does the partclone screen seem to freeze completely after the error messages come up?

Maybe you can schedule a debug deploy task, boot up the machine, set a root password (command passwd), check the IP address (ip a s) and connect to it via SSH. Now you have two command shells to go ahead. Start the deployment (command fog) on the machine directly and step through it. Meanwhile also issue a command on the SSH shell just to see it’s still up and running. Especially when the blue partclone screen starts you want to stick around in the SSH shell to see if that freezes at some point - e.g. just type random characters to see if they appear on screen or stop at some point.

If partclone stops but your SSH shell still works, then run dmesg | tail -20, take a picture and post that here.