Grub2 idea: floating for mindshare

[Tom H]

(I did not understand Rashkae's initial post (sorry!) so I have
snipped that post and Goh Lip's reply.)


> Goh, the isse with grub2 (IMO) is the lack of ease in configuring one
> menu file - note my comments/issues with the 'Visa' entries that I would
> rather not appear in my menu on the 'Grub list menu' thread.

I emailed earlier a possible solution to your Vista problem. I have
not tested it because I do not have a similar setup, sorry.


> The same issue applies to multiple Ubuntu kernel entries; I like to keep
> 4-5 kernels and in the past startupmanager allowed me to simply select
> how many entries that I wished to show in the menu. Unfortunately with
> the new startupmanager I am unble to do that.

> Yes I know that is an issue with startupmanager and not grub2 per se.
> But if I elect to show only the 2 most recent kernels I find there is no
> easy way other than to edit /boot/grub/grub.cfg. That file is of course
> autogenerated by /etc/grub.d/30_os-prober.

> Perhaps I've yet to see the overall grub2 picture (quite likely), but
> for the time being grub2 (menu configuration-wise) is for me, a PITA,
> and likely to be so for other users as well. As mentioned in the other
> thread, I very much like the fact that grub2 picks up all of the
> partitions et al, but not so happy that there is not an easy way (that
> I've found) to easily configure the grub2 menu.

I suspect that the grub1 startupmanager allows you to choose the
number of kernels to keep because it was a feature of menu.lst.
grub1's update-grub settings were set through the lines in between the
automagic kernels begin and end lines.

The number-of-kernels update-grub setting is not available in grub2
(although I am sure that one or more scripts could be edited to limit
the number of kernels that have an entry in grub.cfg). Someone raised
a Launchpad bug that I read a while ago and the developers who
responded either did not understand the issue or replied that users
should limit the number of kernels by purging the older ones. I have
just searched for that report and did not find it but found
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/492995

Before finding this "bug" I was going to suggest that you make a
request to add more variables to /etc/default/grub for users to set
the howmany variable and set partitions to be ignored by os-prober
when update-grub is run...

The grub developers are in a bind. I do not know how well or badly
grub1's update-grub detected all os's but grub2's update-grub
certainly detects all Linux and WIndows ones! This reminds me of
dmraid. Until recently, installing Ubuntu (/Fedora/Debian/...) onto
dmraided disks was difficult. IIRC, the Ubuntu help and wiki pages
even said that it wasn't fully supported (or something like that). Now
the installer is so aggressive in detecting and using dmraid that you
have to boot the live cd with nodmraid and possibly uninstall dmraid
to endure that the install is made on "regular" /dev/sdX devices.