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”
signature.asc
Description: OpenPGP digital signature
