[gentoo-amd64] Re: Outside of portage (was Re: Kernel-3.3.0 and Nvidia-drivers)

[Duncan]

Barry Schwartz posted on Thu, 22 Mar 2012 16:32:55 -0500 as excerpted:

> Frank Peters <frank.peters@×××××××.net> skribis:
>> Out of habit, I still use the kernel sources from kernel.org.
>
> 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 ebuilds
> were broken anyway, and I didn’t 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’m satisfied.
>
> (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 
main machine, with an rsync script to sync up), I use three overlays 
(kde, mozilla, x11) in addition to my own, unmasking stuff I care about 
that takes too long to show up in ~arch, and a number of -9999 live-git 
packages.

For the kernel, I've been running direct Linus-kernel live-git for quite 
some time now, using my own git-pull, git-whatchanged, make-oldconfig, 
build and install scripts, tho I don't normally update during the 2-weeks 
or so merge window between release and the following -rc1.  Sometimes I 
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.  
Additionally, I get a chance to find, report, and generally get fixed, 
bugs, before they end up in a release kernel.  That's actually the most 
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 
releases simply don't have detailed enough changelogs for me to properly 
trace bugs -- the git commit logs and occasionally the commit sources 
themselves are MUCH more informative, even tho I don't claim to really 
know C/C++ or the like (or even python/perl, but I do OK with bash =:^).

That's precisely why I run openrc-9999 as well.  I had a couple 
experiences where openrc had a regression, and there really isn't a 
proper changelog for it, at least that's easy to view before one actually 
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, 
updating it perhaps twice a week or so.   I had already created a couple 
scripts to let me view git-whatchanged on the three (all git-based) 
overlays I run, and I expanded them a bit so I could check git-whatchanged 
with openrc-9999 and whatever other live-git based packages I run, as 
well.

Now, with updates a couple times a week, I not only check the whatchanged 
log before I actually do the install, but if anything looks interesting, 
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/ 
go wrong, I can either use init=bash on grub's commandline, or assemble 
md9 (my backup rootfs and /usr/local partitions) instead of md3 (my main 
rootfs and use root=/dev/md9p1 instead of the kernel built-in
root=/dev/md3p1, thus letting me boot, and either fix the problem, or 
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 
reported and gotten fixed a number of bugs before they ever made it to a 
full release.  But what's really nice about openrc, unlike the kernel, is 
that enough of it is in shell scripts that I can actually propose patches 
some of the time, spottting and correcting the incorrectly used 
commandline option, or at least understanding and explaining why a change 
to the scripts won't work, even if I'm not sure how to actually make a 
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 
client, which I use via gmane for following this list, BTW.  I've been 
interested in nntp clients for years, every since I ran the IE/OE4 betas 
back in the MSWindows 95 era, before MSWindows 98.  So when MS decided to 
do the eXPrivacy thing and I switched to Linux in late 2001, after I'd 
gotten settled on Linux and started looking around for a community 
project to contribute to, the nntp client I had chosen was a logical 
first-choice.  So I've been involved with pan upstream since 2002 or so, 
and have been running a live-vcs version since before gnome and with it 
pan, switched from svn to git.

Pan even lost its former primary developer, Charles Kerr, who moved on to 
other things, and the project looked dead for a few years.  But I and a 
couple others kept the lights on in the user list, which continued to 
function, and eventually we attracted one developer, than another and 
another, and now, pan has an active and healthy development community 
once again. =:^)

So of course I want to run pan's live-git/9999 version.  =:^)  There's 
one in the tree, but I run a slightly modified one here, kept in sync 
with upstream, altho I don't always know the proper way to setup the 
newer USE flags, so some of them only have the side I use setup and 
tested.  Plus, the newer version has features that aren't in a full 
release yet, altho there's another release due this spring/summer that 
should have most of them.

Other than that, it depends on what I'm interested in ATM.  Right now, 
I'm following btrfs, so have the -9999/git-live version of btrfs-progs 
installed, tho I'm not actually running a btrfs filesystem yet, as the 
feature I'm most interested in (multi-way mirroring, the feature they 
/call/ raid1 actually isn't, it's only two-way mirroring) isn't there 
yet... they say kernel 3.5-ish.

For a couple months recently I was running the live-git/9999 version of 
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 
live tho, at least not since I gave up on it pre-4.0) or for gcc-4.6.x, 
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 
packages, because that's where the support for my radeon hd4650 graphics 
card was.  I've not run the xorg/mesa stack live since that support was 
released, but I do sometimes run a couple live-git/9999 xorg packages, 
which are sometimes required to run the latest xorg-server release, or 
because I want to test a new feature in the kernel or mesa, and need a 
live xf86-video-ati to do it, which pulls in a live something else, which 
pulls in two or three other live xorg-releated packages.


You mentioned grub2.  I unmasked and ran the 1.99 version in the tree, 
and have been running the 2.00_betaX versions as well.  Aside from a bit 
of trouble with the initial 1.99 install, and a 2.00_beta1 that would 
boot to the grub menu, but would reboot every time I tried to actually 
boot a kernel, it's been fine.  However, I can mention that while my 
system's legacy-BIOS, I upgraded to GPT partitioning a couple years ago, 
and had the foresight to setup a BIOS-reserved partition on each of my 
four drives.  I've actually been quite happy indeed with how grub2 works 
with that. =:^)

I also run multiple md/raid devices, mostly 4-way RAID-1, and of course, 
grub2 works WAY better with md/raid than did grub-legacy.  But, while 
with most of the system I have a working and backup raid of the same 
size, both 4-way, that wouldn't work for /boot and be able to choose one 
or the other.  So what I did for /boot is split the 4-way in half, into 
two two-way mds, for /boot and the backup /boot.  That sort-of worked OK 
for grub1, getting the job done but managing it was quite complicated.  
By contrast, grub2 makes the boot and backup-boot md/raid management a 
BREEZE! =:^)

But the four drives, two as my main /boot, and the other two as a backup 
/boot, makes upgrading grub a very nearly risk-free exercise, especially 
with GPT and a dedicated BIOS partition for grub2 to use as well. =:^)  I 
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=1

# Just to be safe, since I handle this myself
INSTALL_MASK="$INSTALL_MASK /etc/default /etc/grub.d grub2-mkconfig"
PKG_INSTALL_MASK="$INSTALL_MASK"


I don't know what the package would do if I didn't set the dont-mount 
var, as it can't mount it anyway, since that md/raid device is normally 
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 
would, and leaves /boot alone.

Then I activate the main boot md and mount it, and run grub2-install 
/dev/sda (the first of the four drives, normally set in BIOS to boot) 
myself.

Then I reboot.  If it doesn't work, I can set the BIOS to boot from sdc 
or sdd instead, where the backup boot is located, with a grub that's 
still the older version.  I can then either fix the issue or revert to 
the older grub, from the backup boot.

When I'm satisfied that the first install is working correctly, then I 
assemble the raid and mount the main /boot again, and run grub2-install 
/dev/sdb (the second spindle on the main /boot).  Then I unmount/stop it 
and assemble and mount the boot backup md/raid, and run grub2-install 
for /dev/sdc and /dev/sdd.

As you can see from the above INSTALL_MASKs I handle the configuration 
manually.  grub2-mkconfig is all but worthless on my system, taking 
longer to install a simple config file than the kernel does to BUILD, or 
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 
seconds each to grub-probe!

So before I test the backup boot and new grub install to it, I copy over 
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 
fourth drive, to test that.  Once that's tested, I reboot once more and 
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 
upgrading any other package on the system, especially something like 
openrc, which as I said, I run the live version of and generally upgrade 
a couple times a week.  Grub does happen to be a bit more work to 
upgrade, since unlike the rest of the system, at least at this point in 
grub2's life, I upgrade on both the main and backup together, tho only 
after testing main.  For other packages, I only upgrade the backup once 
every few months, after I've rebooted since the last upgrade thereby 
testing that, and everything, all the daemons and bootscripts, xorg/mesa, 
kde, etc, seems to be running normally, preferably when I'm running a 
full kde release version, not a prerelease, which I'm now doing about two 
months out of every six.

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