Bug 2161152
| Summary: | systems does not boot after kernelupgrade to 4.18.0-425.10.1.el8_7.x86_64 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Need Real Name <hansjoerg.maurer> |
| Component: | kernel | Assignee: | core-kernel-bot <core-kernel-mgr> |
| kernel sub component: | Kernel-Core | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Status: | CLOSED DUPLICATE | Docs Contact: | |
| Severity: | urgent | ||
| Priority: | unspecified | CC: | aquini, chref, reynolds |
| Version: | 8.7 | Flags: | pm-rhel:
mirror+
|
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-01-19 22:23:39 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Need Real Name
2023-01-16 06:48:13 UTC
This seems to be the same class of issue as reported at https://bugzilla.redhat.com/show_bug.cgi?id=2160842 Would you mind setting the system up to collect a vmcore when such occurrences are observed? Hi could you provide a link to a document how to collect vmcore? The affected systems run at two customer locations and we will need a step-by-step guide to collectthe information. Regards Hansjörg (In reply to Need Real Name from comment #2) > Hi > could you provide a link to a document how to collect vmcore? > The affected systems run at two customer locations and we will need a > step-by-step guide to collectthe information. > You can start here: https://access.redhat.com/solutions/6038 It's also advisable, if you don't know how to set up the system to capture a vmcore when it hangs, to open a support case with Red Hat support department and get help to accomplish it. (Bugzilla is not a support channel) Hi thanks. The problem occurs at very early boot(waiting for device-mapper) when trying to resume from hibernation (as you can see from the log. Therefore I doubpt, that kdump would be available at this stage? Regards Hansjörg Hi I found this https://elrepo.org/bugs/view.php?id=1316 "RHEL8.7 system with the kernel version 4.18.0-425.3.1.el8.x86_64 fails to boot with soft lockup message" Any kmod packages that use the affected 'pv_lock_ops' symbol need rebuilding against (bug-free) kernel-4.18.0-425.10.1.el8_7 And the affected systems have nvidia.ko installed from elrepo I will test the new nvidia.ko today and let you know, if it helps Regards Hansjörg (In reply to Need Real Name from comment #5) > Hi > > I found this > > https://elrepo.org/bugs/view.php?id=1316 > > "RHEL8.7 system with the kernel version 4.18.0-425.3.1.el8.x86_64 fails to > boot with soft lockup message" > > Any kmod packages that use the affected 'pv_lock_ops' symbol need rebuilding > against (bug-free) kernel-4.18.0-425.10.1.el8_7 > Yes, that's correct. There was an unwittingly and silent KABI break introduced on kernel-4.18.0-425.el8, which made modules built for older releases stop loading due to the paravirt lock patching. The fix for that KABI break, introduced in kernel-4.18.0-425.10.1.el8_7 end up causing the same problem for modules compiled against all earlier RHEL-8.7 builds. So, in your case a module that was compiled for kernel-4.18.0-425.3.1.el8.x86_64 will stop loading when updating the kernel to 4.18.0-425.10.1.el8_7. -- Rafael *** This bug has been marked as a duplicate of bug 2160842 *** Hi with the new nvidia-x11-drv-525.85.05-1.el8_7.elrepo.x86_64 the system boots with 4.18.0-425.10.1.el8_7 again Regards Hansjörg |