Slashdot Mirror
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."
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.
I still like LILO better.
I'm glad GRUB2 is finally finished! Now we can finally move on to scrapping the entire thing and spending years on GRUB3.
Ubuntu is using grub2 as default since 9.10. https://help.ubuntu.com/community/Grub2
Not for long, though.
Does it install correctly on /dev/mapper RAID drives?
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
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.
Somehow when I read this I just heard crickets in the background.
I haven't thought of anything clever to put here, but then again most of you haven't either.
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.
Join the Slashcott! Feb 10 thru Feb 17!
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.
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.
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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.
I swear to God...I swear to God! That is NOT how you treat your human!
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.)
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.
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.
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
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. /bar.
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
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/
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.
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:
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
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...
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
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.
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
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.
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?
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.
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.
Eurohacker European paranoia, gun rights, and h