FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 02-14-2012, 07:35 PM
"mike@trausch.us"
 
Default grub vs grub 2

On 02/14/2012 02:04 PM, Michael Mol wrote:
> A detailed elaboration would be nice.
>
> A contrasting migration guide, complete with the how's, where's and
> why's would be awesome. (Once one's invested in understanding a tool,
> a 1-2-3-itsmagic walkthrough is very discomforting.)

While there are many different points that differ between the two, the
biggest are:

- Supported upstream.

- Can boot from GPT as well as MBR partition table types, regardless
of whether EFI is in use or not. Also supports the use of Apple
Partition Maps, BSD disk labels, and others through modules.

- Doesn't require patching to deal with modern situations; you can
download upstream source code and it will work, unlike GRUB Legacy.

- Can boot from virtually any filesystem you would want to use,
not just a small handful of them; includes ISO9660, UDF, Reiser,
btrfs, NTFS, ZFS, HFS and HFS+, among others.

- Supports selecting filesystems by UUID without distribution-specific
patches, for filesystem types that can be identified by UUIDs.

- Can be booted from BIOS or EFI on the PC, and no longer depends on
the existence of any particular type of firmware (no more probing
for BIOS boot drives, which can fail on many different systems).

This means that GRUB 2 doesn't have to be hand-installed on systems
GRUB Legacy couldn't figure out for whatever reason. And yes, there
were a good number of them, where LILO was the only choice due to
its use of block maps (another not-so-robust booting mechanism which
required significantly more maintenance than GRUB does).

- Can boot Linux, the BSDs, any Multiboot or Multiboot2 kernel, and
EFI applications.

- Supports El Torito natively on platforms that use it (e.g., BIOS)
to boot optical media, meaning that it is possible to use GRUB 2
boot anything that can be burned to an optical disk. This makes it
easier to work with testing environments burned to any form of
optical disk.

- Better code quality than GRUB Legacy, with more loose coupling
between components and making it possible for people to more easily
write GRUB modules than with GRUB Legacy. Additionally, nearly
anything that would have been a patch to GRUB Legacy can be written
as a module in GRUB 2, making it easier to share modules between
distributions. This also means it is *much* more portable.

- Can be run as an EFI application on modern systems using EFI, such
as Intel-based Macintosh systems, without requiring BIOS emulation.
It can also emulate an EFI environment for things which require it
in order to boot.

- Eliminates dependence on BIOS in order to determine available boot
devices. This empowers GRUB to be able to boot without firmware
assistance from many different mediums, including USB and PXE, even
without firmware support.

- Supports booting from Linux device-mapper and LVM2 configurations,
as well as encrypted partitions.

- Supports kernels > 16 MB in size without patches. This can happen
when you compile a purely static kernel and support a great deal of
options without putting them into modules. Not common, but does
happen.

Additionally, GRUB 2 standardizes (upstream) a number of things which
were developed independently by various distributions as patches for
GRUB Legacy. Gentoo's legacy GRUB is heavily patched,

The configuration file isn't terribly difficult to figure out, either;
as I've mentioned before, there is *absolutely* no requirement to use
grub2-mkconfig, it just makes life easier.

For example, here is the entry that boots my current kernel:

menuentry 'GNU/Linux, with Linux 3.2.5-gentoo' --class gnu-linux --class
gnu --class os {
load_video
insmod gzio
insmod part_gpt
insmod ext2
set root='(/dev/sda,gpt2)'
search --no-floppy --fs-uuid --set=root
3820beff-80b5-4d05-b989-3ab9265bc2a3
echo 'Loading Linux 3.2.5-gentoo ...'
linux /vmlinuz-3.2.5-gentoo root=/dev/sda3 ro

Adding an entry is no more complex as it was before; copy, paste, edit.
Simple. No commands necessary since GRUB reads the grub.cfg file from
the filesystem when it loads, and doesn't embed it anywhere.

(And yes, I have a separate /boot; reason being is that it is mounted -o
sync, that is, when it is mounted at all. At least on my primary
desktop system; /boot is actually on the root fs on most of my systems.)

There will be a day when GRUB Legacy won't be supported by distributions
at all. There's no need to maintain multiple bootloaders (and upstream
refuses to do so, reasonably), and many of the tricks, patches and
workarounds of old are no longer necessary with GRUB 2.

Also, it becomes possible to use the Linux kernel's long-existing
installation hook to automatically update the boot list when you "make
install modules_install" a new kernel image, making kernel installation
literally a single step after the build. Many different distributions
did this before by implementing scripts that do what grub2-mkconfig does
with GRUB 2, but for GRUB Legacy. Now, that's standard and upstream so
that there isn't fragmentation.

All told, GRUB 2 is *significantly* simpler, especially from the POV of
someone who installs, maintains and fixes systems for a living but also
from the POV of distribution packagers and maintainers.

--- Mike

--
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
--- Carveth Read, “Logic”
 
Old 02-14-2012, 07:42 PM
"mike@trausch.us"
 
Default grub vs grub 2

On 02/14/2012 02:29 PM, Andrea Conti wrote:
> Re grub2: as long as grub0 works, I really don't care if grub2 is
> better, cleaner, shinier, more modern or anything else.
>
> I don't need a freakin' whole OS to boot linux, and having a
> configuration that is so convoluted that it *has to* be generated by
> running a set of scripts makes no sense at all. I thought the days of m4
> and sendmail.cf were over a long time ago...

Well, it's a good thing that GRUB 2 is just a bootloader, then. :-)
And again, nobody needs the tools to configure it; they are simply
standardized from what various distributions developed for GRUB Legacy,
but was incompatible from one distribution to the next.

> I am sure grub2 can be made to work, but for a piece of software as
> vital as a boot loader, that level of complexity in my opinion is
> totally unreasonable and impossible to justify.

How about "It Just Works". Seriously.

It is a better designed system with most of its functionality pushed
into modules. It is portable to more than just x86, as I've already
mentioned before, and during _that_ whole process, the quality of the
code increased significantly. It is more robust, and from the POV of a
user, maintainer, or packager it is *much* simpler.

When supporting GRUB Legacy, it's almost a necessity to know which
distribution the user installed it with. Why? Because all of them are
different! That is no longer the case with GRUB 2.

I'm not sure how that translates to being more complex. If you are
averse to change, just say so and be done with it. Is it different?
Oh, yes, absolutely. It couldn't be better if it were the same, could
it? ;-)

--- Mike

--
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
--- Carveth Read, “Logic”
 
Old 02-14-2012, 07:45 PM
Michael Mol
 
Default grub vs grub 2

On Tue, Feb 14, 2012 at 3:35 PM, mike@trausch.us <mike@trausch.us> wrote:
> On 02/14/2012 02:04 PM, Michael Mol wrote:
>> A detailed elaboration would be nice.
>>
>> A contrasting migration guide, complete with the how's, where's and
>> why's would be awesome. (Once one's invested in understanding a tool,
>> a 1-2-3-itsmagic walkthrough is very discomforting.)
>
> While there are many different points that differ between the two, the
> biggest are:
>
> *- Supported upstream.
>
> *- Can boot from GPT as well as MBR partition table types, regardless
> * *of whether EFI is in use or not. *Also supports the use of Apple
> * *Partition Maps, BSD disk labels, and others through modules.
>
> *- Doesn't require patching to deal with modern situations; you can
> * *download upstream source code and it will work, unlike GRUB Legacy.
>
> *- Can boot from virtually any filesystem you would want to use,
> * *not just a small handful of them; includes ISO9660, UDF, Reiser,
> * *btrfs, NTFS, ZFS, HFS and HFS+, among others.
>
> *- Supports selecting filesystems by UUID without distribution-specific
> * *patches, for filesystem types that can be identified by UUIDs.
>
> *- Can be booted from BIOS or EFI on the PC, and no longer depends on
> * *the existence of any particular type of firmware (no more probing
> * *for BIOS boot drives, which can fail on many different systems).
>
> * *This means that GRUB 2 doesn't have to be hand-installed on systems
> * *GRUB Legacy couldn't figure out for whatever reason. *And yes, there
> * *were a good number of them, where LILO was the only choice due to
> * *its use of block maps (another not-so-robust booting mechanism which
> * *required significantly more maintenance than GRUB does).
>
> *- Can boot Linux, the BSDs, any Multiboot or Multiboot2 kernel, and
> * *EFI applications.
>
> *- Supports El Torito natively on platforms that use it (e.g., BIOS)
> * *to boot optical media, meaning that it is possible to use GRUB 2
> * *boot anything that can be burned to an optical disk. *This makes it
> * *easier to work with testing environments burned to any form of
> * *optical disk.
>
> *- Better code quality than GRUB Legacy, with more loose coupling
> * *between components and making it possible for people to more easily
> * *write GRUB modules than with GRUB Legacy. *Additionally, nearly
> * *anything that would have been a patch to GRUB Legacy can be written
> * *as a module in GRUB 2, making it easier to share modules between
> * *distributions. *This also means it is *much* more portable.
>
> *- Can be run as an EFI application on modern systems using EFI, such
> * *as Intel-based Macintosh systems, without requiring BIOS emulation.
> * *It can also emulate an EFI environment for things which require it
> * *in order to boot.
>
> *- Eliminates dependence on BIOS in order to determine available boot
> * *devices. *This empowers GRUB to be able to boot without firmware
> * *assistance from many different mediums, including USB and PXE, even
> * *without firmware support.
>
> *- Supports booting from Linux device-mapper and LVM2 configurations,
> * *as well as encrypted partitions.
>
> *- Supports kernels > 16 MB in size without patches. *This can happen
> * *when you compile a purely static kernel and support a great deal of
> * *options without putting them into modules. *Not common, but does
> * *happen.
>
> Additionally, GRUB 2 standardizes (upstream) a number of things which
> were developed independently by various distributions as patches for
> GRUB Legacy. *Gentoo's legacy GRUB is heavily patched,
>
> The configuration file isn't terribly difficult to figure out, either;
> as I've mentioned before, there is *absolutely* no requirement to use
> grub2-mkconfig, it just makes life easier.
>
> For example, here is the entry that boots my current kernel:
>
> menuentry 'GNU/Linux, with Linux 3.2.5-gentoo' --class gnu-linux --class
> gnu --class os {
> * * * *load_video
> * * * *insmod gzio
> * * * *insmod part_gpt
> * * * *insmod ext2
> * * * *set root='(/dev/sda,gpt2)'
> * * * *search --no-floppy --fs-uuid --set=root
> 3820beff-80b5-4d05-b989-3ab9265bc2a3
> * * * *echo * *'Loading Linux 3.2.5-gentoo ...'
> * * * *linux * /vmlinuz-3.2.5-gentoo root=/dev/sda3 ro
>
> Adding an entry is no more complex as it was before; copy, paste, edit.
> *Simple. *No commands necessary since GRUB reads the grub.cfg file from
> the filesystem when it loads, and doesn't embed it anywhere.
>
> (And yes, I have a separate /boot; reason being is that it is mounted -o
> sync, that is, when it is mounted at all. *At least on my primary
> desktop system; /boot is actually on the root fs on most of my systems.)
>
> There will be a day when GRUB Legacy won't be supported by distributions
> at all. *There's no need to maintain multiple bootloaders (and upstream
> refuses to do so, reasonably), and many of the tricks, patches and
> workarounds of old are no longer necessary with GRUB 2.
>
> Also, it becomes possible to use the Linux kernel's long-existing
> installation hook to automatically update the boot list when you "make
> install modules_install" a new kernel image, making kernel installation
> literally a single step after the build. *Many different distributions
> did this before by implementing scripts that do what grub2-mkconfig does
> with GRUB 2, but for GRUB Legacy. *Now, that's standard and upstream so
> that there isn't fragmentation.
>
> All told, GRUB 2 is *significantly* simpler, especially from the POV of
> someone who installs, maintains and fixes systems for a living but also
> from the POV of distribution packagers and maintainers.

Very nice, thanks.


--
:wq
 
Old 02-14-2012, 07:57 PM
LK
 
Default grub vs grub 2

On 120214, at 21:42, mike@trausch.us wrote:

> On 02/14/2012 02:29 PM, Andrea Conti wrote:
>> Re grub2: as long as grub0 works, I really don't care if grub2 is
>> better, cleaner, shinier, more modern or anything else.
>>
>> I don't need a freakin' whole OS to boot linux, and having a
>> configuration that is so convoluted that it *has to* be generated by
>> running a set of scripts makes no sense at all. I thought the days of m4
>> and sendmail.cf were over a long time ago...
>
> Well, it's a good thing that GRUB 2 is just a bootloader, then. :-)
> And again, nobody needs the tools to configure it; they are simply
> standardized from what various distributions developed for GRUB Legacy,
> but was incompatible from one distribution to the next.
>
>> I am sure grub2 can be made to work, but for a piece of software as
>> vital as a boot loader, that level of complexity in my opinion is
>> totally unreasonable and impossible to justify.
>
> How about "It Just Works". Seriously.
>
> It is a better designed system with most of its functionality pushed
> into modules. It is portable to more than just x86, as I've already
> mentioned before, and during _that_ whole process, the quality of the
> code increased significantly. It is more robust, and from the POV of a
> user, maintainer, or packager it is *much* simpler.
>
> When supporting GRUB Legacy, it's almost a necessity to know which
> distribution the user installed it with. Why? Because all of them are
> different! That is no longer the case with GRUB 2.
>
> I'm not sure how that translates to being more complex. If you are
> averse to change, just say so and be done with it. Is it different?
> Oh, yes, absolutely. It couldn't be better if it were the same, could
> it? ;-)
First, why do we need that much code? If we have less then we dont
have to divide into modules.
Second, it does not translate into complex but rather into too much,
and whenever it is too much than needed, its hard to understand
and THUS complex. Not the other way.
>
>
> A man who reasons deliberately, manages it better after studying Logic
> than he could before, if he is sincere about it and has common sense.
> --- Carveth Read, “Logic”
>
 
Old 02-14-2012, 07:57 PM
James
 
Default grub vs grub 2

Florian Philipp <lists <at> binarywings.net> writes:


> sys-boot/grub has two slots. The default slot 0 with version numbers
> around 0.92-0.97 is grub-1 (or grub legacy). Slot 2 with version numbers
> around 1.99 is grub-2. Because it is still in development hell, it has
> not reached version 2.00.

OK, this part I understand.

> IIRC, sys-boot/grub-static is mostly there for systems that cannot
> compile grub, for example AMD64 no-multilib profiles.

OK, from the handbook....
Thanks for clearing that up.

The second part of this question, is what version of grub do I use
with an AMD64 RAID-1-workstation install that will use this
(multilib) profile:

[5] default/linux/amd64/10.0/desktop/kde *

But I intend to put RAID-1 on the boot/root/swap partitions.
ext2 and ext4 FS for boot/root.

Any preferred version of grub (grub-1) will do ?

Trying to use this document:
http://en.gentoo-wiki.com/wiki/RAID/Software
The advice about grub (1 vs 2) and mdadm RAID-metadata
all confuses the grub choice for me.

Should I use Grub-1 ? or Grub-2 ?

Or maybe I should just do a traditional gentoo (handbook) install
and then migrate to a RAID-1 workstation, via this document:

http://en.gentoo-wiki.com/wiki/Migrate_to_RAID

I've spent countless hours on numerous attempts to do it all in
one install, and grub will not boot for me.

IDEAS?


James
 
Old 02-14-2012, 08:44 PM
Neil Bothwick
 
Default grub vs grub 2

On Tue, 14 Feb 2012 21:57:03 +0100, LK wrote:

> > I'm not sure how that translates to being more complex. If you are
> > averse to change, just say so and be done with it. Is it different?
> > Oh, yes, absolutely. It couldn't be better if it were the same, could
> > it? ;-)
> First, why do we need that much code?

Because there is that much real world. Sure, you and I only need a small
subset of it, but can you guarantee it is the same subset? The idea is
that GRUB2 can work everywhere out of the box, without tweak, hacks and
patches.


--
Neil Bothwick

Cross a tagline and a tribble? You get a full HD...
 
Old 02-14-2012, 08:46 PM
Neil Bothwick
 
Default grub vs grub 2

On Tue, 14 Feb 2012 20:29:26 +0100, Andrea Conti wrote:

> I don't need a freakin' whole OS to boot linux, and having a
> configuration that is so convoluted that it *has to* be generated by
> running a set of scripts makes no sense at all.

No it doesn't. so thankfully, outside of your FUD, this is not true.

There are scripts to automatically generate a configuration but
grub-mkconfig is no more compulsory than genkernel - but both can make
life easier when setting up multiple, different systems.


--
Neil Bothwick

Your lack of organisation does not represent an
emergency in my world.
 
Old 02-14-2012, 10:19 PM
"mike@trausch.us"
 
Default grub vs grub 2

On 02/14/2012 03:57 PM, LK wrote:
> First, why do we need that much code?

First, are you talking about source or binary code?

If you're talking about source code, then realize this: Not all that
source is even compiled on your system.

As to the source that *is* compiled on your system, there is:

- A tiny boot loader (max 448 bytes of binary code), which loads
the GRUB core.

- The GRUB bootloader core, which is the GRUB "main" program and
which knows how to talk to different types of modules.

- The modules themselves. There are modules for:

- disk types, including PATA, SCSI, USB, Device Manager, DMRAID,
LVM, LUKS.

- filesystems, including ext2, btrfs, reiserfs.

- partition types, including MBR, GPT, Apple Partition Map.

Each type of module implements exactly the same interface; the core only
needs to know how to talk to that type of module to communicate with all
modules that implement that interface.

The modular design makes it easier to (a) support new platforms, boot
protocols, bus types, partition types, and filesystems, and (b) ensure
that only code necessary for a particular type of thing is loaded.

This design is _necessary_ to deal with today's world. Your computer is
almost certainly setup differently from mine; I require the use of a GPT
module on my system, for example. You may not, if you still use MBR.
In fact, if you're using GRUB Legacy, then you almost certainly do not
require the GPT module on your system (at least not right now).

GRUB 1 assumed BIOS, and assumed MBR. GRUB 2 assumes neither. And for
that matter, supports encrypted disks and logical volume management
(both relatively common especially in servers) without third-party patches.

For the _most_ part, GRUB 2 is simply designed to handle today's world.
It also includes features that distributions developed (independently,
and incompatibly between each other) for GRUB 1 as patches or add-on
programs.

> If we have less then we dont
> have to divide into modules.

Not true; modules are used in GRUB not because it's too big (once in
32-bit protected mode, all memory becomes available), but to help
organize the system better. This simplifies the design. If I want to,
I can create a new type of filesystem, and then all I have to do to make
sure that GRUB 2 supports it is to write a module that knows how to talk
to it. Nothing changes anywhere else in GRUB. If I create a new type
of firmware, I simply write code that knows how to talk to that type of
firmware, and I am done. Now GRUB 2 still runs on my PC, but also runs
on my new custom computer. And that code for my custom computer never
gets loaded on your computer, because your computer never uses it.

Modules in this case are a structural (design) thing to simplify the
design of the program, not to make it possible to fit in memory or
anything like that.

> Second, it does not translate into complex but rather into too much,
> and whenever it is too much than needed, its hard to understand
> and THUS complex. Not the other way.

Having spent the last 30 minutes looking at the GRUB 2 sources from the
bzr repo, I can tell you that it's very easy to understand; once you
understand how the FS interface works, it's very easy to learn how one
FS module reads a filesystem. And you then gain the understanding
required to write a new, independent module.

Think of GRUB 2's modules as "subprograms" if you must, which implement
a particular (and identical) API for each instance.

If you're interested, I can detail a history for you, and explain why
GRUB 1 was discontinued and why the whole thing was restructured in
detail. I can't right now, as I am about to get on a conference call,
but I can certainly do so later tonight or tomorrow if you want.

What it boils down to, though is that GRUB 1 made assumptions (that
every computer used BIOS, that every computer used MBR partition tables)
which no longer hold true. Because they no longer hold true, it was
necessary to push that functionality into modules with a standardized
interface, in order to support EFI and GPT. That also enabled GRUB 2 to
be able to run on more than one platform, since it no longer made
assumptions that were specific to consumer-class PC systems.

--- Mike

--
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
--- Carveth Read, “Logic”
 
Old 02-14-2012, 10:47 PM
Paul Hartman
 
Default grub vs grub 2

On Tue, Feb 14, 2012 at 12:52 PM, mike@trausch.us <mike@trausch.us> wrote:
> It also supports partition schemes other than MBR, which is useful
> since I use GPT on my systems.

FYI Gentoo's GRUB 0.9x in portage has supported GPT for at least 2 or
3 years now. I'm using it with GPT partitions and my systems all boot.
 
Old 02-14-2012, 10:53 PM
"mike@trausch.us"
 
Default grub vs grub 2

On 02/14/2012 06:47 PM, Paul Hartman wrote:
> FYI Gentoo's GRUB 0.9x in portage has supported GPT for at least 2 or
> 3 years now. I'm using it with GPT partitions and my systems all boot.
>

Not all distributions do. I have been running GPT for quite some time,
while I only switched to Gentoo (relatively) recently.

That said, I also stopped using GRUB 0.9x when GRUB 1.9x became stable
enough to deploy widely, since I was quite tired of fixing broken GRUB
setups (almost never my own, mind).

Since the so-called "mainstream" distributions switched to GRUB 2, I
take a lot less calls for "my system stopped booting". Now most of
those are Windows breakages. :-)

--- Mike

--
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
--- Carveth Read, “Logic”
 

Thread Tools




All times are GMT. The time now is 11:47 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org