Alec Warner posted on Tue, 21 Feb 2012 14:38:53 -0800 as excerpted: > On Tue, Feb 21, 2012 at 1:26 AM, Pacho Ramos <pa...@gentoo.org> wrote: >> El lun, 20-02-2012 a las 20:02 -0600, Ryan Hill escribió: >>> On Mon, 20 Feb 2012 17:17:30 -0800 Zac Medico wrote: >>>> On 02/20/2012 05:03 PM, Ryan Hill wrote: >>>>> On Mon, 20 Feb 2012 21:34:14 +0100 Pacho Ramos wrote: >>>>> >>>>>> [W]hat issues are preventing us from unmasking gcc-4.6 >>>>>> (and think on a near stabilization)?
>>>>> Grub is the only blocker. >>>> Stabilize grub-1.99, and modify the grub-0.9x ebuilds to die if they >>>> can't find a supported compiler. The latter should be doable now, with the die suggesting either grub-static or gcc-config to gcc-4.5, user's choice. The former (grub-1.99)... will take some time... mostly for docs, see my experience as noted below. >>> What's the state of 1.99? I know someone was working on it recently. >>> We'd also have to update the handbooks. I think it could be several >>> months of work to get it ready, and I'd like to unmask 4.6 last >>> September. >>> >> As looks like fixing old grub is far away because nobody know what is >> causing that issues, probably trying to get grub-1.99 ready for >> stabilization would be interesting (we will need to do that sooner or >> later anyway) > > Ubuntu has used grub2 for 3 years, I am considering working on making it > stable for at least x86 / amd64. Ubuntu also defaults to upstart (IIRC, it's certainly not openrc!) and unity. I run grub2 here and am all for the update (for one, it allows amd64/nomultilib to actually build grub, no more forced grub-static!), but surely there's better arguments in a gentoo context than mentioning the U-word, however long they've been doing it. My grub2 upgrade experience, FWIW. TL;DR: Gentoo grub2 docs need SERIOUS improvement for even ~arch usage (the bulk of the below), but I'm thrilled with how it works now that I have it figured out and setup to my liking. VAST improvement over grub-legacy! FWIW, I unmasked gcc-4.6 when I was still running grub-static, but I was thrilled to discover that grub-1.99 builds (and runs) just fine with it, even on amd64/no-multilib. **BUT** there's still a HUGE lack of decent gentoo specific grub2 documentation. The stub of a guide-page that the ebuild mentions, at least as of a few weeks ago when I upgraded, is a start, but it can almost be said to be more missing than there. the holes are so big! There's no way that's fit for even ~arch yet, which is why it's still unkeyworded. grub2 /works/ OK, there's simply no decent documentation at the gentoo level, and the documentation that's out there just isn't meant for or targeted at gentoo users /at/ /all/! This is the current doc, FWIW: http://dev.gentoo.org/~scarabeus/grub-2-guide.xml Since I'm running a quad-spindle md/raid (generally raid-1) setup, except that /boot is only two spindles, thus allowing for a backup /boot on the other two, I had the luxury of building and installing (to system) grub-1.99 with DONT_MOUNT_BOOT=1 set in /etc/portage/env/sys-boot/grub, then installing it to one boot record, gpt-BIOS partition and /boot at a time, keeping the other grub-static until I was comfortable with grub2's functionality. That allowed me to do a trial-and-error install and play around with the one, until I was absolutely SURE it was working well, then install to the second spindle and verify them both, before even TOUCHING the backup /boot and grub-static install on the other two spindles. It's a very good thing, too, as it took me QUITE some trial and error to get things working well, because THE DOCS JUST AREN'T THERE yet. So get the docs there and IMO it's basically ready to go, but that's going to take some time, even to get them to reasonable ~arch level, for folks who don't have the luxury of multiple bootable spindles and /boot install locations, as I do, and thus need documentation that works, at least for a minimal boot, the first time they let it touch /boot and (on BIOS systems, gpt and mbr both) the boot sector. Some problems I ran into: 1) grub-static blocks all grub, not just <=grub-1.90. https://bugs.gentoo.org/show_bug.cgi?id=398451 As mentioned above, I kept both installed. There's no file-conflicts, once grub-static is set to block <=grub-1.90, not all grub, as that work is long since done, slotting grub2 against grub-legacy, only grub-static hasn't been updated appropriately. 2) The doc covers BIOS/mbr and UEFI, but not BIOS/gpt https://bugs.gentoo.org/show_bug.cgi?id=398459 The current doc URL again: http://dev.gentoo.org/~scarabeus/grub-2-guide.xml Some people (like me) switched to gpt some time ago. The existing doc doesn't say anything about what they should do. As it happens, a gpt BIOS partition is detected automatically, and it solves a nasty problem MBR folks might have if there's not room between the boot sector and the first partition for grub-core. That's the only two I bugged, as I don't want to bother people /too/ much with bugs on masked packages. I figured once that doc bug gets fixed and there's some sign of movement, I can file other bugs. 3) LVM is mentioned as auto-detected, but md/raid isn't covered. As it happens, it's auto-detected and handling has VASTLY improved compared to grub-legacy, as well. 4) There needs to be a section dealing with what to do (repartition?) if there's no room between the boot sector and the first partition for the grub-core image. On gpt, this image will be placed in the BIOS partition if it's available, but mbr doesn't have such a thing, and I'm sure there's a few gpt folks out there who thought they didn't need a BIOS partition, since grub-legacy doesn't use it anyway. Luckily, I had the foresight to setup BOTH a BIOS and an EFI partition, for forward compatibility, and that "just works". But surely there's others still on MBR without a sufficient gap (I had problems with that and grub-legacy, it installed to /boot but /boot was/is reiserfs, which would relocate critical bits out from under grub-legacy at times, thus the /boot and /bak/boot scheme), and still others on gpt who didn't have that foresight, who will have problems and need to know how to solve them. 5) After system installation I had trouble installing to the backup boot (/bak/boot, normal /boot was still grub-static and I wanted to keep it that way until I knew grub2 was working), because the script has /boot hardcoded -- it allows the boot record device to be set, but hard-codes /boot, which doesn't make a lot of sense. There's a danger of having /boot on an entirely different device, which may or may not actually be present when the device with that boot record is booted. Surely, they should both be settable. (upstream? What about the pkg_config phase?) I worked around that with a combination of hacking and rearranging my fstab and scripts to mount what had been /bak/boot as /boot. 6) Most existing documentation seems to assume grub-mkconfig (grub2-mkconfig on gentoo), but on my system anyway, running grub2-mkconfig took longer than building a kernel from clean! Seriously, building a kernel takes about 4 minutes here, and grub2-mkconfig was taking about 5! While that's /arguably/ acceptable for folks doing distro kernel upgrades perhaps a few times a year, it's definitely *NOT* acceptable for people like me who routinely run live-git kernels, normally upgrading them every few days, but occasionally doing a git-bisect with a new kernel every few minutes for 12 rounds or so! Doubling that turnaround time due to upstream's incredibly STUPID grub2-mkconfig implementation just isn't going to cut it! With a bunch of script-timestamp debugging, I discovered that the problem was some 30-ish calls to grub2-probe, each of which took ~10 seconds! The primary problem is upstream's, as neither grub2-probe nor grub2-mkconfig caches results, so *EVERY* call to grub2-probe takes ~10 seconds, and there are around *30* of them! However, the wouldfallout is gentoo's to deal with. The workaround is simple enough, or *WOULD* be with proper documentation, simply don't use grub2-mkconfig. Instead, hand-configure grub.cfg just as gentooers have been hand-configuring grub.conf for years. Done right, unlike the automated monster upstream uses, such a config doesn't even need updated with a kernel upgrade, it "just works". (Here, I use the dated but still extremely effective update-symlinks-to- newest-two and a stable backup, trick. It's in my kernel install script, and the grub config simply points to the symlink so doesn't itself need updated.) FWIW, Arch actually recommends hand-configuring too. (Note the FWIW, unlike the U-word comparison I complained about above. IMO arch's close enough to gentoo to at least have /some/ relevance, but the "FWIW" is there to cover and acknowledge those who find it worth little if anything.) But... gentoo needs some documentation for it, because as I said, most of what's out there assumes the automated /etc/grub.d/* and grub2-mkconfig. There's nothing on that in the current doc, AT ALL. But WOW, once it was done and before I've even setup a graphics theme, has it ever been worth it! My favorite feature is being able to access any file from any filesystem, directly from grub. On top of md/raid or lvm2, doesn't matter, it can still access it! No more having to keep copies of such files on /boot! Grub fonts and themes in /usr/share and for that matter, kernel command-line textfile documentation (read with the build-in pager) in /usr/src/linux/Documentation, NOT A PROBLEM! =:^) Plus, being able to actually build it from amd64/nomultilib instead of having to depend on grub-static, is a big plus. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
