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 1SAxbB-0003Ek-GE for garchives@archives.gentoo.org; Fri, 23 Mar 2012 06:03:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1E412E09B1 for ; Fri, 23 Mar 2012 06:03:40 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by pigeon.gentoo.org (Postfix) with ESMTP id EA0BBE07F9 for ; Fri, 23 Mar 2012 04:05:30 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SAvkk-0003wJ-MA for gentoo-amd64@lists.gentoo.org; Fri, 23 Mar 2012 05:05:26 +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 ; Fri, 23 Mar 2012 05:05:26 +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 ; Fri, 23 Mar 2012 05:05:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Outside of portage (was Re: Kernel-3.3.0 and Nvidia-drivers) Date: Fri, 23 Mar 2012 04:05:13 +0000 (UTC) Message-ID: References: <20120319121229.0a9ecd3b.frank.peters@comcast.net> <20120322144131.5f02745a.frank.peters@comcast.net> <20120322213254.GA26298@crud> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@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.136 (I'm far too busy being delicious; GIT 0efefbf /st/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 8476051a-6e8b-450a-a5c7-a614514053f7 X-Archives-Hash: 706d6afafe4fd2a48d62fa1ff76dc58f Barry Schwartz posted on Thu, 22 Mar 2012 16:32:55 -0500 as excerpted: > Frank Peters skribis: >> Out of habit, I still use the kernel sources from kernel.org. >=20 > This makes me curious what other people are using from outside of > Portage. I install Grub outside of Portage, on the grounds that (a) it > is a bad thing to upgrade unless you have to; and (b) the Grub 2 ebuild= s > were broken anyway, and I didn=E2=80=99t want to switch back to Grub 1 = when > moving from Exherbo back to Gentoo. So I used the default GNU install > procedure in /usr/local. If the machine boots, the machine boots, and > I=E2=80=99m satisfied. >=20 > (I also use only package.use and not make.conf for use flags, a habit > picked up from using Paludis, and recently got rid of package.mask and > use package.accepted_keywords for all my masking. Lots of redundancy in > Portage these days, maybe a bit too much.) FWIW, I use almost all ebuilds (but for the kernel), but beyond ~amd64/no= - multilib (and ~x86 on my netbook, with a 32-bit chroot build image on my=20 main machine, with an rsync script to sync up), I use three overlays=20 (kde, mozilla, x11) in addition to my own, unmasking stuff I care about=20 that takes too long to show up in ~arch, and a number of -9999 live-git=20 packages. For the kernel, I've been running direct Linus-kernel live-git for quite=20 some time now, using my own git-pull, git-whatchanged, make-oldconfig,=20 build and install scripts, tho I don't normally update during the 2-weeks= =20 or so merge window between release and the following -rc1. Sometimes I=20 don't update until rc2 or rc3 if I'm really busy. This works quite well, giving me a chance to see what's coming. =20 Additionally, I get a chance to find, report, and generally get fixed,=20 bugs, before they end up in a release kernel. That's actually the most=20 important bit and the reason I run a number of live-git packages. Git- bisect is pretty easy, and in a number of cases, I've found that the=20 releases simply don't have detailed enough changelogs for me to properly=20 trace bugs -- the git commit logs and occasionally the commit sources=20 themselves are MUCH more informative, even tho I don't claim to really=20 know C/C++ or the like (or even python/perl, but I do OK with bash =3D:^)= . That's precisely why I run openrc-9999 as well. I had a couple=20 experiences where openrc had a regression, and there really isn't a=20 proper changelog for it, at least that's easy to view before one actually= =20 does the install, to be prepared for what's going to be changing. So eventually I just started running the live-9999 version of openrc,=20 updating it perhaps twice a week or so. I had already created a couple=20 scripts to let me view git-whatchanged on the three (all git-based)=20 overlays I run, and I expanded them a bit so I could check git-whatchange= d=20 with openrc-9999 and whatever other live-git based packages I run, as=20 well. Now, with updates a couple times a week, I not only check the whatchanged= =20 log before I actually do the install, but if anything looks interesting,=20 I do a git-show on that specific commit, as well, to see the actual patch= . Then I'm prepared for the etc-updates afterward, and have an idea when/ what might go wrong on the first post-update reboot. If something /does/= =20 go wrong, I can either use init=3Dbash on grub's commandline, or assemble= =20 md9 (my backup rootfs and /usr/local partitions) instead of md3 (my main=20 rootfs and use root=3D/dev/md9p1 instead of the kernel built-in root=3D/dev/md3p1, thus letting me boot, and either fix the problem, or=20 emerge the previous binpkg to get back to the old version. Then I can file the bug, and with openrc as with the kernel, I've=20 reported and gotten fixed a number of bugs before they ever made it to a=20 full release. But what's really nice about openrc, unlike the kernel, is= =20 that enough of it is in shell scripts that I can actually propose patches= =20 some of the time, spottting and correcting the incorrectly used=20 commandline option, or at least understanding and explaining why a change= =20 to the scripts won't work, even if I'm not sure how to actually make a=20 working change that does what they were obviously trying to do. The only other "regular" live/9999 version package I run is pan, the news= =20 client, which I use via gmane for following this list, BTW. I've been=20 interested in nntp clients for years, every since I ran the IE/OE4 betas=20 back in the MSWindows 95 era, before MSWindows 98. So when MS decided to= =20 do the eXPrivacy thing and I switched to Linux in late 2001, after I'd=20 gotten settled on Linux and started looking around for a community=20 project to contribute to, the nntp client I had chosen was a logical=20 first-choice. So I've been involved with pan upstream since 2002 or so,=20 and have been running a live-vcs version since before gnome and with it=20 pan, switched from svn to git. Pan even lost its former primary developer, Charles Kerr, who moved on to= =20 other things, and the project looked dead for a few years. But I and a=20 couple others kept the lights on in the user list, which continued to=20 function, and eventually we attracted one developer, than another and=20 another, and now, pan has an active and healthy development community=20 once again. =3D:^) So of course I want to run pan's live-git/9999 version. =3D:^) There's=20 one in the tree, but I run a slightly modified one here, kept in sync=20 with upstream, altho I don't always know the proper way to setup the=20 newer USE flags, so some of them only have the side I use setup and=20 tested. Plus, the newer version has features that aren't in a full=20 release yet, altho there's another release due this spring/summer that=20 should have most of them. Other than that, it depends on what I'm interested in ATM. Right now,=20 I'm following btrfs, so have the -9999/git-live version of btrfs-progs=20 installed, tho I'm not actually running a btrfs filesystem yet, as the=20 feature I'm most interested in (multi-way mirroring, the feature they=20 /call/ raid1 actually isn't, it's only two-way mirroring) isn't there=20 yet... they say kernel 3.5-ish. For a couple months recently I was running the live-git/9999 version of=20 phonon-vlc, because it had some patches needed for either the kde 4.8 pre= - releases (which I ran, from the kde overlay... I've not tried full kde=20 live tho, at least not since I gave up on it pre-4.0) or for gcc-4.6.x,=20 which I unmasked and did a full system rebuild with, a couple months ago. Awhile back, I was running most of the xorg and mesa stack from live=20 packages, because that's where the support for my radeon hd4650 graphics=20 card was. I've not run the xorg/mesa stack live since that support was=20 released, but I do sometimes run a couple live-git/9999 xorg packages,=20 which are sometimes required to run the latest xorg-server release, or=20 because I want to test a new feature in the kernel or mesa, and need a=20 live xf86-video-ati to do it, which pulls in a live something else, which= =20 pulls in two or three other live xorg-releated packages. You mentioned grub2. I unmasked and ran the 1.99 version in the tree,=20 and have been running the 2.00_betaX versions as well. Aside from a bit=20 of trouble with the initial 1.99 install, and a 2.00_beta1 that would=20 boot to the grub menu, but would reboot every time I tried to actually=20 boot a kernel, it's been fine. However, I can mention that while my=20 system's legacy-BIOS, I upgraded to GPT partitioning a couple years ago,=20 and had the foresight to setup a BIOS-reserved partition on each of my=20 four drives. I've actually been quite happy indeed with how grub2 works=20 with that. =3D:^) I also run multiple md/raid devices, mostly 4-way RAID-1, and of course,=20 grub2 works WAY better with md/raid than did grub-legacy. But, while=20 with most of the system I have a working and backup raid of the same=20 size, both 4-way, that wouldn't work for /boot and be able to choose one=20 or the other. So what I did for /boot is split the 4-way in half, into=20 two two-way mds, for /boot and the backup /boot. That sort-of worked OK=20 for grub1, getting the job done but managing it was quite complicated. =20 By contrast, grub2 makes the boot and backup-boot md/raid management a=20 BREEZE! =3D:^) But the four drives, two as my main /boot, and the other two as a backup=20 /boot, makes upgrading grub a very nearly risk-free exercise, especially=20 with GPT and a dedicated BIOS partition for grub2 to use as well. =3D:^) = I=20 have the following set in /etc/portage/env/sys-boot/grub: # To keep grub from trying to mount /boot, # on a normally deactivated md. DONT_MOUNT_BOOT=3D1 # Just to be safe, since I handle this myself INSTALL_MASK=3D"$INSTALL_MASK /etc/default /etc/grub.d grub2-mkconfig" PKG_INSTALL_MASK=3D"$INSTALL_MASK" I don't know what the package would do if I didn't set the dont-mount=20 var, as it can't mount it anyway, since that md/raid device is normally=20 not active/assembled. But with that, it won't even try it. That means the grub ebuild simply merges it to /usr/* as it normally=20 would, and leaves /boot alone. Then I activate the main boot md and mount it, and run grub2-install=20 /dev/sda (the first of the four drives, normally set in BIOS to boot)=20 myself. Then I reboot. If it doesn't work, I can set the BIOS to boot from sdc=20 or sdd instead, where the backup boot is located, with a grub that's=20 still the older version. I can then either fix the issue or revert to=20 the older grub, from the backup boot. When I'm satisfied that the first install is working correctly, then I=20 assemble the raid and mount the main /boot again, and run grub2-install=20 /dev/sdb (the second spindle on the main /boot). Then I unmount/stop it=20 and assemble and mount the boot backup md/raid, and run grub2-install=20 for /dev/sdc and /dev/sdd. As you can see from the above INSTALL_MASKs I handle the configuration=20 manually. grub2-mkconfig is all but worthless on my system, taking=20 longer to install a simple config file than the kernel does to BUILD, or=20 at least it did when I tried it back on grub-1.99. When I profiled/ traced the problem thru the script, it was due to about 50 calls at ~10=20 seconds each to grub-probe! So before I test the backup boot and new grub install to it, I copy over=20 any grubenv or *.cfg changes from the main boot to the backup boot. Then I can reboot again, setting the BIOS to boot from the third or=20 fourth drive, to test that. Once that's tested, I reboot once more and=20 set the BIOS back to booting from the first drive and main /boot. So as you can see, upgrading grub isn't any more dangerous for me than=20 upgrading any other package on the system, especially something like=20 openrc, which as I said, I run the live version of and generally upgrade=20 a couple times a week. Grub does happen to be a bit more work to=20 upgrade, since unlike the rest of the system, at least at this point in=20 grub2's life, I upgrade on both the main and backup together, tho only=20 after testing main. For other packages, I only upgrade the backup once=20 every few months, after I've rebooted since the last upgrade thereby=20 testing that, and everything, all the daemons and bootscripts, xorg/mesa,= =20 kde, etc, seems to be running normally, preferably when I'm running a=20 full kde release version, not a prerelease, which I'm now doing about two= =20 months out of every six. --=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