Folks,

I'm struggling with an HP Envy Laptop that runs with an old Kernel (3.6) but the kernel is too old to support a wi-fi module (Intel only supply drivers for 4.1+).

I can run Mageia 6 Cauldron from a USB stick, install it, boot once or twice and then get a "kernel panic not syncing fatal exception in interrupt" issue.

Why would it be that I can boot to Mageia from a USB stick (sometimes with a kernel panic, usually not), yet once it is installed it just refuses to boot?

If there's any information I can supply (I don't know what I should or could give) please ask and I will post it here.

Many thanks!

DiBosco,

Did Mike Jones not have any words of wisdom on installing Linux in your HP Envy-15-ah150sa?

Nope. No reply at all. I'm trying alternative methods and don't want to pollute one thread with another.

DiBosco,

Fair enough.

I have amended my post accordingly.

I'd bet for a too big kernel and would try to slim it down.

If it boots correctly then I'd suspect that the install went OK. The question becomes what happened on next shutdown(s) that caused it to fail. Did it update? Did you add in and drivers?

I'd just install it and then reboot it with no network connected. Be sure to shutdown properly and fully. See if you can get some replication of effects.

Might be able to look at /var/logs

At what point does the kernel panic? before or after being prompted with a login?

If before, perhaps the bootloaders root= that is passed to the kernel is wrong. Or the /etc/fstab is wrong. It may not look wrong, but if it's root=/dev/... then the /dev/ name can change between boots if multiple drives are plugged in. I remember an older motherboard with both IDE (PATA) and SATA drives. And it was pretty much /dev/ roulette when you powered up the machine. The first drive to power up and announce itself to the bios won, which was probably the IDE drive 2 out of 3 times. But that's why we have LABELs and UUIDs.

If after, you might check the dmesg and /var/log/syslog files from another bootable medium after to see what it did (and logged) last. It could be something semi-obvious like 32 bit versus 64 bit. Or something not so obvious.

@Shadow_7. The panic appears a long time before log in. I've gone into a live boot and got /var/log/dmesg and dmesg.old, but they don't mention the kernel panic. I Googled to find where the boot logs would be and answers seemed to indicate that file, I'm not convinced at all I have got the right one. I've attached them just in case.

I've also attached a picture of the screen when it panics. Looks like it's just loaded udev kernel device manager.

@jefro, I don't think I added anything or did anything other than reboot. I will try another install tomorrow and reboot to see. I will also see if I can see any difference in boot parameters.

@Tonus, how would I slim down the kernel?!

Thanks for all the suggestions.

Attached Thumbnails

 

Attached Files

	dmesg.old.txt (70.2 KB, 13 views)
	dmesg.txt (70.6 KB, 18 views)

Recompile it with most things modular and avoid what you do not have the use.

You might be missing the driver for the motherboard to use the drive. Normally handled by an initrd image or by compiling the module into the kernel instead of as a module. The bootloader loads the kernel (or initrd image) and then passes control off to it. At which point it gets lost since it left the flashlight back at camp. Assuming that there is a bootloader. Throw in secure boot and things can be quirky. Throw in newer drive types like NVME and you might need a more bleeding edge kernel than provided by the distro. Where usb has been fairly well supported in kernel versions spanning years or decades. Throw in exotic filesystems and it may require additional tools not in a default installation for your distro. But most commonly, the /etc/fstab location does not match the / location. Or the bootloader tells the kernel to look over here and it really should look over there.

I don't think it's going to be anything bleeding edge because one distribution (Debian 8.5) which as an old kernel (3.16 ish) works (other than wi-fi as Intel only support kernel 4.1 onwards.) . When you update the kernel to a later one it goes funky.

With Mageia which has a 4.6 kernel, it won't have it. I've tried numerous other distributions and they all do the same as Mageia.

I've tried with and without legacy boot (the Debian version doesn't support EFI AFAIK) and secure boot is disabled completely.

I did go and look at the fstab and check the UUIDs of the HDD partitions against where /boot and / were and they *seemed* to be OK. I could well be missing something though.

I wish I could find some logs that tell you exactly what is going on. The live stick allows me to see /var/log, but I couldn't find any file that mentioned kernel panics.

I know this sounds sarcastic, but I don't mean it to...how can it be a driver for the motherboard to use the drive if it installs the distribution to the drive from the live stick?

Let's get this correct. You said that you installed a distro and booted to it. It worked at least once so we have to assume that the install was good at that point. You are confusing the story with the live boot deal. The issue is that you booted once and then on some subsequent boot it fails.

When you installed did you do a full power down or just do a reboot to this install.

Once or twice, yes, I did manage to boot into it one time. The last four or five times I've installed, it's panicked the first and every time I've tried to boot it.

As far as powering down, yes; I powered down, removed the USB stick/external DVD and rebooted. After that, I can't remember, the one time I managed to boot into the installed OS, whether I powered down or just rebooted.

It's never booted into the installed OS more than once. Twice I have done an install and booted into it once, then been unable to a second time. The exception being Debian with an older kernel. I will see if I can dig out and old version of Mageia and try that. Not sure what it would prove though TBH.

FWIW, lots of other live installs such as Mint KDE, Fedora, Kubuntu just panic as soon as you try and boot. ie They don't install at all!

Because a) usb storage support works out of the box. And b) the driver for the motherboards storage device is "loaded" as a module when it is needed from the working usb storage. The problem is that when you boot it from NOT usb storage and need that driver (before it's loaded), you have a bit of a chicken and an egg scenario. An initrd image works around this by loading a version of the kernel (with modules) via the bootloader. It could not be this at all. Just one of many possibilities.

About the only time I have issues and the kernel works for a given system is when the /etc/fstab is wrong. Or grub is configured for root=/dev/ and the /dev/ name changes between boots. One really should use LABELs or UUIDs these days which may not be the default grub configuration (update-grub). Plus other quirks like " / " being mounted as read-only, which for semi-obvious reason prevents logs from being written. Which is the default if systemd is in play and /etc/fstab is not setup. At least in debian.

I have the issue too, thanks for all the information now I think how to solve my problem!! Thanks!!