GRUB 2.00 Bootloader Officially Released

An anonymous reader writes "After being in development for more than a decade, GRUB2 was released today as stable. The mailing list announcement covers new features including a standard theme, support for new file-systems, ports to new CPU architectures, new driver coverage, better EFI support, and many other new features that have materialized over the years of development to succeed GRUB Legacy."

Pfttt

[Severus Snape]

They should have declared it stable long ago, when all the major distros have adopted it for release after release it's time to move on. Sure, there must have still been bugs but that's where point releases come in handy.

Re:Pfttt

[Anonymous Coward]

See "stable" shouldn't even mean bug free when you're talking about releases. It's not like you can really guarantee that your software has zero (or even very few) bugs.

"Stable" should mean "We're neither going to add new features nor remove existing ones"... meaning you don't have to worry about compatibility issues... so exactly, yes, point releases. The ones you can feel safe they're not going to break anything that used to work.

Re:

[Severus Snape]

Who said anything about Canonical? Did Canonical ask the GRUB team to declare it stable? I merely mentioned the fact all the major distributions had adopted it long before it was released.

This is it.

[DeTech]

Too bad though Ubuntu won't be using GRUB2

Re:

[Anonymous Coward]

Ubuntu is using grub2 as default since 9.10. https://help.ubuntu.com/community/Grub2 [ubuntu.com]

Re:This is it.

[heypete]

Not for long [slashdot.org], though.

Re:This is it.

[Severus Snape]

What Ubuntu has been referring to as Grub2 was Grub1.9x, a pre-release of Grub2. What the OP means is their dropping it because of legal issues around GPLv3, on Windows 8 approved hardware they won't be able to keep the private signing key, private which would result in their certificates being revoked. http://www.extremetech.com/computing/131628-canonical-explains-decision-to-ditch-grub-2-on-uefi-systems [extremetech.com]

Re:

[Darinbob]

Presumably if we want to use other operating systems we have to change the bios (or whatever they're calling the DRM module) to allow Grub anyway. Or am I missing something that Linux except for Red Hat will now be forbidden? If Grub is not allowed to be a bootloader for this reason than it seems that no general bootloader will ever be allowed.

Re:This is it.

[KiloByte]

Yes, UEFI Secure Boot means precisely that: you can't use any Linux but Red Hat and Ubuntu, official kernels only. Microsoft agreed to sign their official kernels to have more ammunition in the inevitable antitrust suit. A pox on Ubuntu for cooperating here!

GPL3 on Grub works as designed here: it stops any DRM, disallowing unmodifiable bootloaders and kernels.

Re:

[Darinbob]

But won't most Linux users be disabling the secure boot feature anyway? This will just discourage more people from using Linux or BSD which is not good but those existing users will presumably figure out quickly what to do.

Re:This is it.

[SuricouRaven]

Linux has taken years of hard work to get to the point where you can just put a disk in and install it, without having to screw around with the BIOS or other low level stuff. It seems a step backwards to require users go into the firmware config (A scarey place for the newbie!) and change things. Also, there is no assurance that Microsoft will grant users that luxury indefinatly - it's quite possible that they'll change their policy in Windows 10 or 11 to remove that option altogether, as soon as they feel they can get away without another antitrust case.

Re:This is it.

[dgatwood]

GPL3 on Grub works as designed here: it stops any DRM, disallowing unmodifiable bootloaders and kernels.

No, not really. As designed, it was intended to prevent hardware vendors from designing hardware with locked-down Linux installations. In this case, it is trying (unsuccessfully) to prevent enthusiasts from being able to install locked-down Linux on off-the-shelf ARM hardware without breaking their ability to switch back to Windows. The fact that you also won't be able to install non-locked-down Linux on that hardware is a secondary issue. It's a clear case of the GPLv3 acting against the right to tinker solely for reasons of ideological purity—the right to change everything or the right to change nothing.... That's truly backwards in my book.

The fact of the matter is that not enough people care about running Linux to convince manufacturers to push back on Microsoft over the ARM UEFI Secure Boot mandate. There is exactly one way to guarantee the right to tinker, and that is to get people from the geek community elected to governing bodies so that they can propose and pass legislation that mandates that right. Any other strategies are doomed to failure. It doesn't even have to be federal law. If the State of California passed a law saying that all electronic devices purchased using California tax dollars must provide a way for the user to install alternative operating systems without removing the user's ability to run the OS that came with it, Microsoft's attempts at mandating non-disableable UEFI Secure Boot on ARM would go down like a lead balloon even if no other legislature adopted such a provision.

Re:

[tuppe666]

"The fact of the matter is that not enough people care about running Linux to convince manufacturers to push back on Microsoft over the ARM UEFI Secure Boot mandate."

Then these manufactures deserve to die. I have no idea what happens in Dell of this world, but Plan A riding the Microsoft monopoly coattails was over, when Microsoft surprised them surface. Stating we are an "electronics company not a software company" keeping all the high margin early adopter money, with a you can keep the scraps...and pay us a premium for our software which we want more control over.

The Accounts need to be sacked if they think alienating even a small portion of their customers for no fin

Re:

[richlv]

waitwaitwait.
gplv3 requires no lockdown, so user is in charge. an "unnamed" vendor pushes for a partial lockdown, which gplv3 "detects" and refuses to "operate on".

how could you claim that it's acting against the right to tinker ?
you could claim that it's rejecting right to tinker in a sandbox - which seems to be a goal, not an oversight.

Re:This is it.

[dgatwood]

GPLv3 requires unlocked hardware, mandating that if the user is in not in charge, the user is not allowed to use the software. Another software company mandates that all hardware vendors require bootstrap loaders in order to be qualified to run their OS. Now, suddenly there's a whole host of hardware vendors that have to choose whether to take the safe bet and ship a Windows-based OS or completely and probably permanently sever their ties with Microsoft.

When it comes to stomping Linux into the ground, the GPLv3 is Microsoft's wet dream.

you could claim that it's rejecting right to tinker in a sandbox - which seems to be a goal, not an oversight

The problem is that more and more hardware is moving towards signed firmware. This transition is inevitable because the level of malware in computing today is just too high, and the only way to reliably prevent malware is to know with some degree of certainty who wrote a particular piece of code. Within 5-10 years, you will likely be unable to buy commodity hardware that can run unsigned code (except maybe for specialized server boxes). This is inevitable, and isn't something you can change by whining about it.

So your choices are pretty much either to accept that the world is changing and adapt or continue pissing into the wind. Either way, the result will be the same. If you want freedom to tinker, you're going to have to provide an alternative. This means either passing laws to mandate that vendors provide an alternative or coming up with a standard scheme for single-device-specific signing certificates (and shared infrastructure to provide such certificates) that the hardware vendors can all agree to support. Either way, there are several prerequisites:

1. All the Linux vendors must accept that code signing is inevitable.
2. All the Linux vendors must start moving towards adding code signing and verifying capabilities to the standard Linux distributions (assuming they aren't there already—I haven't looked in a while).
3. All the Linux vendors must work together to come up with shared infrastructure to support per-device signatures.

Anything short of that pretty much spells the end of Linux except as an embedded OS and/or specialized server OS on specialized hardware. Whether it happens now or ten years from now is unimportant. That's the direction things are going. Ubuntu et al took the first step in that list, but that step is incompatible with GPLv3 unless and until the remaining two steps are taken.

Re:

[hobarrera]

Lucky for use, the Linux Kernel is licensed under GPLv2.

Re:

[dgatwood]

True, but the whole point of having a locked-down boot loader is to prevent malicious modification to everything, not just the kernel. This will eventually lead to kernel changes that require signed binaries. That will almost inevitably be an eventual requirement for being allowed to sign the kernel. A secure bootstrap loader and kernel don't mean anything if an attacker can exploit a couple of security holes, gain root privileges, and load crap into the kernel after the fact.

Re:This is it.

[Rich0]

GPLv3 requires unlocked hardware, mandating that if the user is in not in charge, the user is not allowed to use the software.

The GPL places no restrictions at all on use. It places restrictions on distribution.

I can stick GPL software on whatever system I want to, even if I lack the ability to later modify it. However, if I sell that system to somebody else, then I've got a legal problem.

As long as GRUB isn't on the system when it is sold, there is no GPL issue. That means that Ubuntu can't sell PCs with GRUB pre-loaded on them if they use secure boot without disclosing the signing key, unless it is possible for the user to modify the secure boot keys (which, by the way, is possible on MS-compliant x86 hardware).

I've got no issues with Ubuntu from being blocked from distributing locked-down PCs that users can't modify. If only the kernel were GPL3 then maybe we wouldn't all be stuck having to root our phones...

Re:

[10101001 10101001]

GPLv3 requires unlocked hardware, mandating that if the user is in not in charge, the user is not allowed to use the software. Another software company mandates that all hardware vendors require bootstrap loaders in order to be qualified to run their OS. Now, suddenly there's a whole host of hardware vendors that have to choose whether to take the safe bet and ship a Windows-based OS or completely and probably permanently sever their ties with Microsoft.

The real question would have to be, why would hardware

Re:

[Microlith]

Despite it's claimed impressive install numbers, no professional people use it

I know you're an AC, but your claim is completely unprovable. It can be readily disproven, though.

Re:

[hobarrera]

At my job, about 50% use OS X, and 50% use Ubuntu on their work PCs. With myself being the only exception to those OS. So I think it's quite safe to say Ubuntu is used in professional enviroments.

Re:

[Zero__Kelvin]

Because you are making the classic case of comparing Apple's to imaginary hardware. The Mac is hardware designed and sold by Apple. Which PC does Microsoft design and sell again? But you show distinctly how great they have gotten at fooling the general public. To this day, people still don't get this basic idea.

Re:

[KiloByte]

Now microsoft is requiring an option for secure boot to be disabled in order for the hardware get a shiny new "Windows compatible" sticker

You get this outright wrong: it is Microsoft who's pushing for "secure boot", and in newer iterations of the standard added a small loophole that on x86 (only), a hardware vendor may add the possibility of disabling "secure boot" and still get the "Windows compatible" sticker (and OEM discounts). They are free to not add that possibility or make it as hard to use as possible, possibly making you lose the warranty as well.

Re:

[cpu6502]

Why on earth does a PC need a "SecureBoot" anyway? It should be able to run anything you desire.

To prevent boot-time rootkit installation

[tepples]

UEFI Secure Boot is designed to prevent a boot-time rootkit from executing. This can be one whose installer an inexperienced desktop PC administrator has unwittingly run, or one whose installer a compromised server process running with administrative privileges has run.

Re:To prevent boot-time rootkit installation

[raap]

No. It is designed to generate a chain of trust from the BIOS (UEFI) up to the operating system including drivers. So if you change anything in this chain, DRM-plagued media will refuse to play! It's all about the ability to play content withot the user being able to grab that content or do anything else with it. If it would be about preventing root kits, then the master keys could be in the hand of the user.

Custom mode

[tepples]

If it would be about preventing root kits, then the master keys could be in the hand of the user.

"Custom mode" on x86 puts the keys firmly in the user's hands. So on x86 at least, it is about rootkits.

Re:

[raap]

This might be true for the KEKs (key exchange keys). But the PK (platform key) will be already set up (and controlled) by the hardware manufacturer if I understand the system correctly. With UEFI you do not own your hardware anymore.

Re:

[Zero__Kelvin]

The fact that you wrote the phrase "on x86 at least" makes it clear that it is not about root kits. They would like to say ARM and x86 Always ON, but they know that will never fly so they are going to start here, and switch to x86 Always ON in a year or three. Manufacturers will just start shipping a few models here and there, and then more and more, until it is impossible to find a non-TCP/DRMed machine.

Antitrustworthy Computing

[tepples]

I don't see how an always-on, always-Microsoft configuration for Secure Boot would pass muster with a European Union that, unlike the US DOJ, actually has the testicular fortitude to fine Microsoft for its anticompetitive ways.

Re:

[SpaceLifeForm]

Microsoft does not care about fines as long as they are within the acceptable 'cost of doing business'. In other words, they will sacrifice billions now with the goal of running the world decades from now, when they can tax everyone to pure slavery/near death. This is how the corrupted by money brain operates. Never mind that is actually makes no long term sense. In a corrupted by money brain, greed overrules everything. Nothing else matters. It is an addiction worse than any chemical substance.

Re:

[SuricouRaven]

Easy: All they need to do is accept that they'll get a billion-dollar fine in ten years for their anticompetative actions, but that the multi-billion-dollar profits easily justify the cost of the fine.

Re:

[Rich0]

Actually, what you're describing has been available in x86 PCs for years - remote attestation and such. Nobody really uses it, but it is already available.

Secure boot blocks unsigned code from running. The existing technologies allow code to determine if untrusted code has been run before.

If MS just enabled support for it in their bootloaders they could detect MBR rootkits already. Each stage in the boot process registers itself with the TPM module, and any later stage can find out what came before.

You c

Re:

[SpaceLifeForm]

I have yet to determine which is worse for me, booting a machine with a rootkit, or booting Windows. Can you explain how one is better than the other? Why should I trust one over the other?

Re:

[tepples]

Your employer is more likely to have a use for an apparently clean machine with Windows than a machine with nasty malware. So are PC gamers.

Re:

[hobarrera]

Because user's can't be trusted to use their own PCs as they will. It's unsafe for content providers.

Re:

[Zero__Kelvin]

Can you think of a better way to control their monopoly at this point than this kind of Hail Mary power grab?

Re:

[SuricouRaven]

Official reason: Secureboot was an Intel technology designed to defend against low-level rootkits which load before the OS and are thus able to very evade detection.

Suspected reason: Secureboot imposes a significent hurdle to OS vendors that would be but a minor inconvenince for a company the size of Microsoft, but a crippling disadvantage for anyone else. Microsoft saw this aspect of SecureBoot, and decided to mandate the technology.

Re:

[Lennie]

Yes, but they demand UEFI for ARM and with no off switch (!)

Re:

[hobarrera]

ARM is mostly portable devices, and MS isn't the dominant player there, so it's not so easy for them to pull this off.

ARM twisting

[SpaceLifeForm]

Exactly. And I believe the ARM hardware vendors are balking at this 'requirement' called Secure Boot, the entire premise of which is a malware problem that was created by MS in the first place. Since the hardware guys are fighting this, MS came out with their vapour product called Surface, it an attempt to coerce them into accepting the bribe^W marketing money. It is all about killing your freedom to tinker on hardware you bought.

Re:

[SuricouRaven]

For now. Microsoft has a history of dirty business tactics, so it's quite possible they'll remove that option at some future date. They already have on ARM: Part of the OEM terms for WinRT, the ARM version, requires it only be installed on locked-down hardware incapable of booting any other OS.

Re:

[Anonymous Coward]

That's what makes it doubly annoying. I started reading it that way and then it stopped making sense right after the next comma.

Re:

[dgatwood]

Either way, it stops making sense after the next comma (splice). It should be a semicolon. And the comma after that one shouldn't be there at all.

Sincerely,
The Helpful Grammarian

Citation needed

[k(wi)r(kipedia)]

Either way, it stops making sense after the next comma (splice). It should be a semicolon. And the comma after that one shouldn't be there at all.

Sincerely,

The Helpful Grammarian

It would be (even) more helpful if you quoted the part where the (supposed) grammatical error occured.

Re:

[SpooForBrains]

Orig: "What the OP means is their(0) dropping it because of legal issues around GPLv3,(1) on Windows 8 approved hardware they won't be able to keep the private signing key,(2) private which would result in their certificates being revoked."

(0) debatably incorrect use of "their" (possessive) vs "they're" (contraction). Can be argued to be intended but it probably wasn't

(1) comma splice - two sentences that can stand alone joined together incorrectly. The correct punctuation here would be a semicolon

(2) this

LILO

[manoweb]

I still like LILO better.

Re:LILO

[GNULinuxGuy]

I might agree with you had GRUB ever failed me. :)

Yes

[Anonymous Coward]

I too love to have no functionality in my bootloader, and no recourse but to pull out a recovery drive/disc/etc if even the slightest thing goes wrong with boot configuration. Let's all boot like it was 1985! MS-DOS was advanced enough for anyone.

Re:LILO

[evilviper]

I still like LILO better.

I agree. LILO has a simplicity that GRUB lack, and LILO beat-out GRUB for GPT partition table support for a long, long, long, long time... ie. GRUB v1 doesn't officially have GPT support (it's always 3rd party patches) and GRUB2 is just NOW becoming stable!

But LILO hasn't seen much development or interest. If something is going to take over for GRUB, I'd expect it would be extlinux: http://www.syslinux.org/wiki/index.php/EXTLINUX [syslinux.org]

Besides getting active development, it's also about as flexible as grub, and completely syntax-compatible with syslinux / isolinux / pxelinux, and all the other bootloaders any pros are going to need to figure out how to configure at some point in their careers... Replacing GRUB with extlinux gets all our bootloaders the same config syntax, without sacrificing anything but GRUB's eccentricities.

Re:

[Anonymous Coward]

"But LILO hasn't seen much development or interest."

Debian has assumed the maintenance for LILO:

http://lilo.alioth.debian.org/

Re:LILO

[omnichad]

Ah, yes - LILO. The friendly bootloader with helpful error messages like L or LI.

Re:LILO

[Anonymous Coward]

yeah because grub's error reporting is awesome

OH GOD WHAT HAPPENED HERE IS A SHELL
type help for more
> help

boot dontboot squeak ripple clown jump error what no boot-alt boot-queue list-devices list-devices-differently help

>

Re:

[Rich0]

I just wish that the command set included the ability to print its config file. 95% of the time I struggle to remember what the full boot line was, and I don't mind guessing at devices when they somehow change if I didn't have to guess at everything else.

Re:

[yarbo]

When your boot menu comes up, hit e to enter the faulty boot entry. You can then modify the line one character at a time.
http://www.gnu.org/software/grub/manual/legacy/Menu-interface.html#Menu-interface [gnu.org]

Re:

[Rich0]

Sure, and while I'm doing this I have no access to any of the other grub command options...

Got questions re: GRUB config (vs. LILO)

[KWTm]

I want to sneak in a question about GRUB to which I have tried long to find an answer, in vain:
GRUB can apparently have its settings changed just be editing a configuration file, unlike LILO which needs to be reinstalled with the configuration settings you want. My question is: - where are the Grub settings stored?

If it's in one of the partitions, then aren't you screwed if that partition is deleted? Suppose you have 3 partitions named Linux1, Linux2, Linux3 and you use GRUB to boot between them. If the

Re:

[Rich0]

The grub config file and stage2 file can be on any partition. When you run grub-install the bootloader is pointed at the one that contains the file. If you move it or change the filesystem type of that partition then your system won't boot unless you re-install the bootloader first.

If you wipe out random partitions from time to time you're probably best off dedicating one for grub - it need not be large. With grub1 this is often necessary if you use non-supported features like LVM or raid striping.

The co

Re:

[Rich0]

I'll have to reboot my system. As far as I can tell it doesn't have a cat command - v0.97. Maybe I just missed it.

Re:

[drinkypoo]

yeah because grub's error reporting is awesome

OH GOD WHAT HAPPENED HERE IS A SHELL
type help for more
> help

boot dontboot squeak ripple clown jump error what no boot-alt boot-queue list-devices list-devices-differently help

>

Best anonymous comment ever. EVER, I say.

LILO? LOL!

[Zero__Kelvin]

You're forgetting about the times it just laughs at you with an LOL*

* Can actually happen if byte-order endian issues rear their lovely head

Re:

[broken_chaos]

I've actually been using extlinux (the ext2/3/4/btrfs version of syslinux) lately, and find it to be amazing. No issues with running it on a 64-bit native system without IA-32 emulation, which was a stumbling block for getting either grub or lilo working on a system that doesn't need 32-bit at all. Maybe grub2's better about that, but I've not tried it -- I've heard horror stories about grub2's configuration mess.

finally!

[manicpop]

I'm glad GRUB2 is finally finished! Now we can finally move on to scrapping the entire thing and spending years on GRUB3.

The Hurd comes next?

[k(wi)r(kipedia)]

Or we could be waiting for the Hurd to be officially released, since the GNU folks appear to have finished all the other pieces that would make for a pure GNU sans (rather than slash) Linux OS.

Does it RAID?

[physburn]

Does it install correctly on /dev/mapper RAID drives?

Re:

[bastafidli]

Not sure if this is problem of distro or grub, but once installed then it works on /dev/mapper RAID drives just fine including failover. But I still believe the setup is so complicated that it easily result in unbootable system

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/997414 [launchpad.net]

Re:

[phorm]

I've used it on machines with RAID-1 (software)+LVM and not had any issues.

Re:

[robmv]

Me too, but that worked because RAID 1 is just a mirror without stripping and /boot partition is only used for read. I don't know if you can use grub now for example on a small server using RAID 5 without the need to put /boot on RAID 1

Re:

[rrohbeck]

Yes it does but it's arguable if it makes any sense.
I prefer two completely separate boot partitions. That way I can still boot from the second drive if I mess up /boot.
If everything works I can mount /boot2, copy everything over and umount /boot2, manually or in /etc/rc.local.

Just in time to say good-bye

[Anonymous Coward]

The amusing thing about this is, with secure boot coming out GRUB2 will probably be tossed out in favour of a boot loader with a more liberal license. Ubuntu has already stated they are dropping GRUB2, I imagine other distros will follow in the next few years.

Re:

[Anonymous Coward]

Not much of a loss as far as I'm concerned. I could never get used to Grub2. It has plenty of nifty new features I'm sure but is a pain to work with compared to the previous version. I don't have a single system using it.

Re:Just in time to say good-bye

[10101001 10101001]

The amusing thing about this is, with secure boot coming out GRUB2 will probably be tossed out in favour of a boot loader with a more liberal license.

Yes, the "amusing thing"* that people would want to have as much possible information about their boot system, which is precisely where things like MBR trojans or what will possible be the new "secure boot" versions. And that more "liberal license" than the GPLv3 is only more "liberal" for the OEMs/MS/Vendors in that it gives them more freedom to say while being less liberal in what a user can do.

Ubuntu has already stated they are dropping GRUB2, I imagine other distros will follow in the next few years.

I really hope they don't. I hope they are as vocal and as loud as possible. You know why? Because I can only see "Secure Boot" having flaws in it and being used by malware. I can only see "Secure Boot" turning into "Secure ID" or some other BS and people becoming angry when it backfires. I really hope some distros stick to their guns even if they appear to be Richard Stallman-like crazy because the truth is, they're the only sane ones and the only way to prove that in the long-term is keep arguing for sanity, not kowtow to the craziness just because it'll point out you're different and make people realize the absurdity of the "Secure Boot" option. Yes, if even after all that, computers still keep coming out with TPM and it becomes as far as mandated for internet access, I can see even the die-hards buying a TPM machine. They'll just tunnel through it with their own VPN and try to continue to use their uninfected machines. In the end, I just hope TPM as a whole dies. The technology could be used for so many good things. But, the two powers involved who keep pushing TPM--government (legislative and executive branches, actually) and corpratists--are hardly the groups I'd put any long-term faith in, let alone short-term faith, when it comes to considerations of freedom or liberty at the individual level.

*Yet again, another one of Richard Stallman's speculations holds out as coming true with TPM and is precisely one of the reasons why the GPLv3 software requires the encryption keys used for execution. The fact that some distributions are so quick to brush aside the clear implications of having to avoid GPLv3 code over precisely that issue and to just consider some of Stallman's speculations on the outcome...is just stupid. And this comes with the point that TPM isn't inherently bad; it's just that by nearly every implementation, it doesn't work to foremost given the actual user the keys and the control but instead the hardware/software producers the keys and the control.

Re:

[Rich0]

The only distros that are going to have trouble with secure boot and GPLv3 are those which distribute preinstalled OSes. How many distros even do that? Sure, the big commercial ones might, but 95% of the distros out there are installed from CDs, and as long as they don't conspire with hardware vendors to have their distros signed by some pre-trusted key then they're fine.

Re:

[Zero__Kelvin]

No. That's pretty much the point. There are millions of computer buyers out there, and about 10000 of us understand this issue and its implications. You need much larger numbers, or a much greater leverage, for a boycott to work.

Crickets?

[TheSkepticalOptimist]

Somehow when I read this I just heard crickets in the background.

GRUB2many troubles

[sl4shd0rk]

Quite frankly, I've had enough problems on the past few versions of Ubuntu 11-12 that I cringe every time there is a GRUB2 update. I've had software RAID systems refuse to boot (with GPT partitions), and systems with slash on LVM refuse to boot after GRUB2 updates.

The necessity for GRUB2, from what I understand, grew out of the "want" for a VGA video mode at boot so we could have an image on the boot menu (and other fancy things). The trouble I've gone through trying to keep it working though just isn't worth the eye candy IMO.

Re:

[Anonymous Coward]

Kernel upgrades required updating the MBR with Lilo, which required running Lilo to perform the update (as root/sudo) (not that much of a burden, as you'd have to be root to update the kernel too. It was just inelegant.). Grub 1 ("legacy") did not require running a command, but rather could be updated by updating the /boot/menu.lst file, which is a more elegant/unixy and generally easier to understand.

Grub 2 however, breaks this feature, and requires a command to be executed after updating

Re:

[sylvandb]

LILO never gave me a commandline when it could not find the next stage. Grub and Grub2 both give me a commandline and let me fix the problem without a recovery disk.

Does LILO load disk images into a ramdisk and simulate a drive? Grub2 does.

Does LILO boot ISO files discovered at boot time by scanning a directory? Grub2 does.

I resisted grub2 for a few years. but I've been using a pre-release version for a few years now and it works fine. You just need to update your skills a decade or so.

Re:

[gl4ss]

L 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

and time to pull out the floppy. I guess those were good times.

Isn't Ubuntu leaving grub behind?

[phayes]

ISTR that Ubunto has decided to abandon Grub to be able to run on new Win8 EFI PCs that will only boot from MS signed bootloaders. Does this announcement change any of that or is Grub2 to be a tool for those not using Win8 compatible PCs?

Re:

[Microlith]

For non-EFI PCs, PCs with EFI that don't support secure boot, or PCs with secure boot turned off.

Slightly OT, anyone still dual-booting?

[GodfatherofSoul]

And why? I started using VMWare for Linux installs and I haven't encountered an instance where I needed dual-booting. Not implying that that's the only use for a boot loader.

Re:

[Microlith]

Indeed, I have never dual booted. But instead, I give Linux full hardware instead of suggesting that "put Linux in a VM, run Windows" is a solution.

Re:

[WasteOfAmmo]

Yes, about 150 PCs running in Computer Science Labs. We have looked at running hyper visors with VMs but there simply is not a good solution available for a lab environment. To many issues with switching between OSs, ensuring both VMs are logged out when the user walks away, etc.

At one point I was seriously looking forward to GRUB2 being adopted by more distros as it supports retrieving the boot configuration over the network. This would easily allow simply remote configuration of which OS the machines w

Re:

[hobarrera]

wine [winehq.org] works fine with most games. I've played several high-demanding 2012 games with no issues, including Mass Effect 3, the day it was release. Haven't booted windows in years and that hasn't kept me from gaming. I can even play some really old games I hear don't work in new windows versions (like Max Payne).

Supports FreeDOS (and Windows, Mac)

[Jim Hall]

In the announcement [gnu.org] they said GRUB 2.00 supports FreeDOS [freedos.org] as a boot protocol. I'll have to test that out to see what they mean - it's not that hard to boot DOS. But I am thrilled that the GRUB developers recognized us with explicit support. And of course, all the extra technical details they've added in the 2.00 release. Thanks!

Also, I saw that GRUB 2.00 supports a few other "alternative" operating systems, including Ntldr/bootmgr (to load Windows bootloader) and Darwin 11 (Mac OS X Lion.)

Original Grub is still better

[Anonymous Coward]

Rarely have I seen a bigger pile of shit than the configuration for grub 2. The config for grub 1 was so simple... and it *almost* made sense. They should have dropped the hurd device naming, but kept the grub.conf format we all know and love. This was another bit of software someone just had to rewrite. Now you have to generate a new configuration after any change.

Only thing I hate worse is systemd.

Re:

[xororand]

You can use GRUB2 with a single static cfg file just as well.

Re:

[Drinking Bleach]

One of GRUB 2.00's features over the previous 1.99 release is support for GRUB Legacy configuration files. It's recommended that you upgrade to the newer format, but you don't absolutely need to.

ISO loopback mounting

[xororand]

GRUB2 is cabable of mounting ISO images and loading contained kernels.

That means you can save unmodified liveCD ISO images on a boot partition with GRUB2 and load them directly.
This is not a CD or DVD emulator but simply loopback access, as if you'd mount it in Linux with mount -o loop foo.iso /bar.

If you want to retain the individual boot menus of your liveCDs, you need to recreate them with GRUB2 syntax.

Fortunately some, albeit very few, live CDs ship with a loopback.cfg for this purpose nowadays.
Off the top of my head, new Ubuntu releases and GRML do so. GRML was one of the first.

http://michael-prokop.at/blog/2011/01/07/booting-iso-images-from-within-grub2/ [michael-prokop.at]
http://www.supergrubdisk.org/wiki/Loopback.cfg [supergrubdisk.org]
http://grml.org/ [grml.org]

Re:

[heson]

Wow, a grub2 improvement over grub1 I would actually use, I bet its is buggy as hell...

/grub2 hater

Is it usable yet?

[Trogre]

GRUB2 has a very nice feature set, but they have made a complete and total dogs breakfast of the configuration system. Now one needs to edit poorly-documented shell scripts and run an update script to 'compile' a new GRUB configuration file, or have it hosed at the next kernel update.

Of the three bootloaders I have spent significant time with, LILO, GRUB 1 (0.99 or whatever) and GRUB2, the latter is without doubt by far the worst to configure if you want anything other than the defaults.

GPLv3 violation

[DrYak]

To boot in non secure mode:
- yup, GRUB2 does support EFI.

To boot in secure-mode:
- technically yes, practically not so easy.
To boot in secure-mode, GRUB2 need to be signed.
As per GPLv3, GRUB2 needs to publish the private key, so any one could rebuilt his/her very own version of GRUB2, sign it, and replace the previous one.
But due to the way microsoft license its keys and signing, GRUB won't be allowed to publish said key, thus can't abid GPLv3. Thus no version of GRUB2 signed with microsoft key.

Then two other possibilities remain:
- Canonical will get efilinux signed with microsoft keys. So GRUB2 has to be made bootable from efillinux (efilinux is rather primitive, it just loads a kernel from a set collection of blocks from the device and run it. It shouldn't be too much difficult to have efilinux load and execute a GRUB2's "stage 1.5" or "stage 2").
Thus efilinux is the part that needs to be signed with microsoft's key (and efilinux's license makes it possible. Although that also means that you won't be able to hack it).

- Canonical is trying to setup its own scheme of signing, a much more open-source friendly way. And trying to get motherboard manufacturer to include canonical's signing keys into the mobo's secure boot.
On motherboards that feature also Canonical's key, one could use a GRUB2 binary signed with canonical's key. As per GPLv3: canonical needs to provide some way so an end user can sign his/her new custom version of GRUB2 to replace the original own.

Now the funny part:
- GRUB2 can load coreboot (an opensource firmware) payloads, so it could also load SeaBIOS (a legacy BIOS implementation as a coreboot payload).
- GRUB2 can also load windows XP's boot loader.
So if any of the above is possible (either chainloading efilinux to grub2, or signing grub2 in a gplv3 compatible way). That means that grub2 could be used to boot windows XP on secure-boot hardware. (with seabios providing the legacy bios compatibility, and windows XP's ntldfr being loaded from grub2).

Re:

[Talisein]

As per GPLv3, GRUB2 needs to publish the private key

I'm pretty sure you're wrong about this.

IIRC GPLv3 requires (if you are 'secure booting') you to be able to load in your own certificate that subsequent signatures can be checked against. That doesn't mean Microsoft has to publish their private key in order for computers to be distributed with a GPLv3 licensed GRUB2. Microsoft is (for now) requiring that PC manufacturers that ship Windows allow secure boot to be disable AND that there is some (though probably obscure and poorly documented) way to load in yo

Re:

[bill_mcgonigle]

As per GPLv3: canonical needs to provide some way so an end user can sign his/her new custom version of GRUB2 to replace the original own.

Well, this makes the most sense. Boot once with a GPLv2 bootloader, to (bootstrap the bootstrapping?) and then sign and install with the user's keys. This will be the most trustworthy approach, as long as the user keeps his system secure (imagining the rootkit that finds the user keys, suckers the passphrase out of the user, and installs its own bootloader - remote but

Re:

[Rich0]

Why would you need a custom grub on top of a standard signed one? You sign the grub bootloader and install it. You add your key to the EFI firmware. You point that grub at whatever you want to boot, and lock it down as much or as little as you like.

You only need one bootloader. The issue isn't that grub doesn't work - it is just that it won't be signed by any key recognized by your firmware. The easiest solution to that is to just replace the key in your firmware, and if you want to dual-boot windows r

Re:

[spongman]

so a rootkit dropper on a secure uefi machine would just have to find & replace the post-efilinux part? why not just turn secure boot off?

Re:

[bws111]

No, that is not true. An analogy would be a notary public. You take a document to the notary, with some ID, and sign the document in front of them. They put their seal on it and say certify that it was you who signed the document. They don't care at all about what the document says, and they don't state in any way that the contents of the document are true, just that you signed it.

If you were to send a boot loader to Canonical for signing, all they are doing is saying 'Canonical says this bootloader is

Re:

[bws111]

Have you used secure boot? I have (IBM xSeries servers) and that is pretty much what they do.

I don't know what you are talking about with 'very tightly controlled keys'. The only keys that need to be tightly controlled are the ones used to sign the code, because if they are not tightly controlled you can't trust that the claimed signer is actually who signed the code. Of course, for signing to have any meaning you must be able to verify the signature so you must have a matching public key, but those ar

Re:

[Drinking Bleach]

use UUIDs and it can.