[go: up one dir, main page]
|
|
Log in / Subscribe / Register

GRUB 2 becomes the default bootloader in Ubuntu 9.10

June 24, 2009

This article was contributed by Koen Vervloesem

At the Ubuntu Developer Summit, some discussions took place about the status of GRUB 2, and in early June Canonical's Colin Watson announced that GRUB 2 would be the default boot loader for new Ubuntu installations, starting with Ubuntu 9.10 scheduled for release later this year. GRUB 2 will replace GRUB, which has been used for many years for the task of selecting different kernel images or other operating systems to boot from, both in Ubuntu and other Linux distributions.

GRUB is the first thing a user sees after the computer's BIOS has initialized the PC. In recent times Linux distributions have had the tendency to hide GRUB's menu, so one might wonder why users should care about it. Nevertheless, Ubuntu's switch to GRUB 2 will bring internationalization support, greater flexibility and many other improvements to the boot loader. As changing the boot loader is an inherently risky operation, upgrades from existing Ubuntu installations will not replace GRUB by GRUB 2.

Problems with legacy GRUB

Although GNU GRUB is used by virtually all Linux distributions, it has a couple of problems. First, official development for the most used version, called GRUB Legacy, was stopped. The developers still accept bug fixes but don't add new features. They have refocused on GRUB 2, a complete rewrite of the boot loader. This leaves Linux distributions with a maintenance problem, according to Watson in an email interview with your author:

By far the most pressing problem is that we have no upstream for GRUB Legacy; nobody's interested in it. The Debian GRUB maintainers are not especially interested in it either, and are planning to switch over as well. This means we have nobody to forward bugs to, unless we want to treat one of the forks maintained by other GNU/Linux distributions, e.g. Fedora, as effectively "upstream", which would mean figuring out all the stuff that's different between ours and theirs and what might regress.

Because the GRUB developers don't accept new features, each distribution has actually forked the package to add the features it needs. Ubuntu, for example, added support for UUIDs (a "Universally Unique Identifier" to identify a partition uniquely, even when the boot order and hence the name changes) and for the Ext4 file system. But this is not the preferred way to go, Watson admits:

We really don't want to be going it alone on the boot loader if we don't have to, and we think it's generally a net loss for lots of distributions to be maintaining separate boot loader forks for the rest of eternity. It's a lot of effort that we could be spending on something else, it doesn't serve our users very well, and it doesn't serve the free software community very well.

There are also a variety of technical problems without much hope of a good resolution. For example, the mapping of Linux device names to and from GRUB device names, which on a PC-class system ought to be derived from the BIOS boot order, has long been problematic. In principle the primary master hard disk is known to GRUB as hd0, but some BIOSes let the user configure the secondary master hard disk to become the first one to boot, which confuses GRUB. BIOS Enhanced Disk Drive (EDD) Specification support helps when it works, but hardware support for it is rather limited: BIOSes older than a few years don't have it and even newer BIOSes do not implement it consistently or completely. Ubuntu has papered over this with the use of UUIDs, but this only works for some parts of the boot chain. For example, it doesn't help GRUB find its own stage 1.5, the stage that understands a file system. Another problem is the format of the configuration file /boot/grub/menu.lst, which Watson describes as "a historical disaster".

New features of GRUB 2

So which problems would GRUB 2 solve? First, GRUB 2 adds built-in UUID support, so different distributions no longer have to maintain their own hacked-up versions for this. The boot loader has also refactored its multi-stage load process, which according to Watson "is likely to be less of a practical problem than the current load process". Stage 1.5 was eliminated.

Another change is the new configuration file format, which has been entirely overhauled. It has more extensive scripting support, with conditionals, loops, variables and functions, allowing the user to express some more complex booting logic. However, according to Watson this complexity doesn't make it more complex to use these features:

Changing, for example, the default boot options in /etc/default/grub is a matter of a one-line change (GRUB_CMDLINE_LINUX_DEFAULT) and running update-grub. While you could do this kind of thing with our GRUB Legacy packages too if you knew how they worked, it was very unconventional (you edited one part of the file, then ran update-grub to generate the rest of the file ...) and relatively few people discovered it successfully. We hope the more conventional layout here will be more discoverable.

Other interesting new features are the graphical boot menu, internationalization (including support for non-ASCII character codes, fonts and message catalogs like gettext), a modular framework and the possibility of dynamic loading of modules at run time. Beyond that, GRUB 2 also supports non-x86 platforms, such as PowerPC.

What will Ubuntu do with GRUB 2?

Now the question is what GRUB 2 will bring for Ubuntu's users. The more reliable configuration handling should let the developers do some more interesting things at the desktop level, which according to Watson have been difficult in practice before, "as inserting the right options ran a significant risk of stomping over people's local changes." One example he gives is to offer a straightforward interface to reboot into a specific operating system at the desktop level. The user doesn't have to first reboot and then pick that operating system from GRUB's boot menu.

The use of a graphical menu means that, in principle, distributions have a chance of integrating fairly smoothly with kernel mode setting even when a boot menu is displayed. Watson adds:

Whether we can entirely avoid a visible mode switch between the boot loader and the kernel is as yet unclear, but we should at least be able to make it a smoother transition than it is right now.

There's a Google Summer of Code project to add graphical menu support to GRUB 2, although it hasn't landed yet. Even though Ubuntu will be aiming for a so-called "quiet-by-default" boot loader, which doesn't show a boot menu by default, Watson expects from the sheer volume of requests that many Ubuntu users will be interested in a graphical boot menu that they can tweak with their own theme.

Why switch now?

The switch to GRUB 2 doesn't come out of the blue. According to Watson, Ubuntu has been keeping half an eye on GRUB 2 for some time:

I think it was first brought up as a possibility for Ubuntu 5.10, but it was just far too early. Anyone who's been watching GRUB 2 for some time will agree that there was a long period when development was very slow, focus was not as much on the common case as it should have been, and anything that might be usable in production looked a long way off.

This situation has changed considerably in recent times. The pace of development over the last year has picked up markedly, and there's now quite an active GRUB 2 community in place. Then, pressure to add proper support for things like EFI and boot menu internationalization in Ubuntu has been growing, so the developers thought they'd take the opportunity to have another look at the new boot loader:

We ran it through all the machines the Ubuntu kernel team could get their hands on (a respectable selection). The results from that were encouraging - in fact, I don't think there was a single failure on the hardware we had, although of course we probably had somewhat newer hardware than the average.

Ubuntu is not alone in this task. As Watson says, Debian makes a big difference to Ubuntu too:

The guts of our installer support for boot loaders is largely shared with Debian, and a lot of the work to integrate GRUB 2 has already been done there. The Debian GRUB maintainers are determined and confident to switch Debian over for Squeeze. As a Debian installer developer myself, I think it benefits both projects for Ubuntu to be up to date with current development efforts.

With all this in mind, the Ubuntu developers felt that switching over was much more feasible than they'd previously thought, and that the risk of there still being a couple of missing features was tolerable given the pace of upstream development. Watson considers the time ripe now for GRUB 2 in Ubuntu:

I think we've struck a reasonable balance between the risk of regressions and the risk of being a really conservative late adopter only to find that it doesn't work for us but everyone else is now totally reliant on it and scared to change it. The timing works out pretty well for us, as this gives us a couple of release cycles to get used to it before our next long-term-support release.

No switch to GRUB 2 in openSUSE 11.2

While Ubuntu is switching later this year, openSUSE currently has no plans to switch to GRUB 2 in its next release, version 11.2. Andreas Jaeger explains this:

Experience with GRUB and LILO showed that there are many subtle ways that can break and therefore a change will need really good testing. GRUB 2 is not released yet, and the latest alpha version was released more than a year ago - nothing that gives much confidence into the stability of the code and the interfaces from my perspective for the moment. However, I applaud Ubuntu for taking this risk - and in the same way helping to move GRUB 2 forward to a stable release.

Jaeger is right that GRUB 2 is not entirely ready. For example, some GRUB Legacy functionality isn't yet supported in GRUB 2: it doesn't have boot password support yet, and the savedefault functionality which saves the current menu entry as the default entry doesn't work properly.

According to Jaeger, the openSUSE developers have so far not received a single request to move to GRUB 2. But if somebody volunteers to maintain the package and integrate it in openSUSE, he welcomes it to give it some testing and then decide if it can be used for future releases. He adds that support for GRUB 2 doesn't mean only a new package, but also changes the way the boot loader setup is automatically generated by openSUSE's system management tool YaST.

Fedora

The Fedora developers also have no concrete plans to use GRUB 2 as their default boot loader. However, Fedora's GRUB 2 maintainer Lubomir Rintel sees the current situation with GRUB clearly as unsatisfactory:

What I see as a big problem with legacy GRUB is that currently inactive former upstream failed to provide a single place for GRUB users (distributions) to cooperate and share fixes, declaring the project dead long before any viable alternative existed. On top of that, distributions somehow failed to cooperate either, virtually each of them having its own fork of GRUB with unique features (ext4 support, EFI, bugfixes, ...)

GRUB Legacy has posed some real problems for Fedora. For example, the support for Ext4 didn't land in the version shipped with Fedora 11, because the patches weren't ready in time for the beta. This means that Fedora 11 users can't boot from an Ext4 file system, something that is possible in Ubuntu 9.04.

Rintel sees the active upstream community of GRUB 2 as a nice advantage, especially now that Ubuntu is going to use it. He expects the community around it to grow and the quality of the GRUB 2 code to increase rapidly, increasing chances of inclusion in other distributions, including Fedora. In the meantime, he will ensure that GRUB 2 is up-to-date with upstream code and easily installable for anyone interested in using it in Fedora. The short runway for Fedora 12 means that there's really not that much time to get GRUB 2 in shape for Fedora's next release, but according to Fedora's wiki the integration is planned for Fedora 13.

With respect to the technical qualities of GRUB 2, Rintel is mostly impressed about GRUB 2's modular architecture. He calls other features such as the graphics subsystem with mouse support capable of rendering antialiased Unicode glyphs "hardly things that would convince anyone to switch to GRUB 2".

An interesting adventure

It remains to be seen which hurdles Ubuntu has to take for the switch from the stable legacy GRUB to the new GRUB 2. Adventurous Ubuntu users can already test GRUB 2 in Jaunty Jackalope and are invited to report any bugs. If this experiment turns out successfully, other distributions could very well follow Ubuntu's lead.


Index entries for this article
GuestArticlesVervloesem, Koen

to post comments

Maintenance of GRUB 1

Posted Jun 25, 2009 1:37 UTC (Thu) by proski (guest, #104) [Link] (1 responses)

In my opinion, instead of complaining that GRUB 1 has been abandoned, one of the distros should have taken over the maintenance. It's hard to get volunteers to maintain the old version. And it's really not too much work. The patches for GRUB 1 are floating around. And the immediate benefit would be the ability to install the whole system on ext4.

Maintenance of GRUB 1

Posted Jun 27, 2009 19:52 UTC (Sat) by giraffedata (guest, #1954) [Link]

In my opinion, instead of complaining that GRUB 1 has been abandoned, one of the distros should have taken over the maintenance.

But what they're complaining about is that it's too much work to maintain even for their own use. Maintaining it for everybody would be even more work, so how is that an alternative to complaining?

This just looks to me like a classic case of open source users exploiting the free work of others (original maintainers of GRUB 1), then being sorry when those folks choose to stop providing. So they complain (nothing wrong with that), and look around for the next best free offering to exploit, which in this case may be GRUB 2.

The GRUB story was something of a shock because the GRUB 1 developers abandonned it (to the point of branding it "legacy," effectively discouraging people from using it) so they could work on something newer, but did so long before the new thing was at least as good as the old one (missing documentation was the biggest regression I saw). It doesn't usually happen that way.

Rhaaa, yet another font format!

Posted Jun 25, 2009 9:00 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (3 responses)

So they felt they needed to invent a new font format. Couldn't they really use one of the numerous existing ones? (restricting possibly to a specific profile with a profile checker).

They claim they want unicode support but specify ascii metadata.

And they've forgotten the third style attribute in modern (CSS/WPF) font classifications, width.

http://blogs.msdn.com/text/attachment/2249036.ashx
http://blogs.adobe.com/typblography/typotechnica2007/Font...

Now that Apple, Adobe and Microsoft finally agreed on a common universal font format (OpenType) do we actually need a new platform-specific application-specific one?

http://www.microsoft.com/typography/tt/sbit.htm

Rhaaa, yet another font format!

Posted Jun 26, 2009 4:39 UTC (Fri) by colinb (guest, #59303) [Link] (2 responses)

As the author of the graphical menu support in GRUB 2 and the creator of the new font format, I can defend the decision to create a new font format in a few ways. First, it was decided at the beginning of the graphical menu project that bitmap fonts should be used at first, and possibly down the road we could add support for vector (outline) fonts, and we would definitely need to depend on an external library for the more complex rendering of vector fonts. There has been discussion of using the FreeType library to provide support for OpenType, TrueType, and many other font formats. In my opinion, full vector font support would not be too difficult to add to GRUB.

As for using an existing bitmap font format such as BDF of PCF, I seriously considered them but found them altogether unsatisfactory for our specific purpose. Here is my analysis of why another font format was needed. We also have discussed plans to add LZMA compression support to the font format, which would dramatically improve storage efficiency without impacting performance, by providing near-random access to characters of the font through compressing groups of characters together.

As for the omission of the 'width' property of fonts, I simply considered that too unimportant of a detail, particularly in light of the fact that non-antialiased bitmap fonts were the only target of that font format, and none of the free fonts we tested with were provided in different widths.

I do take your point about ASCII metadata for the fonts. True textual data such as the font name and family name should be Unicode strings, not ASCII.

Regards,

Colin

Correction to article: No font antialiasing or mouse support *yet*

Posted Jun 26, 2009 4:49 UTC (Fri) by colinb (guest, #59303) [Link] (1 responses)

Also, a quick correction to the article, which states:

With respect to the technical qualities of GRUB 2, Rintel is mostly impressed about GRUB 2's modular architecture. He calls other features such as the graphics subsystem with mouse support capable of rendering antialiased Unicode glyphs "hardly things that would convince anyone to switch to GRUB 2".

Actually, mouse support has not been added yet, though USB support has recently been added, and I'm about to commit the graphical menu branch to GRUB's mainline, so mouse support is not far off. Rendering antialiased text is not supported with the current bitmap-based fonts. If and when we add support for font rendering with FreeType, then we will have antialiased text rendering.

Regards,

Colin

Correction to article: No font antialiasing or mouse support *yet*

Posted Nov 13, 2009 14:01 UTC (Fri) by evgenyz (guest, #61962) [Link]

So, why you then just don't make this bitmap font 8-bit/pixel? With such an alpha channel you can do anti-aliasing in compile (font conversion, huh) time and simply draw it in run time ("...making the code to read the font simple than we are with writing the font.").

Size? Just complete LZMA! It will be far more simple (and faster) to implement than OpenType rendering in run time.

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 25, 2009 9:15 UTC (Thu) by marcH (subscriber, #57642) [Link] (6 responses)

> Another change is the new configuration file format, which has been entirely overhauled.

As long as they do not switch to human-unwritable XML...

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 25, 2009 13:01 UTC (Thu) by clugstj (subscriber, #4020) [Link] (2 responses)

That's the first thing I though of also when I read that. I don't know what the new format is, but I'm sure someone suggested XML (they always do).

They just did

Posted Jun 25, 2009 18:59 UTC (Thu) by proski (guest, #104) [Link] (1 responses)

http://lists.gnu.org/archive/html/grub-devel/2009-06/msg00445.html

They just did

Posted Jun 25, 2009 20:33 UTC (Thu) by cjwatson (subscriber, #7322) [Link]

That's probably OK for the layout engine, but I think it'd be terrible for the menu itself, which does need to be human-readable and -writable even by people who aren't fond of XML. (And having syntactically-significant newlines inside XML tags is just odd ...)

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 25, 2009 15:53 UTC (Thu) by alankila (guest, #47141) [Link]

It is some kind of scripting language. Here's part of my config:

insmod raid mdraid
set root=(md0)
search --no-floppy --fs-uuid --set 5e0f1983-e597-4ef3-b167-e127b30b95ef
if loadfont /usr/share/grub/ascii.pf2 ; then
  set gfxmode=640x480
  insmod gfxterm
  ...
fi

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 25, 2009 20:25 UTC (Thu) by martinfick (subscriber, #4455) [Link] (1 responses)

Ahh, XML.

All the readability of binary with all the efficiency of ASCII! :) Who could ask for more?

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 26, 2009 7:14 UTC (Fri) by k8to (guest, #15413) [Link]

Sadly XML does not achieve the efficiency enjoyed by most text formats, or even most text complex data serialization formats.

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 25, 2009 11:44 UTC (Thu) by ikm (subscriber, #493) [Link]

Thanks for the great article, made a nice read.

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 25, 2009 13:55 UTC (Thu) by jengelh (subscriber, #33263) [Link] (5 responses)

GRUB1 used to write to the disk directly, bypassing the linux fs. That did not fare well with delayed-allocation based filesystems, most notably xfs, but it also effects ext3 to a certain degree. Did they fix that in GRUB2?

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 25, 2009 15:50 UTC (Thu) by alankila (guest, #47141) [Link] (4 responses)

As far as I remember, the issue is not actually writing to the disk bypassing the FS. It is the fact that XFS can consider files stored only in the journal as committed on the disk, and then later on moves the data from the journal to the final locations. GRUB 1's XFS module used to ignore the journal, so it might not see the most recent versions of all files. I also don't know if the grub installation procedure might embed sector locations for boot files while they still exist only in the journal.

Sadly, I don't know if this problem has been solved.

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 25, 2009 16:31 UTC (Thu) by proski (guest, #104) [Link] (1 responses)

GRUB 2 don't require direct writing to any filesystem for installation. Direct read access to the filesystem at the installation time is possible, but it's discouraged, and it's not the default mode of operation. The default is embedding the core into the sectors following the MBR (master boot record, the first sector of the hard drive).

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jul 1, 2009 8:02 UTC (Wed) by The_Barbarian (guest, #48152) [Link]

Or for GPT, grub is normally put into the BIOS boot partition or the EFI system partition.

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jun 25, 2009 20:36 UTC (Thu) by cjwatson (subscriber, #7322) [Link] (1 responses)

It was at least solved in recent Debian versions of GRUB Legacy by way of xfs_freeze -f/-u, so in the worst case it'd be straightforward to apply the same hack for GRUB 2; I forget where this came up, but I understand that the XFS kernel code itself is also better at handling freeze/thaw now in a way that isn't quite so unfriendly to GRUB.

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jul 4, 2009 9:58 UTC (Sat) by abpsoft (guest, #53672) [Link]

Calling it solved is a bit bold - that xfs_freeze hack has the tendency of freezing - indeed - the whole box solid, provided that system has / (including /boot) on XFS and an unsuspecting admin tries to run grub-install. That hack might work when run from d-i, but in a live system (let's say, after upgrading from etch to lenny and pondering whether it may be time to finally replace LILO) it's a disaster. It should at least print a big fat warning before actually freezing a live FS that might have plenty of write activity.

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jul 4, 2009 20:54 UTC (Sat) by muwlgr (guest, #35359) [Link] (3 responses)

LILO works well for me, boots my systems from md/raid1 array.
Don't know why throw it away and replace with GRUB2.
The only warts for LILO I noticed for the years are: lack of LVM/LVM2 support (especially if your LVM PVs are created on md arrays themselves), and that it searches for MBRs only on hard disks with BIOS number 0x80 and higher, so fails on BIOSes that assign removable drive numbers for your USB flash (0x2..0x7f).
For me, GRUB1 lacks a feature that I often used and liked in LILO: to create a filesystem on the entire unpartitioned volume
(like, mkfs.ext3 /dev/sdb) and then to install a bootloader into its boot sector, i.e. the case when you don't have partition table at all. Don't know if GRUB2 could do that. Anyone knows ?

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Jul 5, 2009 16:53 UTC (Sun) by obi (guest, #5784) [Link] (2 responses)

I've got boxes with root on crypto on lvm2 on md (raid1), and boot on lvm2 on md (raid1). Grub2 can deal with it without difficulty.

As for grub2 on a volume without a partition table - I'll have to try it out.

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Sep 3, 2009 15:53 UTC (Thu) by jmcnulty (guest, #60140) [Link] (1 responses)

This is what I'm looking forward to the most: being able to use disks each with just one single partition to create a single MD raid device with LVM on top containing LVs for boot, swap and /.

That way I can assign another disk as a spare raid disk and have the loss of one whole disk replaced by another whole disk. Right now I can't do that as I have to partition both disks into two and create two raid devices: one for /boot and one for LVM. I can't assign spare disk to each of these as loss of a disk would try and map two spare disks to replace two partitions. Well, either that or it would fall flat on its face. It's so dumb I've not even tried it. GRUB2 solves this dilemma, so it can't arrive fast enough for me.

GRUB 2 becomes the default bootloader in Ubuntu 9.10

Posted Dec 4, 2009 18:14 UTC (Fri) by hop9807 (guest, #62334) [Link]

I find Grub 2 in ubuntu 9.10 64 bit to be a real pain. First of all there is no utility available that will allow one to edit and and it shows up with multiples of the same os if you have several hard drives but only some are actually connected to that os.

When I had to reinstall windows 7 the grub would then not load but gave a grub rescue message. None of the parameters to recover grub worked nor did any of the instructions I used from several "help forums". Ended up having to fix mbr in windows 7. I will never use grub 2 again unless a utility is developed to recover it and edit the entries.


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds