grub2 back to lilo ?

grub2 back to lilo ?

[bc w]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

Hi

     I think the problem proposed by this article is very important.

    The article URL is
http://www.linuxplanet.com/linuxplanet/tutorials/7004/1/

http://www.linuxplanet.com/linuxplanet/tutorials/7004/2/


    It said

"In the distant past, Linux used a boot loader called lilo. Lilo was a pain,
because whenever you changed anything, like adding a new kernel, you had to
reboot into the distro where you originally installed lilo to update your
disk's boot partition. You couldn't run lilo from anywhere else because of
version incompatibilities. If you forgot which distro was the one allowed to
run lilo, you were in trouble.

In 2001, grub changed that -- you could make a small shared partition for
/boot and update it from anywhere. Huge improvement!

Now, 9 years later, we have grub2 -- and we're back to the bad old days of
lilo."

"Instead, you're supposed to edit files inside */etc/grub.d*, plus another
file, */etc/default/grub*. That's all very well ... except that those
directories aren't accessible to other distros. If you've set up grub on
your Ubuntu 9.10 partition but you're currently running 10.04, or Fedora or
Gentoo, what happens if you need to add a new grub2 entry? Apparently you're
supposed to reboot back to Ubuntu 9.10, and lord help you if you forget and
accidentally run update-grub from some other system. Ouch! Is this a case of
"Those who don't remember the past are doomed to repeat it?""


How can we solve this problem?

[-- Attachment #2: Type: text/html, Size: 2215 bytes --]

Re: grub2 back to lilo ?

[BVK Chaitanya]

I tend to agree.  IIRC, with grub-legacy (on debian), we could simply
add any user customizations at the end of the menu.lst (after auto
generated list markers) which would remain there even after
update-grub operations.  Thus user had an easier way to add his
customizations (without even need to run update-grub).

With GRUB2 that simplicity is not there anymore.  User has to add his
customizations in two places, /etc/grub.d/40_custom and
/etc/default/grub  Also, he has to run update-grub after any changes.
IMO we need to fix this usecase ASAP.



-- 
bvk.chaitanya

Re: grub2 back to lilo ?

[Colin D Bennett]

Perhaps instead of pre-generating the entire GRUB configuration
(e.g. from a particular Distro like Ubuntu 9.10) things could be
inserted into the main grub.cfg at GRUB boot time.

Here's just a portion of what Ubuntu 10.04 puts in the generated
grub.cfg (of course with a stern warning not to hand modify the file):

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Ubuntu, with Linux 2.6.32-22-generic' --class ubuntu --class
gnu-linux --class gnu --class os { recordfail
        insmod ext2
        set root='(hd0,3)'
        search --no-floppy --fs-uuid --set
534672c7-9930-407e-a13d-66a8e873a842 linux   /vmlinuz-2.6.32-22-generic
root=UUID=a5c8657b-e206-47d5-8cc2-30cc6cbfc77e ro   quiet splash
initrd  /initrd.img-2.6.32-22-generic
}
### etc. etc.


Now what if specific OS parts could be separated out into another file,
which could be referred to by GRUB at boot time.  Something like:

--- grub.cfg

# General settings
set timeout=10
set root='(hd0,3)'

# OS-specific parts
include ubuntu-10.04.cfg
include macos.cfg
include windows_xp.cfg

--- ubuntu-10.04.cfg

menuentry 'Ubuntu, with Linux 2.6.32-22-generic' --class ubuntu --class
gnu-linux --class gnu --class os { recordfail
        insmod ext2
        set root='(hd0,3)'
        search --no-floppy --fs-uuid --set
534672c7-9930-407e-a13d-66a8e873a842 linux   /vmlinuz-2.6.32-22-generic
root=UUID=a5c8657b-e206-47d5-8cc2-30cc6cbfc77e ro   quiet splash
initrd  /initrd.img-2.6.32-22-generic
}

And so on.

Regards,
Colin

Re: grub2 back to lilo ?

[Bruce Dubbs]

Colin D Bennett wrote:
> Perhaps instead of pre-generating the entire GRUB configuration
> (e.g. from a particular Distro like Ubuntu 9.10) things could be
> inserted into the main grub.cfg at GRUB boot time.
> 
> Here's just a portion of what Ubuntu 10.04 puts in the generated
> grub.cfg (of course with a stern warning not to hand modify the file):

The warning is a bit too strong.  It should be more like "Don't modify 
by hand unless you know what you are doing."

I personally think that grub-mkconfig goes too far.  At least the 
distros go too far in completely overwriting grub.cfg.  They make 
assumptions that the users don't know what they're doing.  That is not 
always true.  If there is an existing grub.cfg, the user should at least 
be given a prompt that grub.cfg is going to be overwritten and given a 
chance to bail out.

> ### BEGIN /etc/grub.d/10_linux ###
> menuentry 'Ubuntu, with Linux 2.6.32-22-generic' --class ubuntu --class
> gnu-linux --class gnu --class os { recordfail
>         insmod ext2
>         set root='(hd0,3)'
>         search --no-floppy --fs-uuid --set
> 534672c7-9930-407e-a13d-66a8e873a842 linux   /vmlinuz-2.6.32-22-generic
> root=UUID=a5c8657b-e206-47d5-8cc2-30cc6cbfc77e ro   quiet splash
> initrd  /initrd.img-2.6.32-22-generic
> }
> ### etc. etc.
> 
> 
> Now what if specific OS parts could be separated out into another file,
> which could be referred to by GRUB at boot time.  Something like:
> 
> --- grub.cfg
> 
> # General settings
> set timeout=10
> set root='(hd0,3)'
> 
> # OS-specific parts
> include ubuntu-10.04.cfg
> include macos.cfg
> include windows_xp.cfg

This is a reasonable thing to do, but where are the include files found? 
  I would suggest grub/config.d/

Is there anything that goes in these include files other than menuentries?

One problem is that many distros install in one partition, including 
/boot.  You then have the same problem of having to access another 
partition of various types (reiser, ext4, jfs, xfs, etc) on possibly a 
different drive to find the other /boot partitions.  If we can educate 
user and distros to always have a dedicated small /boot partition, then 
there are several good options.

   -- Bruce

Re: grub2 back to lilo ?

[Colin Watson]

On Sat, May 15, 2010 at 08:02:22AM +0530, BVK Chaitanya wrote:
> I tend to agree.  IIRC, with grub-legacy (on debian), we could simply
> add any user customizations at the end of the menu.lst (after auto
> generated list markers) which would remain there even after
> update-grub operations.  Thus user had an easier way to add his
> customizations (without even need to run update-grub).
> 
> With GRUB2 that simplicity is not there anymore.

Simplicity ... except when it broke.  Which it did, all the time.  Let's
not follow the model of those marker comments!

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: grub2 back to lilo ?

[Marc Haber]

Hi,

On Sat, May 15, 2010 at 08:11:27AM +0100, Colin Watson wrote:
> On Sat, May 15, 2010 at 08:02:22AM +0530, BVK Chaitanya wrote:
> > I tend to agree.  IIRC, with grub-legacy (on debian), we could simply
> > add any user customizations at the end of the menu.lst (after auto
> > generated list markers) which would remain there even after
> > update-grub operations.  Thus user had an easier way to add his
> > customizations (without even need to run update-grub).
> > 
> > With GRUB2 that simplicity is not there anymore.
> 
> Simplicity ... except when it broke.  Which it did, all the time.  Let's
> not follow the model of those marker comments!

Just for the record, grub 0.x's method of generating configuration in
Debian didn't even break once on me.

Greetings
Marc, who would love to have a possibility to edit grub configuration
from a rescue system

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Re: grub2 back to lilo ?

[Colin Watson]

On Sat, May 15, 2010 at 09:21:36AM +0200, Marc Haber wrote:
> On Sat, May 15, 2010 at 08:11:27AM +0100, Colin Watson wrote:
> > Simplicity ... except when it broke.  Which it did, all the time.  Let's
> > not follow the model of those marker comments!
> 
> Just for the record, grub 0.x's method of generating configuration in
> Debian didn't even break once on me.

You weren't the one receiving the bug reports when it did ...

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: grub2 back to lilo ?

[BVK Chaitanya]

On Sat, May 15, 2010 at 12:41 PM, Colin Watson <cjwatson@ubuntu.com> wrote:
> On Sat, May 15, 2010 at 08:02:22AM +0530, BVK Chaitanya wrote:
>> With GRUB2 that simplicity is not there anymore.
>
> Simplicity ... except when it broke.  Which it did, all the time.  Let's
> not follow the model of those marker comments!
>

Given the GRUB script capabilities, we can get this simply by adding

include $prefix/custom.cfg

or similar to grub.cfg.



-- 
bvk.chaitanya

Re: grub2 back to lilo ?

[Marc Haber]

On Sat, May 15, 2010 at 08:41:14AM +0100, Colin Watson wrote:
> You weren't the one receiving the bug reports when it did ...

Granted. Grub2 can use include files in its configuration, yes? Then
it's much easier than with grub legacy.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Re: grub2 back to lilo ?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]

bc w wrote:
> Hi
>
>      I think the problem proposed by this article is very important.
>
>     The article URL is
> http://www.linuxplanet.com/linuxplanet/tutorials/7004/1/
>                               
> http://www.linuxplanet.com/linuxplanet/tutorials/7004/2/
>
>
First of all this list is plain text only. No HTML.
Secondly if you don't like grub.cfg autogeneration you can simply remove
grub-mkconfig and edit grub.cfg manually as much as you want or rather
every time you need it, or rather every time you have any autodetectable
changes.
grub-mkconfig is just a convenience tool meant to have uniform grub.cfg
handling across distributions. But any distribution or user may choose
either to use it or not.
Old way of modifying menu.lst is unsuitable due to grub2 having much
more flexible syntax.
I consider current default way sane and it takes better argument than "I
feel comfortable with XYZ" to change. But it's only a default, feel free
to change on your computer
>     It said
>
> "In the distant past, Linux used a boot loader called lilo. Lilo was a
> pain, because whenever you changed anything, like adding a new kernel,
> you had to reboot into the distro where you originally installed lilo
> to update your disk's boot partition. You couldn't run lilo from
> anywhere else because of version incompatibilities. If you forgot
> which distro was the one allowed to run lilo, you were in trouble.
>
> In 2001, grub changed that -- you could make a small shared partition
> for /boot and update it from anywhere. Huge improvement!
>
> Now, 9 years later, we have grub2 -- and we're back to the bad old
> days of lilo."
>
> "Instead, you're supposed to edit files inside //etc/grub.d/, plus
> another file, //etc/default/grub/. That's all very well ... except
> that those directories aren't accessible to other distros. If you've
> set up grub on your Ubuntu 9.10 partition but you're currently running
> 10.04, or Fedora or Gentoo, what happens if you need to add a new
> grub2 entry? Apparently you're supposed to reboot back to Ubuntu 9.10,
> and lord help you if you forget and accidentally run update-grub from
> some other system. Ouch! Is this a case of "Those who don't remember
> the past are doomed to repeat it?""
>
>
> How can we solve this problem?
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: grub2 back to lilo ?

[Colin Watson]

On Sat, May 15, 2010 at 01:41:09PM +0530, BVK Chaitanya wrote:
> On Sat, May 15, 2010 at 12:41 PM, Colin Watson <cjwatson@ubuntu.com> wrote:
> > On Sat, May 15, 2010 at 08:02:22AM +0530, BVK Chaitanya wrote:
> >> With GRUB2 that simplicity is not there anymore.
> >
> > Simplicity ... except when it broke.  Which it did, all the time.  Let's
> > not follow the model of those marker comments!
> 
> Given the GRUB script capabilities, we can get this simply by adding
> 
> include $prefix/custom.cfg
> 
> or similar to grub.cfg.

I could support that.  It might be simpler than expecting people to edit
/etc/grub.d/40_custom and re-run update-grub.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: grub2 back to lilo ?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

Colin Watson wrote:
> On Sat, May 15, 2010 at 01:41:09PM +0530, BVK Chaitanya wrote:
>   
>> On Sat, May 15, 2010 at 12:41 PM, Colin Watson <cjwatson@ubuntu.com> wrote:
>>     
>>> On Sat, May 15, 2010 at 08:02:22AM +0530, BVK Chaitanya wrote:
>>>       
>>>> With GRUB2 that simplicity is not there anymore.
>>>>         
>>> Simplicity ... except when it broke.  Which it did, all the time.  Let's
>>> not follow the model of those marker comments!
>>>       
>> Given the GRUB script capabilities, we can get this simply by adding
>>
>> include $prefix/custom.cfg
>>
>> or similar to grub.cfg.
>>     
>
> I could support that.  It might be simpler than expecting people to edit
> /etc/grub.d/40_custom and re-run update-grub.
>
>   
This is a good and acceptable possibility. Just keep in mind that it has
to be
#!/bin/sh
echo <<EOF
if [ -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
EOF

If nobody opposes in one week I'll add 41_custom alongside 40_custom.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]