Kernel Panic - I panic

This may be only of interest only to people who Dual Boot. Here is what I saw on my PC when I booted Mint sometimes.

Kernel Panic
Please reboot your computer
Fatal exception in interrupt

My panic was I had just install MX 25 a couple days ago, so I delete the MX 25 partition thinking it was the problem. I also have MX 23 on the PC.

What I found out.
The problem was intermittent.
It only occurred when I restarted (warm boot) the PC from MX to Mint.
Shutdown of PC and boot (cold boot) to Mint and there was never a panic from the Mint’s kernel.

I always thought a restart of the PC was the same as a shutdown (power off). AI help me resolve this problem and believe it to be correct.

My guess is MX 25 during startup loads firmware into various motherboard components. The warm boot, I think , skips reloading firmware. So switching distros with a warm boot might try to run Mint on MX firmware.
That said… I do it all the time… ie switch distros with a warm boot …it does not usually give trouble.

I have MX25 controlling grub … to test it out. It gives a message about not finding EFI , but it continues into grub OK.
I think MX25 needs a couple more updates.

That was the exactly opinion of the AI. It suggest the cold boot which force the reloading of everything. Power off / power on - I never saw a panic. I thought it was a little funny that MX did not seem to care about the warm restart. Did not see a panic from MX, going form Mint to MX.

Reading about Howard s problems with mx 25 and given his level of computer knowledge why are others not jumping up and down about problems or is it just different things linked together hardware and op systems combinations causing this

I’d suggest playing around with GRUB_CMDLINE_LINUX instead …

Yes, the AI suggest this change.

"#GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash reboot=pci pci=nomsi acpi=force”

But I see two extra parameters. Maybe over kill. The above change cause Mint to crawl. The mouse moved slowly and apt update-grub took 3 to 5 minutes to complete.

When I backed out the change I commented the line. So just adding the reboot=pci fixed your problem?

I had Mint controlling grub. Do you think that would make a difference?

Exactly, it did.

Strange we have 2 kernel panic questions today….. different hardware and linux systems.

Coincidence, what else?
Wait - didn’t both have dual boot? :grin: :wink:

Warm boots are generally OK. There is something strange about MX25?

Not many dual booters in this world.
I have been getting some strange messages on my screen when I use MX25 to bring up the grub menu.
Maybe MX25 has a very new version of grub?

@abu
I forgot about that ‘boot works, reboot doesnt’ topic.
Yes , I think
GRUB_CMDLINE_LINUX =“reboot=pci”
or similar
may do tne trick

I have no idea… we do not know what is causing this problem.
It does seem that grub is behaving strangely?

Not 100% sure what caused the kernel panic I was experiencing. Here are my observations. not necessarily in order.

1 - Did see the problem until I install MX25.
2 - I was doing a lot of warm (restart) booting.
3 - Both MX25 and MX23 caused the panic to occur.
4 - A restore of Mint was not necessary. I thought it was.
5 - Update grub was not needed from MX23.
6 - After the panic, power off / on and Mint was okay.
7 - I panic (jump to think MX25 was the problem) and deleted MX25 from PC.
8 - Panic still happen after MX25 was gone.
9 - Never saw Mint panic after cold start of PC.
10 - MX never had a panic.
11 - Mint panic was intermittent from warm start after MX.

My error was believing restarting the PC was the same as power off / on.
The best explanation I hear is a restart did not reset all the components in the PC.
Mint is more sensitive then MX during initialization and issues the message “Fatal exception in interrupt”

I have not tested the option suggested by @abu yet, but will give it a try.

Welcome to the club (of believers). I had to get the same experience. :grin:

I made the change you suggested with reboot=pci. I restart the PC and went to MX23. Then restarted the PC and went back to Mint. No panic but it was intermittent, so it may take a few days to see what happens. The change did not cause Mint to react differently.

Do you have dual boot?

No, never!

On dual boot this is an interesting topic. Who controls grub? On my PC Mint control grub.

Maybe this was unusual or the way it works on who owns grub. Working on the panic one comment from AI was maybe the MX23 at kernel 6.1 and Mint at 6.8 may be causing some conflict on the warm start.

So I decided to load kernel 6.8 to MX23. Then I update-grub, re-booted, and check to see the new kernel was there and it was not! It was sill 6.1.

I finally got MX23 to load kernel 6.8 by going back to Mint, who owned grub, and perform update-grub there. Going back to MX23 and the correct kernel was loaded.

I thought this was strange.

Did you say earlier that it was with windows as well or did I mix that up ?

So 3 boot possible or was it another computer

I think I can explain that.
When you update a kernel or grub in MX23, it should automatically run update-grub during the update, in order to get a new grub.cfg in MX23. If it does not do it automatically you should do it by hand.
then
When Mint , the grub controller , runs, it needs to do update-grub too, in order to consult the new update-grub in MX23, and build a new grub menu and new entries in its grub.cfg. Mint will not do this update-grub automatically, you have to tell it.

Maybe this explains what happened with MX25. After you installed MX25, did you do update-grub in Mint?

Are you sure Mint is still the grub controlling distro?
It might be worth doing grub-install in Mint , just to be sure?

grub-install --efi-directory=/boot/efi  <disk name if you have more than one disk>

Yes, I am sure I did. MX25 showed up as one of the OS’s to select to boot from. I let Mint control grub so it is at the top of the menu and loads by default. After I installed MX25 and updated grub the menu had 4 OS’s to choose from.

Mint, MX25, MX23, and Windows.

grub-install - The OS that issues this command owns grub. I learn this from one of your posts.