From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S07ra-0005hi-5N for garchives@archives.gentoo.org; Wed, 22 Feb 2012 08:47:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C270EE1C74; Wed, 22 Feb 2012 08:47:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 02A64E1C6C for ; Wed, 22 Feb 2012 08:46:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8C3F11B4050 for ; Wed, 22 Feb 2012 08:46:53 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5.5 tests=[AWL=-0.587, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJEltU1hIhMF for ; Wed, 22 Feb 2012 08:46:46 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 6E8D51B4040 for ; Wed, 22 Feb 2012 08:46:45 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S07qV-0005i4-59 for gentoo-dev@gentoo.org; Wed, 22 Feb 2012 09:46:43 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Feb 2012 09:46:43 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Feb 2012 09:46:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: About gcc-4.6 unmasking Date: Wed, 22 Feb 2012 08:46:35 +0000 (UTC) Message-ID: References: <1329770054.21166.12.camel@belkin4> <20120220190313.57892cfa@gentoo.org> <4F42F0AA.50004@gentoo.org> <20120220200220.3a54d88a@gentoo.org> <1329816398.2868.1.camel@belkin4> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 19ecd49 /st/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: aaed5f93-b241-4352-8162-e58860d264e1 X-Archives-Hash: d55a5e10378111f93ae7b64edcaaf1cf 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 wrote: >> El lun, 20-02-2012 a las 20:02 -0600, Ryan Hill escribi=C3=B3: >>> 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=20 experience as noted below. >>> What's the state of 1.99? =C2=A0I know someone was working on it rece= ntly. >>> We'd also have to update the handbooks. =C2=A0I think it could be sev= eral >>> 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) >=20 > Ubuntu has used grub2 for 3 years, I am considering working on making i= t > stable for at least x86 / amd64. Ubuntu also defaults to upstart (IIRC, it's certainly not openrc!) and=20 unity. I run grub2 here and am all for the update (for one, it allows=20 amd64/nomultilib to actually build grub, no more forced grub-static!),=20 but surely there's better arguments in a gentoo context than mentioning=20 the U-word, however long they've been doing it. My grub2 upgrade experience, FWIW. TL;DR: Gentoo grub2 docs need SERIOUS= =20 improvement for even ~arch usage (the bulk of the below), but I'm=20 thrilled with how it works now that I have it figured out and setup to my= =20 liking. VAST improvement over grub-legacy! FWIW, I unmasked gcc-4.6 when I was still running grub-static, but I was=20 thrilled to discover that grub-1.99 builds (and runs) just fine with it,=20 even on amd64/no-multilib. **BUT** there's still a HUGE lack of decent gentoo specific grub2=20 documentation. The stub of a guide-page that the ebuild mentions, at=20 least as of a few weeks ago when I upgraded, is a start, but it can=20 almost be said to be more missing than there. the holes are so big! =20 There's no way that's fit for even ~arch yet, which is why it's still=20 unkeyworded. grub2 /works/ OK, there's simply no decent documentation at= =20 the gentoo level, and the documentation that's out there just isn't meant= =20 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= =20 that /boot is only two spindles, thus allowing for a backup /boot on the=20 other two, I had the luxury of building and installing (to system)=20 grub-1.99 with DONT_MOUNT_BOOT=3D1 set in /etc/portage/env/sys-boot/grub,= =20 then installing it to one boot record, gpt-BIOS partition and /boot at a=20 time, keeping the other grub-static until I was comfortable with grub2's=20 functionality. That allowed me to do a trial-and-error install and play around with the=20 one, until I was absolutely SURE it was working well, then install to the= =20 second spindle and verify them both, before even TOUCHING the backup=20 /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=20 get things working well, because THE DOCS JUST AREN'T THERE yet. So get=20 the docs there and IMO it's basically ready to go, but that's going to=20 take some time, even to get them to reasonable ~arch level, for folks who= =20 don't have the luxury of multiple bootable spindles and /boot install=20 locations, as I do, and thus need documentation that works, at least for=20 a minimal boot, the first time they let it touch /boot and (on BIOS=20 systems, gpt and mbr both) the boot sector. Some problems I ran into: 1) grub-static blocks all grub, not just <=3Dgrub-1.90. https://bugs.gentoo.org/show_bug.cgi?id=3D398451 As mentioned above, I kept both installed. There's no file-conflicts,=20 once grub-static is set to block <=3Dgrub-1.90, not all grub, as that wor= k=20 is long since done, slotting grub2 against grub-legacy, only grub-static=20 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=3D398459 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=20 doesn't say anything about what they should do. As it happens, a gpt=20 BIOS partition is detected automatically, and it solves a nasty problem=20 MBR folks might have if there's not room between the boot sector and the=20 first partition for grub-core. That's the only two I bugged, as I don't want to bother people /too/ much= =20 with bugs on masked packages. I figured once that doc bug gets fixed and= =20 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=20 happens, it's auto-detected and handling has VASTLY improved compared to=20 grub-legacy, as well. 4) There needs to be a section dealing with what to do (repartition?) if=20 there's no room between the boot sector and the first partition for the=20 grub-core image. On gpt, this image will be placed in the BIOS partition if it's=20 available, but mbr doesn't have such a thing, and I'm sure there's a few=20 gpt folks out there who thought they didn't need a BIOS partition, since=20 grub-legacy doesn't use it anyway. Luckily, I had the foresight to setup= =20 BOTH a BIOS and an EFI partition, for forward compatibility, and that=20 "just works". But surely there's others still on MBR without a=20 sufficient gap (I had problems with that and grub-legacy, it installed=20 to /boot but /boot was/is reiserfs, which would relocate critical bits=20 out from under grub-legacy at times, thus the /boot and=20 /bak/boot scheme), and still others on gpt who didn't have that=20 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=20 that way until I knew grub2 was working), because the script has /boot=20 hardcoded -- it allows the boot record device to be set, but hard-codes=20 /boot, which doesn't make a lot of sense. There's a danger of having=20 /boot on an entirely different device, which may or may not actually be=20 present when the device with that boot record is booted. Surely, they=20 should both be settable. (upstream? What about the pkg_config phase?) I worked around that with a combination of hacking and rearranging my=20 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=20 for folks doing distro kernel upgrades perhaps a few times a year, it's=20 definitely *NOT* acceptable for people like me who routinely run live-git= =20 kernels, normally upgrading them every few days, but occasionally doing a= =20 git-bisect with a new kernel every few minutes for 12 rounds or so! =20 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= =20 was some 30-ish calls to grub2-probe, each of which took ~10 seconds! =20 The primary problem is upstream's, as neither grub2-probe nor grub2-mkconfig caches results, so *EVERY* call to grub2-probe takes ~10=20 seconds, and there are around *30* of them! However, the wouldfallout is= =20 gentoo's to deal with. The workaround is simple enough, or *WOULD* be with proper documentation,= =20 simply don't use grub2-mkconfig. Instead, hand-configure grub.cfg just=20 as gentooers have been hand-configuring grub.conf for years. Done right,= =20 unlike the automated monster upstream uses, such a config doesn't even=20 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,= =20 and the grub config simply points to the symlink so doesn't itself need=20 updated.) FWIW, Arch actually recommends hand-configuring too. (Note the FWIW,=20 unlike the U-word comparison I complained about above. IMO arch's close=20 enough to gentoo to at least have /some/ relevance, but the "FWIW" is=20 there to cover and acknowledge those who find it worth little if=20 anything.) But... gentoo needs some documentation for it, because as I said, most of= =20 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,=20 has it ever been worth it! My favorite feature is being able to access=20 any file from any filesystem, directly from grub. On top of md/raid or=20 lvm2, doesn't matter, it can still access it! No more having to keep=20 copies of such files on /boot! Grub fonts and themes in /usr/share and=20 for that matter, kernel command-line textfile documentation (read with=20 the build-in pager) in /usr/src/linux/Documentation, NOT A PROBLEM! =3D:^= ) Plus, being able to actually build it from amd64/nomultilib instead of=20 having to depend on grub-static, is a big plus. =3D:^) --=20 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