rcu_sched Error on Host Registration - PC Tablet w/ Dock
-
Hi all, I was thrown a bit of a curveball today when I was told we’re going to be supporting some third party Windows Tablets and will need to be able to image these things. I’m getting the “rcu_sched” error when attempting to register the device as a host which I did do some research on here on the forums and as far as I can tell this is an issue with the type of hardware and normally it seems like downgrading the Kernel to a prior version can help? The last post I found on the subject that mentioned this fix was from February so I’m not sure if that info is still valid or not, or if the recommended kernel version to get around this (1.5.2) has changed since then.
I’m not sure if this is due to the fact that the only way to PXE boot into these things is by plugging these into a dock with an ethernet port which is obscuring the hardware type or what the issue is-- I was told by the manufacturers that they image these using MS DISM tools and that “any imaging software that can support UEFI x64 should work”. If this is still a matter of changing the Kernel to a previous version I can do that, I just wanted to check beforehand to see if that changed since there’s been a few revisions between now and the most recent previous post about this.
-
Would you provide us a clear screen shot of the error message?
It would be also helpful to know what version of FOG you are using. -
Yes, I apologize. I’m currently on FOG v1.5.6, screenshot of the exact error is below. When left running this fills up the screen with varying numbers
-
@explosivo98 Ok, I want you to download and test a back dated kernel of 4.15.2 you can get it from here: https://fogproject.org/kernels/
Download the file Kernel.TomElliott.4.15.2.64 and save it as bzImage_4152
Move that renamed image to the fog server in
/var/www/html/fog/service/ipxedirectory.Now manually register that specific target computer in FOG. On the host management page update/set the Host Kernel field to
bzImage_4152.Next pxe boot the target computer and pick compatibility testing (or whatever its called). The goal is to see if you can boot info FOS Linux using the 4.15.2 version of the linux kernel.
-
@george1421 Will do, may take me a bit today but I’ll reply once I’m able to test this out.
-
@explosivo98 Just to be clear I’m not suggesting this is a forever fix, only for the systems that have issues with the current kernel. The latest kernels will support newer hardware. So for the new stuff you need to stay current
-
@george1421 I finally had some time to test this out today and was able to successfully manually assign the new kernel to that device, but when booting into the compatibility mode option the screen goes black and nothing shows up. There’s no flashing cursor or anything, just a black screen.
-
@explosivo98 OK lets take a different approach.
Do you know if those are 32 bit or 64 bit tablets?
Do you know if you can usb boot them in either bios or uefi mode? -
@george1421 They are 64 bit devices (Atom x7-Z8750). We’ve supported some betas on these tablets before and we were able to boot to Clonezilla on USB to image them individually in the past.
-
@explosivo98 Ok lets see if we can get these usb booted into FOS Linux. This is not the best approach, but it does work if pxe booting route is not working.
The tutorial is here: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image read through it in its entirety. Be sure to watch out for the caveats. Also look at the FOG Forum chat bubble for a few additional hints to get it to run.
-
@george1421 Hmm, if I can get this working that’d be an okay workaround provided they still can select the image being deployed without having to be registered first. I made a boot USB using the .img file you provided but when trying to go back into the compatibility menu I get a “db_root:cannot open: /etc/target” message, followed by the same cascading “rcu_sched” errors if left alone long enough.
-
@explosivo98 said in rcu_sched Error on Host Registration - PC Tablet w/ Dock:
I get a “db_root:cannot open: /etc/target” message,
This is just an unrelated symptom of older version init/kernel files. Don’t worry about that.
-
@Sebastian-Roth ah okay, unfortunately after seeing that message it goes back to the same repeated error. I did attempt to run the debug kernel option in the FOS menu and it looked like it was about to do something but then started showing the rcu_sched error again with more bits of information in between, however there was a bit more info attached to this one regarding the system
-
@explosivo98 While it appears you are still no where, it does tell us a few things in that your issue doesn’t appear to be an issue with PXE booting, because usb booting gave you the same error. I seem to recall us having this rcu_sched error before. I though downgrading the FOS Linux kernel solved the problem OR it was adding a kernel parameter. I’m going to see if I can find the solution we solved before. I can’t remember if it was a apci kernel parameter or something else at the moment.
-
@explosivo98 Just to be clear, you have more than one of these tablets and each of the tables are seeing the rcu stall? Because it could be bad memory too, just saying.
-
@george1421 Yeah I have a couple here and they all seem to be doing the same thing. I did find this post from a while ago about some new kernel inits that were manually created to resolve this in the past, but the links don’t seem to work anymore. Not sure if this is what you were referring to or not but in my time scrubbing the forums for the solution I did notice it but couldn’t proceed:
https://forums.fogproject.org/post/121137 -
@explosivo98 If you manually register this system with the FOG ui. In the host definition for this suspect system. In the kernel args, place the following kernel parameter
clocksource=hpetThen pxe boot that target computer again. This will change how the CPUs are metered for stall detection. -
@george1421 okay, and to be sure this goes under “Host Kernel Arguments”, correct?
-
@explosivo98 Yes, I stated the name from memory. I was close but not exact.
-
@george1421 haha I got you. I went ahead and added that argument but no change
