[Mageia-dev] Grub2 vs. Grub Legacy in M3

Barry Jackson zen25000 at zen.co.uk
Mon Feb 4 13:23:47 CET 2013


On 03/02/13 18:05, Felix Miata wrote:
> On 2013-02-02 10:08 (GMT) Barry Jackson composed:
>
>> Felix Miata wrote:
>
>>> Good start:
>>> 1-/boot/grub2/i386-pc/core.img in a Grub Legacy stanza succeeds
>
>>> Not good from then on:
>>> 1-Grub2 error message due to not finding some png file
>
>> You removed the png by using --no-suggests
>
> One cannot remove what is not present. What I did was block installation
> of packages that the grub2 package does not declare to be required.
> Grub2 should not be configured to show user an error resulting from its
> own installation misconfiguration. That looks like a bug.
>
>>> 2-25 item Grub 2.00 menu (grub.cfg:
>>>      http://fm.no-ip.com/Tmp/Linux/Mdv/grub.cfg.gx27b-cauldron3-1.txt ).
>>> After selecting a selection from a master bootloader, there's no good
>>> reason to see similar selections as in the previous menu unrelated to
>>> the chosen selection. IOW, when not a master bootloader (i.e.
>>> "chainloaded" via core.img, only Mageia entries attributable to selected
>>> filesystem hosting core.img should be in this menu.
>
>> If that is what you want then:-
>> # urpme os-prober
>
> Why was it installed when I did 'urpmi --no-suggests grub2' if it's not
> required?
>
> # urpme os-prober
> To satisfy dependencies, the following 2 packages will be removed...
>      grub2-yada
>      os-prober-yada...
>

Right, sorry - I agree - I never really envisaged anyone not wanting 
os-prober installed, however it should really be a Suggests - I will 
change that.

However I should have pointed out that it can be disabled in 
/etc/defaults/grub with

GRUB_DISABLE_OS_PROBER=true

>>> 3-Grub2 menu uses same awful spindly-looking font responsible in large
>>> part for my distaste for *buntu
>
>> Yes could be a lot better, but it's mainly a choice based on licensing,
>> probably will be improved in the future.
>
> What's wrong with nice legible BIOS native fonts?

Try commenting out the line in /etc/defaults/grub

#GRUB_THEME=...

and also temporarily rename /boot/grub2/fonts

Run "grub2-mkconfig -o /boot/grub2/grub.cfg"
after changing anything in /etc/deafult/grub before rebooting.


Is that better for you?

>
>>> 4-default menu selection for Cauldron causes this cmdline:
>
>>>      BOOT_IMAGE=/boot/vmlinuz-prv
>>> root=UUID=bbe8a402-5fb1-4247-b372-5bb6cff4e18c ro splash
>
>>> which is nothing like the default Grub Legacy menu stanza's cmdline
>>> result:
>
>>>      root=LABEL=22cauldrn splash=verbose noresume video=1152x864
>>> vga=794 3
>
>>> obviously caused by Grub2 installation disregarding content of
>>> pre-existing menu.lst ....
>
>> grub2 does not pay any attention to legacy menu.lst - it's a totally
>> different, unrelated bootloader.
>
>> If you want grub2 to use an existing legacy menu.lst then you can use
>> grub2-menulst2cfg tool to create a grub.cfg from menu.lst.
>
>> Usage: grub2-menulst2cfg [INFILE [OUTFILE]]
>
> Nice in theory, but the root device is off by -1. Default menu.lst
> cmdline includes root=LABEL=22cauldrn instead of UUID or device name,
> which is apparently disregarded by grub 2.
>
> menuentry 'Cauldron defkernel' {
>    legacy_kernel   '(hd0,22)/boot/vmlinuz' '(hd0,21)/boot/vmlinuz'
> 'root=LABEL=22cauldrn' 'splash=verbose' 'noresume' 'video=1152x864'
> 'vga=794' '3' ''
>    legacy_initrd '(hd0,22)/boot/initrd' '(hd0,21)/boot/initrd'
> }
>
> It works when I s/hd0,21/hd0,22/g.
>
That looks like an upstream bug - I will investigate.

>>> 5-semi-legible blue on black graphical progress bar instead of normal
>>> complement of startup messages when splash=verbose
>
>> The font colours were chosen to complement the background image which
>> you chose not to install.
>
> I saw no fonts in that progress bar. I asked for no progress bar.
>

OK remove the theme as above and set:

GRUB_CMDLINE_LINUX="3"

... for runlevel 3 and just remove the "splash" on that line for verbose 
output.

>>> 6-post ESC, startup messages are inappropriately tiny
>
>> Sounds like the same issue I used to have when I was using nvidia
>> graphics with nouveau.
>> Using intel I don't see this.
>
> # lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated
> Graphics Controller (rev 02)
>

Hmm - dunno then - I do see a drop in size which appears to happen after 
grub2 has handed over to the kernel.

>>> 7-tty text is too tiny to use (same as startup messages; screen's
>>> preferred mode 1600x1200 used instead of legible mode 1152x864)
>
>> Probably configurable in /etc/defaults/grub but off hand I don't know
>> the variable name - should be in the maunual somewhere.

I'm suspecting this is not a grub2 issue but I may be wrong.
>
> grub2-menulst2cfg picked up the ones that work in Grub Legacy (vga=
> ((http://www.kernel.org/doc/Documentation/kernel-parameters.txt)) &
> video= ((http://www.kernel.org/doc/Documentation/fb/modedb.txt))), which
> are kernel parameters. They do the same thing loaded via Grub2 as when
> loaded via Grub Legacy.
>
>>> 8-KDM is on tty2, the location I reserve for certain class of recurring
>>> activities, instead of where expected on tty7
>
>> Dunno - I have never seen this.
>
> Booting with 3 on cmdline and later doing startx or init 5?

I think that startx and init are deprecated in favour of proper systemd 
commands now.

> On current
> boot I used 3 on cmdline, logged in on tty2 & tty3, did startx on tty3,
> and found X is running on tty3. On exiting the X session I did init 5.
> That put KDM on tty1. On openSUSE & Fedora the problem is essentially
> the same, e.g.: https://bugzilla.novell.com/show_bug.cgi?id=768788
>

I don't think this is grub2 related.
Graphical desktop should default to tty1 now, however I have seen an 
issue where it moves to tty7 after stopping and re-starting 
prefdm.service. I have not checked this recently.

>>> 9-preferred initial runlevel as evidenced by menu.lst cmdline options
>>> was not specified
>
>> Again menu.lst is nothing to do with grub2
>
> Maybe grub2-menulst2cfg should be used instead of grub2-mkconfig when
> grub2 is added to a system with grub previously installed.

Yes that could be an option, although for the majority of users I 
suspect that os-prober does what is needed.


More information about the Mageia-dev mailing list