Bug 24566 - M7 beta3 32-bit grub2 going into kernel panic when trying to boot 64-bit M6 install, Removing "VGA=791" from the kernel options fixes the issue.
Summary: M7 beta3 32-bit grub2 going into kernel panic when trying to boot 64-bit M6 i...
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
Keywords: 7beta3
Depends on:
Reported: 2019-03-26 01:41 CET by Thomas Andrews
Modified: 2020-09-20 03:17 CEST (History)
4 users (show)

See Also:
Source RPM: grub2? drakx?
Status comment:


Description Thomas Andrews 2019-03-26 01:41:57 CET
After doing a 32-bit Plasma install from the beta3 Classical iso, and attempting to boot into a 64-bit M6 Plasma install on the same hardware, I see a message almost immediately about vga=791 being depreciated, and after a few seconds it goes into a kernel panic. Booting into the just-installed M7 Plasma system has no problems, and neither does booting into an existing 64-bit M7 Plasma install on the same hardware.

Removing "VGA=791" from the kernel options allows the M6 install to boot, though it "grumbles" a bit with some text messages, and the infamous "three question marks" screen shows up. Once in M6, I used MCC to install the M6 grub2, and all installs booted without incident. Returning to the new 32-bit M7 and using MCC to re-install that grub2 brings the problem back again.

On other hardware, containing one new 64-bit beta3 Plasma install and one 64-bit  M6 Xfce install, booting into M6 proceeds without incident.

Affected hardware: Athlon X2 7750, 8GB DDR2 RAM, Nvidia Geforce 9800 GT graphics (nvidia340 driver).

Unaffected hardware: Intel Core2Duo, 4GB DDR2 RAM, nvidia Geforce 210 video (nvidia340 driver).

Reporting this as "all" even though only the 32-bit bootloader seems to be affected because I am using 64-bit hardware.
Thomas Andrews 2019-03-26 01:42:57 CET

Priority: Normal => High
Keywords: (none) => 7beta3

Comment 1 Marja Van Waes 2019-03-26 09:54:48 CET
Assigning to grub2, which might be entirely wrong :-/

Was that kernel option also added when you re-installed the bootloader in Mageia 6?
And if you re-install it in Mga7 64bit?

Assigning to the mageia tools maintainers, because grub2 doesn't have a registered maintainer and I don't know whether this can be caused by a drakboot & stage2 setting.

Source RPM: (none) => grub2? drakx?
Summary: M7 beta3 32-bit grub2 going into kernel panic when trying to boot 64-bit M6 install => M7 beta3 32-bit grub2 going into kernel panic when trying to boot 64-bit M6 install, Removing "VGA=791" from the kernel options fixes the issue.
CC: (none) => kernel, marja11, zen25000
Assignee: bugsquad => mageiatools

Comment 2 Thomas Andrews 2019-03-26 13:32:37 CET
I did not check the bootloader configuration in the post-install phase of the 32-bit beta3 install. I will try another install on other hardware later today and check it then, but I don't expect to see results that are any different.

When installing grub2 from MCC in both M6 and M7, both arches, "VGA=xxx" is not shown as one of the options to be added. However, if I hit "e" during the boot, it is there, at the end, for every install. 

Typing this on my laptop, currently running M7 as installed from the beta2 isos and fully updated as of about 30 minutes ago. This laptop also contains a 32-bit M6 install. Each install has a couple of old kernels that have not been removed. I have no trouble booting into any of the installs/kernels that are present.

Examining /boot/grub2/grub.cfg on this laptop this morning shows that each non-failsafe list of kernel options has "VGA=791" at the end.
Comment 3 Thomas Andrews 2019-03-26 15:12:05 CET
Another difference on the affected machine: When using "e" to examine the kernel options for M6, the line that includes those options starts with "linux" and the line below that starts with "initrd." Using "e" on the M7 installs shows "linux16" and "initrd16."

Editing those lines for M6 to read "linux16" and "initrd16" while leaving "VGA=791" intact allows the boot to proceed normally, without the "grumbling" and without the infamous "3 question marks" screen.
Comment 4 Martin Whitaker 2019-03-26 19:50:38 CET
You've answered the question I was going to ask, TJ. I had to switch the ISOs to use linux16/initrd16, because the linux/initrd commands caused problems on some machines.

BTW, when configuring the bootloader, the option to set the video mode is hidden away under "Advanced". Don't ask me why!

CC: (none) => mageia

Comment 5 Thomas Andrews 2019-03-27 00:25:50 CET
I took a look at the Intel-based machine that boots OK, and the M6 grub2 entry there is using linux/initrd, as well. The M7 entry uses linux16/initrd16.

And here is something unexpected: Using the M6 MCC to change bootloaders, the M6 entry is using linux16/initrd16, but the M7 entry is using linux/initrd.

And even more: The desktop I'm using now contains several Mageia installs, some M7 and some M6. I am running my main M7 production install now. Looking at /boot/grub2/grub.cfg I see that every boot for this install (I'm WAY behind at removing old kernels) is using linux16/initrd16, but every other boot is using linux/initrd. 

Speculation without knowing what's goin on: grub.cfg is partially created using information passed along by os prober, which is instructing that linux/initrd be used on those other boot entries. If that is accurate, then the bug description should probably be changed to something more appropriate.
Comment 6 Aurelien Oudelet 2020-09-19 18:08:52 CEST
This is High priority bug for a good reason.

Making Mageia even better than ever is best direction.
In order to do right thing, this bug should be examined and fixed as soon as possible.

Packagers, please make the status to Assigned when you are working on this.
Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it.

On October 1st 2020, we will drop priority to normal.
Comment 7 Thomas Andrews 2020-09-20 03:17:26 CEST
I no longer have any M6 installs, since M6 is EOL.

I no longer use the affected hardware. I use the same motherboard, but I upgraded the processor, and replaced the nVidia video card with one made by AMD. 

I do still see that the kernel options for the install associated with the "active" grub2 show "linux16" and "intrd16" while the options for the "inactive" installs are "linux" and "initrd." But, it doesn't seem to matter. None of the systems shows a kernel panic when trying to boot.

Speculation: The newer kernels in M7 aren't as fussy about this as the older M6 kernels were.

Since I seem to have been the only one affected by this bug, and since I am no longer affected by it either, I'm closing it as "old."

Resolution: (none) => OLD

Note You need to log in before you can comment on or make changes to this bug.