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.
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.
kernel, marja11, zen25000Assignee:
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.
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.
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.
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!
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.