@george1421 very well, I’ll test as you specified and report the results later.

Hi guys, I didn’t forget about this topic. I’m just currently dealing with some iPXE booting challenges due to the big differences between system archs I have here. I’m almost finished, so I can try out these tests you asked.

So far, some answers:

@Sebastian-Roth said in Error "rcu_sched self detected stall on CPU" on legacy BIOS Capture job:

Are you saying that it does work “sometimes” without an issue. Is that on the same kernel version 4.19.6 that is causing the error initially posted?? Would make it even harder for us to nail this issue down.

As much as I wanted to answer it technically, the best I have is: yes, it’s kinda random. Our business model demands constant infrastructure changes as our clients points out their needs, so we have lots of machines that although are the same models, have slightly different CPUs and BIOS versions, a challenging scenario for applications such as FOG to be set up as an automation tool. So at each node I have to test what FOS image will be the best fit.

So far I had 4.19.6 bzImage + FOG 1.5.5 init.xz working on about 90% of my systems with no bugs, hangings or issues of other nature. For the ones I did find issues, switching it to 4.15.2 as suggested by @george1421 fixed the problems, but only when I used init.xz packed with FOG 1.5.2 binaries.

Using bzImage 4.15.2 + FOG 1.5.5 init.xz gave me kernel panic “FATAL: Kernel too old” messages on every single system I’ve tried it. It happens also with bzImage of all versions from this up to 4.19.6 with the same init.xz, which works fine to boot and start the task, but throws me the errors reported in the title of this topic at given point in image deploy/capture tasks (it’s not always the same point and I didn’t test other kinds of tasks).

@Sebastian-Roth said in Error "rcu_sched self detected stall on CPU" on legacy BIOS Capture job:

Trying to figure out what might be causing this on your hardware I started by reading the kernel docs on this. Essentially it says that this can be caused by many different things (see a detailed list in the document linked) and we might need to turn on CONFIG_RCU_TRACE in the kernel to get an idea where things go wrong. But as a start we would need to have a clear picture of the exact error messages on screen.

Ok, I’ll reproduce the error scenario and take a picture of the screen. I’m doing this right now.

@Sebastian-Roth said in Error "rcu_sched self detected stall on CPU" on legacy BIOS Capture job:

@fenix_team @george1421 @Quazz Ok, I just compiled inits that should work with kernels all the way back to 4.15.x (64 bit and 32bit). Can you guys give those a try in your environments before I make those the default?

Will test it right after the rcu_sched issue.

@george1421 yes, I understood that, I’m downloading the inits and will test it asap. What I stated was just to confirm why these issues were happening.

@george1421 @Sebastian-Roth Hello guys! I’m here to say that I had no problems loading tasks, neither capture or deploy, since I’ve updated the init files.

I’m using bzImage at latest version, did extensive tests on Legacy BIOS systems that were presenting the “rcu_sched” warnings and so far I’ve never saw them again or any other hanging issues.

If I can help with any othe kind of tests, please let me know.
Thanks everyone, awesome work!

Hello folks! My Log Viewer menu entries had vanished and I don’t know what could I have done wrong. Can someone help me as to where should I look to fix it?

@george1421 @Sebastian-Roth Hello guys! I’m here to say that I had no problems loading tasks, neither capture or deploy, since I’ve updated the init files.

I’m using bzImage at latest version, did extensive tests on Legacy BIOS systems that were presenting the “rcu_sched” warnings and so far I’ve never saw them again or any other hanging issues.

If I can help with any othe kind of tests, please let me know.
Thanks everyone, awesome work!

@ragnurenson so, I’ve just tested after applying the commited changes and everything works fine! Thank you for pointing out the github commit and thanks @Fernando-Gietz for the awesome work!

If I can make a suggestion, I’d say it would be nice to have that search filter implemented in “List All Hosts” screen on Active Tasks!

@ragnurenson Hello! Thank you for sharing this! I’ve updated the file as suggested, but unfortunately it didn’t change anything, I’m still capable of finding unwanted hosts while logged in with my limited account.

I believe the bug @Fernando-Gietz fixed was just concerning the host count that shows on Site Management page when you list All Sites. That feature was fixed after updating the file, indeed! But the listing problems are still lingering, at least for me…

I did a test putting a single host in this Site, then I’ve searched the partial name and it shows up with all the other ones, as the plugin has no effect.

This is my limited user account configs. As you can see, it’s correctly enrolled with the created Site called “SMT”.

[EDIT] - I found the commit concerning the right updates! I will test them and report later, thanks everyone!

@Fernando-Gietz hello Fernando, I don’t know if I’m doing it right… My FOG version is 1.5.5 straight out of the master branch. I’ve created a Site, included an user in Membership and a list of hosts that user has the right to find in searches. But when I log in with that user credentials, it’s still able to find hosts in and out of the Site associated hosts list!

I have the Access Control and Location plugin installed as well.

1. Host association screen (should find ONLY hosts that starts with “FENG”)
   

2. Logged in as target limited user, hosts that are not “FENG” are still displaying!
   

Any help will be largely appreciated, thanks in advance!

@george1421 yes, I understood that, I’m downloading the inits and will test it asap. What I stated was just to confirm why these issues were happening.

@Fernando-Gietz your plugin is just the piece that is missing on my infrastructure so I can control access from other departments to FOG interface and storages. If I can provide any help on the issue just let me know, thank you!

Hi guys, I didn’t forget about this topic. I’m just currently dealing with some iPXE booting challenges due to the big differences between system archs I have here. I’m almost finished, so I can try out these tests you asked.

So far, some answers:

@Sebastian-Roth said in Error "rcu_sched self detected stall on CPU" on legacy BIOS Capture job:

Are you saying that it does work “sometimes” without an issue. Is that on the same kernel version 4.19.6 that is causing the error initially posted?? Would make it even harder for us to nail this issue down.

As much as I wanted to answer it technically, the best I have is: yes, it’s kinda random. Our business model demands constant infrastructure changes as our clients points out their needs, so we have lots of machines that although are the same models, have slightly different CPUs and BIOS versions, a challenging scenario for applications such as FOG to be set up as an automation tool. So at each node I have to test what FOS image will be the best fit.

So far I had 4.19.6 bzImage + FOG 1.5.5 init.xz working on about 90% of my systems with no bugs, hangings or issues of other nature. For the ones I did find issues, switching it to 4.15.2 as suggested by @george1421 fixed the problems, but only when I used init.xz packed with FOG 1.5.2 binaries.

Using bzImage 4.15.2 + FOG 1.5.5 init.xz gave me kernel panic “FATAL: Kernel too old” messages on every single system I’ve tried it. It happens also with bzImage of all versions from this up to 4.19.6 with the same init.xz, which works fine to boot and start the task, but throws me the errors reported in the title of this topic at given point in image deploy/capture tasks (it’s not always the same point and I didn’t test other kinds of tasks).

@Sebastian-Roth said in Error "rcu_sched self detected stall on CPU" on legacy BIOS Capture job:

Trying to figure out what might be causing this on your hardware I started by reading the kernel docs on this. Essentially it says that this can be caused by many different things (see a detailed list in the document linked) and we might need to turn on CONFIG_RCU_TRACE in the kernel to get an idea where things go wrong. But as a start we would need to have a clear picture of the exact error messages on screen.

Ok, I’ll reproduce the error scenario and take a picture of the screen. I’m doing this right now.

@Sebastian-Roth said in Error "rcu_sched self detected stall on CPU" on legacy BIOS Capture job:

@fenix_team @george1421 @Quazz Ok, I just compiled inits that should work with kernels all the way back to 4.15.x (64 bit and 32bit). Can you guys give those a try in your environments before I make those the default?

Will test it right after the rcu_sched issue.

@george1421 very well, I’ll test as you specified and report the results later.

@george1421 question, should I use original init.xz packed with FOG 1.5.5 or should I downgrade it as well to the 1.5.2 one as you suggested earlier?
I ask it because I already extensively tested 4.18.x down to 4.16.x branches (for both archs) and in all cases I had kernel panic “FATAL: Kernel too old” issues.