Grub2 idea: floating for mindshare

[NoOp]

On 02/06/2010 08:40 AM, Goh Lip wrote:
> On 02/06/2010 11:23 PM, Rashkae wrote:
>> Here's a thought I had about Grub 2 based on recent discussions on this
>> list.
>>
>> I really love Grub2, and think it's been a great improvement in just
>> about every way.  But the automatically generated grub.cfg is just not
>> always easy to cope with for people with more complex systems (ie, maybe
>> someone has multiple versions of Windows and Linux...)
>>
>> However, if you rely on 40_custom for your grub.cfg, you then have to
>> update that file yourself to benefit from kernel updates.
>>
>> My idea is that is that a file like 45_ubuntu_custom be created in
>> /etc/grub.d but be made non-executable.  This file would then be
>> populated by commented out options (just like the old menu.lst) file,
>> and the kernel package post install would insert a boot stanza for the
>> recently installed kernels.  If someone needed to use a custom grub.cfg
>> file, they could then make that file executable (and optionally, remove
>> the exec option from the default grug.d files) and have a system that
>> worked much like the old style menu.cfg.
>>
>>
> I was trying to understand the motivation of your suggestion and looking 
> at your recent messages of the subject, I guess it was that, after each 
> update-grub or kernel upgrade, you have to either:
> 
> o <one> reorder the sequence of the boot order or
> o <two> renter the kernel numbers for kernel upgrades at the 40_custom
>          and delete the preceeding entries again.
> 
> 
> If there are more points that I missed out or have misconstrued your 
> intentions, please revert. May I suggest a third?
> 
> o <three> If kernel upgrade is done at an OS whose grub is not set to
>            mbr, we will need to go to the OS whose grub is set to mbr and
>            do and update-grub to ensure the kernel for that OS
>            is updated.
> 
> 
> In my earlier message, I suggested one alternative, viz., to set default 
> to 'saved'; albeit a somewhat incomplete alternative and does not 
> satisfy point <three>.
> 
> I hope I have summarized correctly but would like more feedback from you 
> or others.
> 
> Again, I like to point out that the above affects grub-legacy as well as 
> grub2 and it puzzles me that grub2 is disliked when the same issues is 
> afflicting grub-legacy as well. It is clearly not a matter of 
> grub-legacy or grub2 but merely the sequence of booting preferences or 
> kernel changes whatever boot mechanism is used.
> 
> As I had alluded to earlier, a first boot partition would be able to 
> handle these issues and I had this on grub-legacy some time back and I 
> had changed it to grub2 when grub2 came on board. Grub2 handles this a 
> lot better.
> 
> Regards - Goh Lip
> 
> 
 Sorry for not trimming, but want to keep everything intact so far...

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.

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.