Grub2 idea: floating for mindshare
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.
Similar Topics
| Topic | Started |
|---|---|
| Problem with newer DVD's in ubuntu 10.04 (Video-Player) | 52 min 27 sec ago |
| ARM ubuntu on the beagleboard xM | 54 min ago |
| Re: Network installation server for Ubuntu | 1 hour 17 min ago |
| Re: ubuntu 10.4 Shutdow | 1 hour 47 min ago |
| FIXED: Ubuntu 10.04 Shutdown solution | 6 hours 35 min ago |
| [Fixed: Ubuntu 10.04 Shutdown] | 8 hours 44 min ago |
| Ubuntu 10.4 Shutdown | 10 hours 44 min ago |
| Test | 15 hours 53 min ago |
| Strange video behaviour | 18 hours 16 min ago |
6 comments
Re: Grub2 idea: floating for mindshare
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
Re: Grub2 idea: floating for mindshare
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.
Re: Grub2 idea: floating for mindshare
Yes, I see your point in so far as changing grub.cfg involves
/etc/default/grub and /etc/grub.d and doing an update-grub.
As others have pointed out, it's okay to do a direct, manual change to
grub.cfg (especially on first choice of boot) as long as we know it will
revert back once an kernel change or new grub version is effected.
With my 'first boot', I do not need to touch the OS grub system at all,
and looking now at the grub.cfg, especially the hardy grub (it's on
grub2), it is a mile high (time to purge some old kernels) and the
entries are a lengthy "Ubuntu, with Linux 2.6.32-12-generic" etc
compared to the simple "Hardy", "Lucid", "Vista" etc that I have on the
'first grub'.
On a related note, Tom H has posted in a separate newer thread, an
interesting workaround script for 30_os-prober. Since I don't have a
need for this, it would be good if others can replicate and confirm it.
His 'script-fu' is too good for me to understand.
Regards -Goh Lip
Re: Grub2 idea: floating for mindshare
(I did not understand Rashkae's initial post (sorry!) so I have
snipped that post and Goh Lip's reply.)
I emailed earlier a possible solution to your Vista problem. I have
not tested it because I do not have a similar setup, sorry.
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
<a href="https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/492995" title="https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/492995">https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/492995</a>
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.
Re: Grub2 idea: floating for mindshare
Works. Thanks again!
The upstream is telling...
<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548600" title="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548600">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548600</a>
<quote>
It would be nice if you could submit this upstream at
<a href="mailto:grub- ... at gnu dot org">grub- ... at gnu dot org</a>. 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.
Re: Grub2 idea: floating for mindshare
You might want to register at
<a href="https://savannah.gnu.org/account/register.php" title="https://savannah.gnu.org/account/register.php">https://savannah.gnu.org/account/register.php</a>
which is the upstream-upstream for grub rather than the debian-upstream.
Although the grub developer (FZ) suggests that "you" join the
grub-devel list and make a request there.
No idea what the difference between the two is - and which is the more
efficient course of action.