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."

Comments

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:Pfttt

[Anonymous Coward]

I don't agree. Your argument appears to have no real meaning. "It's not like you can really guarantee that your software has zero (or even very few) bugs." does not provide any useful argument. The human perception of bug probability heuristic (based upon bug-report and major changes rate, etc) is a completely valid way of measuring stability, even if it is not a 'guarantee'.

Re:Pfttt

[Anonymous Coward]

So, stable should mean that it is stable besides what is unstable and that unstable pieces will be fixed without regression?

hmm....

Re:Pfttt

[AbominousSalad]

I am categorically opposed to upstream developers doing anything just because Canonical said so.

Re:Pfttt

[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:This is it.

[Anonymous Coward]

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

Re:This is it.

[heypete]

Not for long, 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

Re:This is it.

[Anonymous Coward]

THEY ARE.
Kill yourself.

Re:This is it.

[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.

[Anonymous Coward]

His sentence still makes sense as "their", though it's a bit more colloquial in phrasing since it leaves out "of"; it makes sense as "their dropping of it because"...
You first.

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:This is it.

[cpu6502]

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

Re:This is it.

[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:This is it.

[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:This is it.

[AvitarX]

I'm pretty sure that I read at least in x86 MS will force vendors to allow secure-boot to be turned off (but then not boot Windows? killing dual boot?).

I don't mind secure boot, I do wish that they would let me install my own keys, protected with a physical switch on the MB, so that i could sign whatever I wanted, and have the protection offered by secure boot.

Re:This is it.

[Anonymous Coward]

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

To more easily prevent it from running things I don't desire.

OK, so me, personally I'm only tangentially worried, but this just isn't about me.

Re:This is it.

[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

Re:This is it.

[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.

[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:This is it.

[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 financial gain is a good move.

The Management need to be sacked for being getting in so deep with Microsoft...and kicked on there way out for making the same mistake post Surface.

These companies need to make a plan and that needs to involve Android, Tizen, Debian, WebOS or their own software stack.

They need to commit to breaking the monopoly they have propped up, because they are not going to be part of the next part of that fight.

Re:This is it.

[Anonymous Coward]

No, the GPLv3 doesn't stop DRM. What it does is prevent people from using the software licensed under the GPLv3 when people need to deal with DRM. In a world with secure boot GRUB2 (under the GPLv3) becomes virtually useless.

Re:This is it.

[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.

[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:This is it.

[Lennie]

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

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:This is it.

[hobarrera]

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

Re:This is it.

[hobarrera]

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

Re:This is it.

[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.

Re:This is it.

[Anonymous Coward]

Microsoft agreed to sign their official kernels to have more ammunition in the inevitable antitrust suit. A pox on Ubuntu for cooperating here!

Wait, why would MS get sued for doing something Apple has been doing for decades?

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:This is it.

[Anonymous Coward]

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

Lucky for us there is BSD.

Re:This is it.

[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:This is it.

[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:This is it.

[dgatwood]

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

That may be a moot point. If no one is allowed to distribute a version of the software compiled in such a way that will run on the hardware, no one can run it on the hardware. Whether that would be the case depends on how you interpret the GPL.

Re:This is it.

[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.

[Anonymous Coward]

You're permitted to distribute the GPL3 software when you also permit users the same rights as was passed to you. It's not good to restrict your downstream users when freedom has been granted to you.

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.

[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:This is it.

[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:This is it.

[Pi1grim]

They will be using new bootloader only on the systems, that will not allow disabling secure boot (if these will come into existance). On all others they will be using good old GRUB2 (systems that will allow disabling secure boot or uploading your own keys). But why bother reading the article, when you can express your opinion about it, right?

Re:This is it.

[Pi1grim]

You, sir, are as misinformed, as it gets. UEFI Secure Boot means that bootloader has to be signed. Now microsoft is requiring an option for secure boot to be disabled in order for the hardware get a shiny new "Windows compatible" sticker, Canonical, in addition to that requires an option for users to be able to upload their own keys, although Canonical has less leverage on hardware manufacturers, but this is still better then you whining on slashdot without even reading about the problem in the first place.
And, while Fedora will have a bootloader signed by Microsoft, Ubuntu will pack a number of options: on systems without or a disabled Secure Boot it will install Grub2, same story in case of secure boot with your own keys (you will have to sign the GRUB2 yourself, though). On systems with enabled secure boot with only Microsoft key working — it will install a small signed bootloader.

Re:This is it.

[Anonymous Coward]

that doesn't preclude secureboot,
in order to be able to run anything you desire you simply need to be the one in control of the keyring for trusted bits

I'd very much like it if I could:
1) add my own key to that keyring
2) kick out all the default keys most definately including MS's keyring from
3) then easily sign grub and my kernel with my own key

That gives me both the safetey and the control, the problem atm is that it looks like we won't get step 2, which means you need to trust a huge bureacracy to never sign the wrong thing, which nullifies the security aspect from my point of view

Re:This is it.

[Anonymous Coward]

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.

One set of restrictions is intended to safeguard the right to tinker, the other set of restrictions is intended to restrict the computer to running supplier approved software. Which one was acting against the right to tinker, again?

Re:This is it.

[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:This is it.

[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 vendors, after seeing that MS is leading down the path of making its own hardware and presumably working to cut them out of the market when it comes to Windows hardware, going out of its way to support Secure Boot or any other MS-controlled authorization scheme? The simple truth is, the major point of the GPLv3, beyond preventing its use on locked down hardware, is to be a red flag that something is serious fucked up in the situation for the user.

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

Right... Because it's not like MS could deny a signing key for FreeBSD. Oh, right, the GPLv3 has really nothing to do with it except symbolically.

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.

Yeah. I mean, look how ActiveX never had malware issues. And hell, we all know how much SSL was such a great success because of certificates. Meanwhile, Windows is such a bastion of security because it goes beyond signing keys and can outright block all system-level access. Please tell me to stop whenever the bullshit gets thick enough for you?

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.

This is probably inevitable for the same reason most x86 CPUs are x86_64 and VM/dual core is so common: the extra silicon space is so relatively small compared to the potential "added feature" selling factor to users. The real question isn't if TPM-like modules will be included any more than whether Pentium3s had unique serial numbers built in. The real question is whether it'll be forced on the user such that only signed code will run--or more precisely, the main boot chain since jailbreaking seems a given. It's really hard for me to imagine that will work out precisely because it will be shown to be such a futile effort via malware prevention and people will bitch about it enough to demand a BIOS option to turn it off. So, yea, maybe for Windows it will be inevitable anyways, but that doesn't mean people won't be able to chose Linux, FreeBSD, etc to avoid the clusterfuck it's likely to be.

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.

Well, the former is unlikely just because it seems in direct contradiction to the point of the DMCA. Meanwhile, the latter won't work because again it seems in direct contradiction to the DMCA.

Re:This is it.

[Anonymous Coward]

they will be using good old GRUB2

GRUB2: fresh out and already "good old" :-) (I know, I know, stable enough to become 2.0 since long ago)

Win8 Hardware support?

[Anonymous Coward]

But, can it boot on Windows 8 approved hardware?

LILO

[manoweb]

I still like LILO better.

Re:LILO

[GNULinuxGuy]

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

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

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:LILO

[Anonymous Coward]

Back when SCSI was a thing, I never saw GRUB work properly on a mixed system. Supposedly it was designed for 'broken' BIOSs, and would second-guess the boot order presented by working ones. Some vendors even had a "Linux" option in their BIOS which existed solely to fake-out GRUB. I used to curse the "grub shell", but haven't needed that type of hardware for a long while now.

Re:LILO

[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]

You forgot LIL.

It's pretty obvious that these aren't error messages at all, it simply prints LILO character-by-character every step of the way. When there's an error it just stops so you can see (approximately) where.

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:LILO

[Ant P.]

If only ELILO was anywhere near as reliable... :(

Re:LILO

[Smask]

Bah! Boot into MS-DOS and use CONFIG.SYS and AUTOEXEC.BAT to run LOADLIN.COM

Re:LILO

[schmatzler]

You made my day :D

Re:LILO

[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:LILO

[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.

Re:LILO

[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

Re:LILO

[galanom]

LI LI LI LI LI LI LI LI (x1000 times)

Please debug this!

Re:LILO

[galanom]

> help linux
Loads a Linux kernel. Usage "linux /boot/kernel.bin". Have a nice day!

sounds easy to me

Re:LILO

[Anonymous Coward]

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

That's the combination on my luggage, you insensitive clod!

Re:LILO

[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.

Re:LILO

[Rich0]

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

Re:LILO

[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.

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.

Re:finally!

[Anonymous Coward]

A decade even.

Re:finally!

[El_Isma]

What? A decade? Why are you in such a rush?

Does it RAID?

[physburn]

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

Re:Does it RAID?

[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

Re:Does it RAID?

[phorm]

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

Re:Does it RAID?

[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:Does it RAID?

[phorm]

Good question. I've never really had a reason to put /boot on the RAID-5, so as you've said I always made it RAID-1.
Since it doesn't get written (or even read, really) that often that should work for most people though.

Re:Does it RAID?

[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:Just in time to say good-bye

[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:Just in time to say good-bye

[Anonymous Coward]

lilo forever narf

Re:Just in time to say good-bye

[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:Just in time to say good-bye

[Anonymous Coward]

Dude, you're a bit confused and paranoid. Actually, a lot confused and paranoid.

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.

If you want as much information as possible about Secure Boot, the information is out there. It's not a secret how it works. Your grammar is so fractured I'm not sure what you're saying with that last part, but the only way you're going to be able to have a "MBR trojan" or similar is one of four scenarios:

1. You disable it. (yes, this will be possible in x86 computers)
2. Private keys used to sign bootcode get leaked to malware authors
3. Someone finds a method of breaking strong encryption
4. The computer's firmware has a really stupid bug permitting some kind of exploit

#3 and #4 are unlikely to happen in the real world, especially #3 (and if that happens we'll have bigger things to worry about than whether our individual personal computers have been compromised). 2, hopefully not very likely.

Because I can only see "Secure Boot" having flaws in it and being used by malware.

We should take what you "see" as a good prediction of the future why? You don't seem to have put any effort into learning anything real about these technologies you're whining about.

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.

I hate to break it to you Mr. Tinfoil Hat Man who thinks TPM is coming to eat our brains, but UEFI Secure Boot doesn't even require a TPM. Also nobody but you is talking about requiring a TPM to access the internet, that's a paranoid fantasy. You're funny (in the way that the timecube guy was funny).

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.

TPMs never did the kinds of things you're paranoid about, and can't. They're just little peripheral chips which add some crypto functionality and secure key storage to a computer. The only way to big-brotherize your computer using a TPM is to rewrite the OS to do the big-brotherization itself. A TPM can be used to make that big-brotherization harder to crack, but not much else.

See, it turns out that the main point of a TPM is just to make it difficult to conduct a certain class of attacks on crypto systems. For example, if you store keys in a TPM's shielded on-chip memory and use its decryption engine, it's supposed to be very difficult to use those fancy power draw side-channel attacks you read about in security papers. They're even intended to provide some protection against crazy shit like decapping the TPM chip and probing its circuits to extract any stored keys.

In other words TPMs were actually designed to help secure data against very resourceful attackers who steal a computer or storage device which contains encrypted data. They're for people who are (a) as paranoid as you but also (b) a lot smarter about what to be paranoid about and how to go about responding to it. That's why government agencies and large corporations are the primary market for laptops with TPM chips -- they use them to help prevent data leaks through lost hardware.

(If you have any financial data at a fortune 500 corporation, you should bloody well hope their IT department knows how to enforce an intelligent TPM policy, so there's reduced risk of all your vital data getting

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:GRUB2many troubles

[AvitarX]

I remember kernel upgrades requiring updating Lilo also.

Of course, that's all automated now (the Debian make a kernel a deb thingy), that i doubt the accidental death is not so likely anymore.

Re:GRUB2many troubles

[Anonymous Coward]

LILO could do everything GRUB could do, except for change configurations at runtime, rather than having to change a config file.

Re:GRUB2many troubles

[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 the kernel (to convert the updated kernel list in /etc/grub/ into the required /boot/menu.lst file). This removes one of Grubs features that they used be so excited about.
 
  Personally, I don't use Grub 2 because 1) it didn't detect my triple boot properly (it would detect Ubuntu, but not Fedora or Windows) and 2) when I tried to fix it by hand (I'd already been fixing the configuration for Fedora by hand for some time) the syntax and files had changed so much, NOTHING I had learned previously seemed to be applicable. Near as I could tell, I was supposed to write some shell script which would produce the proper syntax, so that the auto detect would work. I switched to Lilo, which has since worked very well, since I can write a configuration file, run a command, and know that my computer will provide a menu to select my operating system. (although I've found the release of EXTLINUX intriguing, and may switch again in the near future.)

Re:GRUB2many troubles

[Exrio]

No offense but, did you check that os-prober was actually installed? That one got me once in Debian. I've never seen autodetection fail other than that time os-prober was somehow not installed.

Re:GRUB2many troubles

[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:GRUB2many troubles

[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:Isn't Ubuntu leaving grub behind?

[Microlith]

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

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.

BURG

[Anonymous Coward]

I prefer BURG. It blows GRUB's theming capabilities out of the water. With GRUB 2, the best I could do was get the tiny text normally bunched together in the top left corner of the screen to be not tiny, at least until the next kernel update, after messing around in text files for who knows how long. BURG is something else. It's got actual themes that actually looks great, and it's dead easy to configure too.

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:GPLv3 violation

[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 your own certificate that booting kernels need to be verified against.

Re:GPLv3 violation

[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 possible).

People who don't care at all about that could continue to use the GPLv2 bootloader.

Re:GPLv3 violation

[cryptizard]

Either you would have to have your own custom grub that runs on top of a standard, signed grub or you are completely circumventing secure boot which would ruin the whole thing for everybody.

Re:GPLv3 violation

[cryptizard]

That seems like a horrible solution. As soon as Canonical starts signing things for people, they take on a tremendous amount of responsibility. All it takes is them signing ONE potentially malicious boot loader (doesn't even have to be that malicious, just something that silently boots unsigned kernels) and the whole secure boot thing is ruined for everyone everywhere. It is crazy how narrow a precipice this all rests on. As much as I hate to say it, I don't see an easy way out of this situation besides Microsoft highly restricting signing (like they are doing) and letting people install their own root certificates (which would be a headache, even for moderately technical people).

Re:GPLv3 violation

[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 from cryptlizard'. Nothing says anyone else has to trust cryptlizard.

So, let's say I get Canonical to sign my malicious boot loader, and it gets installed on your machine. The first thing that ought to happen is that UEFI notices that the signature and/or signer of the bootloader is not that same as the last time it booted, and puts up a screen saying "The last time you booted 'Windows 8 from Microsoft (according to Microsoft)', was what you were running. Now, you are running 'GRUB2 from bws111 (according to Canonical).' Is this an intentional change?" That should stop a lot of malware sneaking in as a bootloader.

But what if you intentionally installed a bootloader that loads unsigned kernels so you can hack the system to remove DRM checks, etc? In that case, any upstream processes (kernel, drivers, apps, remote services) can find out that your bootloader was from cryptlizard, and assign as much (or as little) trust to that as they want.

Re:GPLv3 violation

[cryptizard]

Yes, that would be wonderful if that was how secure boot worked in right now but it does not. Hence, we have to rely on the fact that the keys are very tightly controlled. The second part would also be great except any "upstream" process is at the mercy of the boot loader. Imagine the boot loader is a hypervisor that fakes any requests from the kernel for the boot sector so that it looks like everything is valid and signed. The only way to get this to work right now is to have complete controlled trusted boot chain.

Re:GPLv3 violation

[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:GPLv3 violation

[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 are not tightly controlled at all. In fact, the problem there is how to make it EASY to add the keys. Hence, the Red Hat/Microsoft deal where Microsoft will sign anyones code for $90. Microsoft is controlling the signing key, and the matching public key will be widely distributed because of Microsoft's influence. Ubuntu is taking a different tack, opting instead to do it's own signing, and trying to get hardware manufacturers to include their public key.

The only other thing that needs to be tightly controlled is your personal database of trusted public keys. The only requirement there is that you trust the entity who's key you have to verify that the code is from who they says it is before they sign it. Those keys can come either pre-installed from sources that the manufacturer trusts (Microsoft and Ubuntu) or they can be added by the owner of the machine.

No, a hypervisor can not fake answers from the TPM. Look at the lift of companies who contributed to trusted computing. Notice how right at the top is IBM, someone with about 40 years of experience with virtualization and hypervisors. Do you really think they designed this 'trusted' model so it could be easily broken by something as trivial as a hypervisor? No. The answer to that problem is the TPM - a piece of hardware. The TPM is itself 'sealing' it's responses with encryption. You can't 'fake' a TPM, because you don't have the key that the TPM uses to seal it's responses. Therefore, any responses your hypervisor attempts to give to the process that asks for attestation will be rejected, because the response does not come from a trusted source.

Again, the ONLY keys that need to be tightly controlled are the ones used to do signing, including the one the TPM uses.

So, if someone wants to see if they 'trust' your system before giving it data, they ask you to provide attestation as to the state of your machine. You can either provide a valid answer from the TPM (which they will trust), or a spoofed answer (which will not be trusted). If you provide a valid answer, then they can see that the UEFI is good, but the bootloader, signed by Microsoft, says it is from 'cryptlizard'. End of trust.

Re:GPLv3 violation

[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 re-sign the windows loader.

Re:GPLv3 violation

[cryptizard]

If there is no verification going along with the signing, then what is even the point of having Canonical sign custom boot loaders in the first place? You should just self sign it and then load your public key in UEFI. I agree with everything you are saying, I just don't see the point of Canonical signing anything but their own code.

Supports the thing where MS took over the HW?

[Anonymous Coward]

Does it support this UEFI thing where Microsoft took control over the hardware market preventing open source OSes by requiring every OS to pay MS for a key to be able to boot it?

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:Slightly OT, anyone still dual-booting?

[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:Slightly OT, anyone still dual-booting?

[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 would boot into. Although still useful now we have developed other ways to remote manage OS selection and reboots.

Re:Slightly OT, anyone still dual-booting?

[Anonymous Coward]

All my laptops for the last 11 years have been dual Windows/Linux. I don't see that changing for the foreseeable future.

Re:Slightly OT, anyone still dual-booting?

[Anonymous Coward]

Do PC games run well under virtualization? Seriously, I'm asking. That's the only reason I dual boot my Linux machine into Windows.

Re:Slightly OT, anyone still dual-booting?

[hobarrera]

wine 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 they said GRUB 2.00 supports FreeDOS 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.)

Re:Supports FreeDOS (and Windows, Mac)

[Anonymous Coward]

The Darwin support is the shit. Before I hosed an OSX partition a while back on a Hackintosh I'd decided to try out (Hey, it was a legit family upgrade DVD, and I duct-taped the broken monitor from my G4 iBook that failed to it, so it was technically legit!) I had it running with one of the hackintosh oriented bootloaders. At some point XP overwrote it, at which point I got around to installing grub1.99 under ubuntu to test it out. Long story short it detected every OS on the system, including MacOS, and direct-booted into OSX from grub with no intermediary steps. Blew me away. Sadly getting it to autodetect as nicely on other linuxes (notably gentoo) just hasn't happened.

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:Original Grub is still better

[xororand]

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

Re:Original Grub is still better

[Anonymous Coward]

Same as menu.lst grub.cfg is 'cut and paste a known good entry, modify to fit new kernel'. Or at least that's how I handle it. You definitely can try and use grub(2)-mkconfig, but depending on your OS it may or may not autodetect every available partition/entry type (memtest86(+) on gentoo is a failure example).

Re:Original Grub is still better

[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.

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.

Re:To prevent boot-time rootkit installation

[Swave An deBwoner]

Welcome to RootKit 3.14159265 !

At the prompt, please securely
sign this code so that your
installation may proceed without
problems.

There ya go!

Re:To prevent boot-time rootkit installation

[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:To prevent boot-time rootkit installation

[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:To prevent boot-time rootkit installation

[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 can even do this on linux - just google for Trusted GRUB. I'm fine with the concept, as long as the computer owner is issued a copy of any keys preinstalled by the vendor (including associated private keys), and is able to replace them with their own. That is what is missing in most TPM implementations, which is what makes it "treacherous computing." If you just fixed that one bit this would be a powerful way for system owners to prevent attacks on their devices while blocking attempts to use it for DRM.

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:Custom mode

[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:Custom mode

[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.

Can it boot from named partition vs Nth partition?

[Anonymous Coward]

I often change plug and unplug internal drives and maybe connect them in a different order than originally or maybe one less drive is attached than before. Booting then doesn't work because the drive that used to be "SDA" is now "SDB". I want to be able to list my boot partition using its name no matter what order it is in a list. Can the latest GRUB do this?

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/
http://www.supergrubdisk.org/wiki/Loopback.cfg
http://grml.org/

Re:ISO loopback mounting

[Anonymous Coward]

I loves this!

A year ago I used it make a 4GB thumb drive with 5 different Ubuntu desktop ISOs. Thumb drive prices have dropped 50% in the past year, so I guess it's time to make an 8GB thumb drive with all 8 of the currently supported Ubuntu desktop ISOs: {10.04_LTS,11.04,11.10,12.04_LTS}_{i386,amd64}.

Thanks for the reminder! :-D

p.s. You can also put 6 bootable ISOs on a regular 4.7GB DVD+R.

Re:ISO loopback mounting

[heson]

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

/grub2 hater

Re:ISO loopback mounting

[Anonymous Coward]

it is, using DOS based BIOS update images was questionable. Failed sometimes, wouldn't boot other times. Much easier to burn a cd, usb-cdfs or Zalman ZVE type device (iodd).

I Use Ubuntu Professionally

[Anonymous Coward]

You can put me amongst the professional users of Ubuntu servers.

I use CentOS, Red Hat and SuSE Enterprise Linux(SLES) and FreeBSD as well. However, I find Ubuntu is the easiest to manage.

But, Ubuntu is not without its problems either. The LTS releases that I use, these are servers, are slow to fix bugs that are not security related. Some are never fixed which is insanely frustrating.

Also, Debian/Ubuntu seem to feel that they should rearrange packages which makes working with an application a bit different on Ubuntu than on any other distribution. This makes finding some files cumbersome and breaks my scripts.

Despite these issues, I would have been willing to use Ubuntu exclusively for professional use. However, I'm no longer sure about that thought. There seems to be a lot of change coming in the next LTS version. Change that doesn't seem to offer my servers much, if any, value.

Re:I Use Ubuntu Professionally

[Anonymous Coward]

Personally, I like how Debian/Ubuntu reorganize files into a logically consistent way. I find it makes things very easy to find, unlike the willy-nilly system used on other distributions. It's one of the reasons why I stick with Debian-derived distros.

I've had the same experience on LTS as you. Even really simple bugs don't get fixed.

I have Ubuntu deployed on 25 servers, my desktops, and laptop. It has its warts, but it's the best out there.

Re:I Use Ubuntu Professionally

[Anonymous Coward]

Reorganizing packages makes using a strange app on a familiar distro easy.
Shipping vanilla packages makes using a familiar app on a strange distro easy.

Depending on who you are, one of those sounds like a horribly stupid idea; if it's the one I like, you're the kind of deranged fool who's keeping UNIX from succeeding on the desktop.

Just Buy Non MS Hardware

[Anonymous Coward]

Can't we all just boycott UEFI???

I mean really ... why not???

Re:Just Buy Non MS Hardware

[Malvineous]

The problem is that a huge amount of people are Windows users and won't boycott, so the tiny drop in business probably wouldn't be noticeable.

But it would be nice if lots of people bought from companies like Dell who offer a good return policy, then return them based on the inability to boot a custom Linux kernel. That might actually affect their bottom line enough that they put in a DIP switch on the motherboard that disables secure boot - assuming they aren't going to do that already, Dell aren't exactly opposed to Linux.

I can just imagine the tech support calls from "Microsoft" that home users get, explaining how the evil computer company disabled the turbo function on their PC, and to speed up their computer they have to flick this little switch inside the box...

Re:Just Buy Non MS Hardware

[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.

I'm glad I got away from it.

[schmatzler]

I've had always problems with Grub. Using Ubuntu, I often had to alter the config after every new version, to be able to boot a Windows partition. A lot of difficult, not self-explaining commands using grub-config or the fact, that the device names not always match the corresponding order in Grub let me truly hate this "software". After I switched to Slackware, I got LILO working out of the box and always doing what it should do: Booting my machine. Sometimes the old, established things are the best.

Re:I'm glad I got away from it.

[Anonymous Coward]

device names not always match the corresponding order

Blame x86 bioses, not grub, for this.
And you will be happy to hear that grub2 has UUID support, so you can freely reorder your devices from bios POV without having to worry about the resulting bootable status.

Unless i need to boot iso images...

[Anonymous Coward]

Why would i want to switch to that bloated piece of crap?
grub2 wont be the solution to secure boot anyway, so i will stay with grub 0.9 till i need to buy new hardware and to get past the secure boot crap...

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:Citation needed

[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 comma just doesn't belong here. They want to keep the private signing key private.

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.

Re:The Hurd comes next?

[Hal_Porter]

GNU sans (rather than slash) Linux OS.

I thought we'd all agreed to call it GNU-Linux, pronounced GNU minus Linux?

Re:Can it boot from named partition vs Nth partiti

[Drinking Bleach]

use UUIDs and it can.

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.

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

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:Antitrustworthy Computing

[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:Antitrustworthy Computing

[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.

Now if they can just make it not suck

[Anonymous Coward]

As someone who has experienced grub command line hell, I ask, is this progress?

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.

Inevitable, inevitable, inevitable

[galanom]

Oh, how discreetly you attach words like "inevitably" to your predictions! How "futile" is arguing with you....!

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 config is stored on the Linux1 partition, then if there is an error or you wipe the Linux1 partition, then the entire drive can't boot, even if Linux2 and Linux3 are working fine! I mean, suppose you haven't used Linux1 for ages but the config files are there ...

Or is it replicated in all partitions? in that case, where is it stored on each partition?

Or can you put a GRUB config file on any partition, and it will find it? in that case, what happens if there are two conflicting configs on different partitions?

Or is it stored on the MBR just like LILO, and when the config file on the partition goes AWOL, GRUB will just use the MBR copy?

From what I can tell, the answer seems to be the first option, but I don't see how this makes GRUB a good thing if I'm beholden to a partition (Linux1 in this case) which may be obsolete and waiting to be wipe and installed over with the latest Linux distro.

Re:Got questions re: GRUB config (vs. LILO)

[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 code does have to go somewhere - you can't fit all those fancy menus in a boot sector. The code in the 0th cylinder can decode your filesystem so it is no problem if the files are fragmented/etc.

Sure it's not your distro?

[Anonymous Coward]

Usually the need to run the user-edited config file through a preprocessor / mangler is is a requirement imposed by your distro, not the upstream developers of the software. Red Hat, Debian, and their derivatives are the biggest offenders here.

You can always use a distro that doesn't do this, of course (Arch and Slackware come to mind) but then you have to configure everything by hand, not just the one part your previous distro handled badly.