I’m having a kernel panic on F:32 and F:33, running a custom build of Fedora. We use Fedora to create an initramfs and vmlinuz for a bootable image (kiosk web browser) and it never goes past a kernel panic. The weird thing is that the F:32 and F:33 Workstation live images do seem to work (although without audio). The custom build works on hundreds of other systems, but newer systems seem to struggle sometimes.
Is anybody else having kernel panics with Fedora on this system?
Okay, good to hear that your HP doesn’t appear to have any issues. Your model, however, is the G3. It’s 3 years older than the G8 I am testing with our custom image. That one was released last year in November.
It happens very often that very new systems simply don’t have the hardware support to run the most recent kernels. We often have to wait for newer kernels to come out, which support the required hardware.
Since your G3 is over 3 years old, it makes sense that you aren’t having any similar issues.
We basically use Fedora containers to install some necessary packages, required to keep users locked into a web browser on a very minimalistic version of Fedora. So we are using Fedora to basically boot some sort of kiosk web browser, which connects to an environment to supply our services. These services are not really relevant right now.
The part that is relevant, is that this system never goes past a kernel panic. We usually see this when, indeed, hardware is simply too new to support. The HP ProBook 450 G8 was released November of last year, so the odds that this system is simply too new are quite probable.
I was just wondering if others have had Fedora kernel panics on this system. Using the “nomodeset” boot parameter allows me to bypass the kernel panic and fire up our custom image, but then it doesn’t have audio. This leads me to believe that it is indeed a missing kernel module.
Are others having kernel panics using F:32 or F:33 on this system? Are there any boot parameters that could enable audio when modesetting is turned off?
It appears to me that something is up with “custom” initramfs (see the first 2 lines in your photo)
and all what comes later (the panic) in the boot process is probably caused by an damaged/misconfigured initramfs.
so I would suggest to try to get a “normal Fedora” running at first and later starting with custom $(something}
and if the box - cause of being too new - won’t run F32, F33 or F34 I would try with rawhide (the newest Kernel).
But be aware: rawhide isn’t for daily use.
I currently don’t know if boot media for rawhide are out somewhere
IIUC the nomodeset is related to GPU. That implies you may have 2 different issues with that probook and the fact that it is that new.
First, is the gpu appears to be causing the kernel panic. Nomodeset bypasses by blocking attempts to load a video driver. Then the sound does not work.
Perhaps if you were post the ouput of “inxi -Gxx” we could help with the video (nomodeset) problem. Then the output of “inxi -Axx” could help with the sound.
We have traced the problem to being USB-related. We have similar images being built for iPXE as well as USB. This system does not support legacy boot options, so those go out the window immediately.
As for UEFI, PXE images work (but without audio). USB images are the ones giving the kernel panics. The same USB-image DOES work on other systems in our infrastructure. Most of these DO support legacy boot options.
My personal conclusion is, that this is either a legacy USB issue, or simply a hardware support (kernel, BIOS) one. Further actions would include:
updating the kernel,
updating iPXE, or
updating the BIOS.
However, these were obviously some of the first things we already tried. I’ll keep this issue open and try newer kernels or BIOS firmware as they come out.
We are still getting kernel panics on this device, even with the latest kernel (5.11.16). They only seem to appear when building a bootable USB image, using cpio to create initrd. Fedora 34 Workstation boots fine through USB. iPXE only appears to have some sound issues (these can be fixed by turning off DMIC with kernel parameters, but this disables the mic).
For some reason however, when creating a custom initrd with this kernel, it will still give a kernel panic. The same USB image works on almost all of our other test devices. This leads me to believe that the USB kernel modules might not fully support this system yet.
I would like for the developers to take a look at this, but I don’t quite know where to start. Does anybody have an idea?