1 |
Barry Schwartz posted on Thu, 22 Mar 2012 16:32:55 -0500 as excerpted: |
2 |
|
3 |
> Frank Peters <frank.peters@×××××××.net> skribis: |
4 |
>> Out of habit, I still use the kernel sources from kernel.org. |
5 |
> |
6 |
> This makes me curious what other people are using from outside of |
7 |
> Portage. I install Grub outside of Portage, on the grounds that (a) it |
8 |
> is a bad thing to upgrade unless you have to; and (b) the Grub 2 ebuilds |
9 |
> were broken anyway, and I didn’t want to switch back to Grub 1 when |
10 |
> moving from Exherbo back to Gentoo. So I used the default GNU install |
11 |
> procedure in /usr/local. If the machine boots, the machine boots, and |
12 |
> I’m satisfied. |
13 |
> |
14 |
> (I also use only package.use and not make.conf for use flags, a habit |
15 |
> picked up from using Paludis, and recently got rid of package.mask and |
16 |
> use package.accepted_keywords for all my masking. Lots of redundancy in |
17 |
> Portage these days, maybe a bit too much.) |
18 |
|
19 |
FWIW, I use almost all ebuilds (but for the kernel), but beyond ~amd64/no- |
20 |
multilib (and ~x86 on my netbook, with a 32-bit chroot build image on my |
21 |
main machine, with an rsync script to sync up), I use three overlays |
22 |
(kde, mozilla, x11) in addition to my own, unmasking stuff I care about |
23 |
that takes too long to show up in ~arch, and a number of -9999 live-git |
24 |
packages. |
25 |
|
26 |
For the kernel, I've been running direct Linus-kernel live-git for quite |
27 |
some time now, using my own git-pull, git-whatchanged, make-oldconfig, |
28 |
build and install scripts, tho I don't normally update during the 2-weeks |
29 |
or so merge window between release and the following -rc1. Sometimes I |
30 |
don't update until rc2 or rc3 if I'm really busy. |
31 |
|
32 |
This works quite well, giving me a chance to see what's coming. |
33 |
Additionally, I get a chance to find, report, and generally get fixed, |
34 |
bugs, before they end up in a release kernel. That's actually the most |
35 |
important bit and the reason I run a number of live-git packages. Git- |
36 |
bisect is pretty easy, and in a number of cases, I've found that the |
37 |
releases simply don't have detailed enough changelogs for me to properly |
38 |
trace bugs -- the git commit logs and occasionally the commit sources |
39 |
themselves are MUCH more informative, even tho I don't claim to really |
40 |
know C/C++ or the like (or even python/perl, but I do OK with bash =:^). |
41 |
|
42 |
That's precisely why I run openrc-9999 as well. I had a couple |
43 |
experiences where openrc had a regression, and there really isn't a |
44 |
proper changelog for it, at least that's easy to view before one actually |
45 |
does the install, to be prepared for what's going to be changing. |
46 |
|
47 |
So eventually I just started running the live-9999 version of openrc, |
48 |
updating it perhaps twice a week or so. I had already created a couple |
49 |
scripts to let me view git-whatchanged on the three (all git-based) |
50 |
overlays I run, and I expanded them a bit so I could check git-whatchanged |
51 |
with openrc-9999 and whatever other live-git based packages I run, as |
52 |
well. |
53 |
|
54 |
Now, with updates a couple times a week, I not only check the whatchanged |
55 |
log before I actually do the install, but if anything looks interesting, |
56 |
I do a git-show on that specific commit, as well, to see the actual patch. |
57 |
|
58 |
Then I'm prepared for the etc-updates afterward, and have an idea when/ |
59 |
what might go wrong on the first post-update reboot. If something /does/ |
60 |
go wrong, I can either use init=bash on grub's commandline, or assemble |
61 |
md9 (my backup rootfs and /usr/local partitions) instead of md3 (my main |
62 |
rootfs and use root=/dev/md9p1 instead of the kernel built-in |
63 |
root=/dev/md3p1, thus letting me boot, and either fix the problem, or |
64 |
emerge the previous binpkg to get back to the old version. |
65 |
|
66 |
Then I can file the bug, and with openrc as with the kernel, I've |
67 |
reported and gotten fixed a number of bugs before they ever made it to a |
68 |
full release. But what's really nice about openrc, unlike the kernel, is |
69 |
that enough of it is in shell scripts that I can actually propose patches |
70 |
some of the time, spottting and correcting the incorrectly used |
71 |
commandline option, or at least understanding and explaining why a change |
72 |
to the scripts won't work, even if I'm not sure how to actually make a |
73 |
working change that does what they were obviously trying to do. |
74 |
|
75 |
The only other "regular" live/9999 version package I run is pan, the news |
76 |
client, which I use via gmane for following this list, BTW. I've been |
77 |
interested in nntp clients for years, every since I ran the IE/OE4 betas |
78 |
back in the MSWindows 95 era, before MSWindows 98. So when MS decided to |
79 |
do the eXPrivacy thing and I switched to Linux in late 2001, after I'd |
80 |
gotten settled on Linux and started looking around for a community |
81 |
project to contribute to, the nntp client I had chosen was a logical |
82 |
first-choice. So I've been involved with pan upstream since 2002 or so, |
83 |
and have been running a live-vcs version since before gnome and with it |
84 |
pan, switched from svn to git. |
85 |
|
86 |
Pan even lost its former primary developer, Charles Kerr, who moved on to |
87 |
other things, and the project looked dead for a few years. But I and a |
88 |
couple others kept the lights on in the user list, which continued to |
89 |
function, and eventually we attracted one developer, than another and |
90 |
another, and now, pan has an active and healthy development community |
91 |
once again. =:^) |
92 |
|
93 |
So of course I want to run pan's live-git/9999 version. =:^) There's |
94 |
one in the tree, but I run a slightly modified one here, kept in sync |
95 |
with upstream, altho I don't always know the proper way to setup the |
96 |
newer USE flags, so some of them only have the side I use setup and |
97 |
tested. Plus, the newer version has features that aren't in a full |
98 |
release yet, altho there's another release due this spring/summer that |
99 |
should have most of them. |
100 |
|
101 |
Other than that, it depends on what I'm interested in ATM. Right now, |
102 |
I'm following btrfs, so have the -9999/git-live version of btrfs-progs |
103 |
installed, tho I'm not actually running a btrfs filesystem yet, as the |
104 |
feature I'm most interested in (multi-way mirroring, the feature they |
105 |
/call/ raid1 actually isn't, it's only two-way mirroring) isn't there |
106 |
yet... they say kernel 3.5-ish. |
107 |
|
108 |
For a couple months recently I was running the live-git/9999 version of |
109 |
phonon-vlc, because it had some patches needed for either the kde 4.8 pre- |
110 |
releases (which I ran, from the kde overlay... I've not tried full kde |
111 |
live tho, at least not since I gave up on it pre-4.0) or for gcc-4.6.x, |
112 |
which I unmasked and did a full system rebuild with, a couple months ago. |
113 |
|
114 |
Awhile back, I was running most of the xorg and mesa stack from live |
115 |
packages, because that's where the support for my radeon hd4650 graphics |
116 |
card was. I've not run the xorg/mesa stack live since that support was |
117 |
released, but I do sometimes run a couple live-git/9999 xorg packages, |
118 |
which are sometimes required to run the latest xorg-server release, or |
119 |
because I want to test a new feature in the kernel or mesa, and need a |
120 |
live xf86-video-ati to do it, which pulls in a live something else, which |
121 |
pulls in two or three other live xorg-releated packages. |
122 |
|
123 |
|
124 |
You mentioned grub2. I unmasked and ran the 1.99 version in the tree, |
125 |
and have been running the 2.00_betaX versions as well. Aside from a bit |
126 |
of trouble with the initial 1.99 install, and a 2.00_beta1 that would |
127 |
boot to the grub menu, but would reboot every time I tried to actually |
128 |
boot a kernel, it's been fine. However, I can mention that while my |
129 |
system's legacy-BIOS, I upgraded to GPT partitioning a couple years ago, |
130 |
and had the foresight to setup a BIOS-reserved partition on each of my |
131 |
four drives. I've actually been quite happy indeed with how grub2 works |
132 |
with that. =:^) |
133 |
|
134 |
I also run multiple md/raid devices, mostly 4-way RAID-1, and of course, |
135 |
grub2 works WAY better with md/raid than did grub-legacy. But, while |
136 |
with most of the system I have a working and backup raid of the same |
137 |
size, both 4-way, that wouldn't work for /boot and be able to choose one |
138 |
or the other. So what I did for /boot is split the 4-way in half, into |
139 |
two two-way mds, for /boot and the backup /boot. That sort-of worked OK |
140 |
for grub1, getting the job done but managing it was quite complicated. |
141 |
By contrast, grub2 makes the boot and backup-boot md/raid management a |
142 |
BREEZE! =:^) |
143 |
|
144 |
But the four drives, two as my main /boot, and the other two as a backup |
145 |
/boot, makes upgrading grub a very nearly risk-free exercise, especially |
146 |
with GPT and a dedicated BIOS partition for grub2 to use as well. =:^) I |
147 |
have the following set in /etc/portage/env/sys-boot/grub: |
148 |
|
149 |
# To keep grub from trying to mount /boot, |
150 |
# on a normally deactivated md. |
151 |
DONT_MOUNT_BOOT=1 |
152 |
|
153 |
# Just to be safe, since I handle this myself |
154 |
INSTALL_MASK="$INSTALL_MASK /etc/default /etc/grub.d grub2-mkconfig" |
155 |
PKG_INSTALL_MASK="$INSTALL_MASK" |
156 |
|
157 |
|
158 |
I don't know what the package would do if I didn't set the dont-mount |
159 |
var, as it can't mount it anyway, since that md/raid device is normally |
160 |
not active/assembled. But with that, it won't even try it. |
161 |
|
162 |
That means the grub ebuild simply merges it to /usr/* as it normally |
163 |
would, and leaves /boot alone. |
164 |
|
165 |
Then I activate the main boot md and mount it, and run grub2-install |
166 |
/dev/sda (the first of the four drives, normally set in BIOS to boot) |
167 |
myself. |
168 |
|
169 |
Then I reboot. If it doesn't work, I can set the BIOS to boot from sdc |
170 |
or sdd instead, where the backup boot is located, with a grub that's |
171 |
still the older version. I can then either fix the issue or revert to |
172 |
the older grub, from the backup boot. |
173 |
|
174 |
When I'm satisfied that the first install is working correctly, then I |
175 |
assemble the raid and mount the main /boot again, and run grub2-install |
176 |
/dev/sdb (the second spindle on the main /boot). Then I unmount/stop it |
177 |
and assemble and mount the boot backup md/raid, and run grub2-install |
178 |
for /dev/sdc and /dev/sdd. |
179 |
|
180 |
As you can see from the above INSTALL_MASKs I handle the configuration |
181 |
manually. grub2-mkconfig is all but worthless on my system, taking |
182 |
longer to install a simple config file than the kernel does to BUILD, or |
183 |
at least it did when I tried it back on grub-1.99. When I profiled/ |
184 |
traced the problem thru the script, it was due to about 50 calls at ~10 |
185 |
seconds each to grub-probe! |
186 |
|
187 |
So before I test the backup boot and new grub install to it, I copy over |
188 |
any grubenv or *.cfg changes from the main boot to the backup boot. |
189 |
|
190 |
Then I can reboot again, setting the BIOS to boot from the third or |
191 |
fourth drive, to test that. Once that's tested, I reboot once more and |
192 |
set the BIOS back to booting from the first drive and main /boot. |
193 |
|
194 |
|
195 |
So as you can see, upgrading grub isn't any more dangerous for me than |
196 |
upgrading any other package on the system, especially something like |
197 |
openrc, which as I said, I run the live version of and generally upgrade |
198 |
a couple times a week. Grub does happen to be a bit more work to |
199 |
upgrade, since unlike the rest of the system, at least at this point in |
200 |
grub2's life, I upgrade on both the main and backup together, tho only |
201 |
after testing main. For other packages, I only upgrade the backup once |
202 |
every few months, after I've rebooted since the last upgrade thereby |
203 |
testing that, and everything, all the daemons and bootscripts, xorg/mesa, |
204 |
kde, etc, seems to be running normally, preferably when I'm running a |
205 |
full kde release version, not a prerelease, which I'm now doing about two |
206 |
months out of every six. |
207 |
|
208 |
-- |
209 |
Duncan - List replies preferred. No HTML msgs. |
210 |
"Every nonfree program has a lord, a master -- |
211 |
and if you use the program, he is your master." Richard Stallman |