public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Mol <mikemol@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] grub vs grub 2
Date: Tue, 14 Feb 2012 15:45:02 -0500	[thread overview]
Message-ID: <CA+czFiCOAS0xDgrgphsEJ6ZYu8C9Rc0c4V_wkUehwDpM3pWEsA@mail.gmail.com> (raw)
In-Reply-To: <4F3AC593.4040701@trausch.us>

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



  reply	other threads:[~2012-02-14 20:50 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-14 17:36 [gentoo-user] grub vs grub 2 james
2012-02-14 17:53 ` Florian Philipp
2012-02-14 18:08   ` LK
2012-02-14 18:24     ` mike
2012-02-14 18:40       ` LK
2012-02-14 18:46         ` Alecks Gates
2012-02-14 18:52         ` mike
2012-02-14 19:04           ` Michael Mol
2012-02-14 20:35             ` mike
2012-02-14 20:45               ` Michael Mol [this message]
2012-02-14 23:47           ` Paul Hartman
2012-02-14 23:53             ` mike
2012-02-14 19:29         ` Andrea Conti
2012-02-14 19:53           ` [gentoo-user] grub vs grub2 LK
2012-02-14 19:59             ` Michael Cook
2012-02-14 20:44               ` mike
2012-02-14 20:58                 ` LK
2012-02-14 21:19                   ` Michael Mol
2012-02-14 20:30             ` Alex Schuster
2012-02-14 20:46             ` mike
2012-02-14 20:42           ` [gentoo-user] grub vs grub 2 mike
2012-02-14 20:57             ` LK
2012-02-14 21:44               ` Neil Bothwick
2012-02-14 23:19               ` mike
2012-02-15 12:19                 ` Tanstaafl
2012-02-15 12:28                   ` Neil Bothwick
2012-02-15 12:33                   ` Michael Mol
2012-02-15 14:37                   ` mike
2012-02-15 14:47                     ` Tanstaafl
2012-02-15 15:02                       ` Neil Bothwick
2012-02-14 21:46           ` Neil Bothwick
2012-02-15 15:57             ` [gentoo-user] " James
2012-02-15 16:11               ` Neil Bothwick
2012-02-15 16:28                 ` Claudio Roberto França Pereira
2012-02-15 17:17                   ` Paul Hartman
2012-02-15 17:33                 ` Doug Hunley
2012-02-15 17:40                   ` Neil Bothwick
2012-02-15  8:10           ` [gentoo-user] " ny6p01
2012-02-14 20:57   ` [gentoo-user] " James
2012-02-14 18:07 ` [gentoo-user] " Stefano Crocco

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+czFiCOAS0xDgrgphsEJ6ZYu8C9Rc0c4V_wkUehwDpM3pWEsA@mail.gmail.com \
    --to=mikemol@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox