Grub2 idea: floating for mindshare

[NoOp]

On 02/09/2010 05:56 PM, Tom H wrote:
> (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.

Works. Thanks again!

> 
> 
>> 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

The upstream is telling...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548600
<quote>
It would be nice if you could submit this upstream at
grub-devel at gnu.org. Though you need to subscribe first.
</quote>
Thanks for the link to the bug report. I'll try to add to it (the
launchpad bug) tomorrow.

> 
> 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.
>