1 |
Mark Knecht posted on Thu, 27 Jun 2013 13:52:18 -0700 as excerpted: |
2 |
|
3 |
> Looking at caps, xattr & filecaps I don't appear to have them selected |
4 |
> on any packages. (equery hasuse ..., emerge -pv ...) |
5 |
> |
6 |
> Similar results as yours for the zgrep: |
7 |
|
8 |
> With that in mind I may well have needed the -X on the rsync. |
9 |
|
10 |
Since you don't have any packages with caps/xattr/filecaps set in USE, |
11 |
you're probably fine in that regard -- you were correct that you didn't |
12 |
need it. However, as I said, the -X won't hurt. |
13 |
|
14 |
> However as |
15 |
> I didn't get a quick response I decided this was a background issue for |
16 |
> me in a sense. |
17 |
|
18 |
Makes sense. |
19 |
|
20 |
> However, I think your comments about gpt & grub2 are VERY good points |
21 |
> and might work out in my favor long term. I only used 2 partitions on |
22 |
> the SDD - one for a new boot partition and one for /, my thought being |
23 |
> that if I installed grub on the SDD then in BIOS I could point at |
24 |
> /dev/sda to boot off the SDD instead of /dev/sdb. As I think about your |
25 |
> comments, I could consider backing up the SDD install using rsync -aAvx, |
26 |
> converting to gpt & grub2 on that device, do my learning and it doesn't |
27 |
> have to impact my current setup at all. That can all stay on the hard |
28 |
> drives until I'm ready to get rid of it. It's just a flip of a switch in |
29 |
> BIOS as to which one I'm using. |
30 |
|
31 |
That's a good idea. |
32 |
|
33 |
Two other comments/suggestions regarding grub1 -> grub2 conversion. |
34 |
|
35 |
1) I found it *EXTREMELY* useful when I was learning grub2, to have two |
36 |
bootable devices setup, with just a BIOS selector switch to switch |
37 |
between them, keeping my normal boot setup grub1 until I was pretty much |
38 |
done experimenting with grub2 on the other one and had it setup the way I |
39 |
wanted. After I could boot to grub2 and from it to my normal Linux |
40 |
setup, then and only then did I blow away the grub1 setup that I had been |
41 |
using for backup while I experimented with grub2. Of course now I have |
42 |
all three of my current bootable devices (the pair of SSDs and the |
43 |
spinning rust as backup) configured with separate grub2 instances, so I |
44 |
can boot to grub2 from any of the three, and from the grub2, load the |
45 |
kernel and boot to any of my five root filesystems (the primary and |
46 |
backup btrfs raid1 mode roots on the pair of ssds, and any of the three |
47 |
roots, primary and first and second backup of the rootfs on the spinning |
48 |
rust, which I've yet to repartition now that I have the ssds up and |
49 |
running, tho I intend to at some point, but there's no hurry). |
50 |
|
51 |
That's FAR less nerve-racking than trying to be sure that you got it |
52 |
correct enough to at least boot far enough to correct any remaining |
53 |
issues, on the single working bootable device available, that can be |
54 |
either grub1 or grub2, but can't have both installed and working at the |
55 |
same time! |
56 |
|
57 |
Of course for those without a second installed primary boot device, it's |
58 |
possible to do the same thing with a USB stick, which is what I probably |
59 |
would have done if I didn't have the extra installed boot devices around |
60 |
to try. But either way, leave the existing grub1 alone while you |
61 |
experiment with grub2 on a different device, only blowing away grub1 once |
62 |
you have grub2 configured and booting to your satisfaction. |
63 |
|
64 |
2) There's two methods available for configuring grub2, the automated/ |
65 |
scripted method, and the direct grub.cfg edit method. Certainly YMMV, |
66 |
but here, the automated/scripted method just didn't cut it. I did use it |
67 |
for the initial automated conversion from grub1 and the initial bare- |
68 |
bones grub2 functionality test, to see that it was working at all, but |
69 |
after that, I quickly switched to the far more powerful direct edit |
70 |
method, as all I was getting from the automated/scripted method was |
71 |
frustrated. |
72 |
|
73 |
Of course most of the documentation and howtos out there are based on the |
74 |
scripted method. There's certainly info available for the direct edit |
75 |
method, including the grub info pages installed with the package itself |
76 |
and the manual on the grub web site if you prefer that to trying to |
77 |
navigate info pages, but as they're designed more for experts and distro |
78 |
maintainers than ordinary users (who are expected to use the scripted |
79 |
interface), the documentation does tend to be a bit vague at various |
80 |
points. |
81 |
|
82 |
Which is why I ended up doing a lot of experimentation, because I knew |
83 |
that there was a command to do basically what I wanted, but finding |
84 |
either nice examples or command specifics wasn't always easy, so I had to |
85 |
look stuff up, then reboot to grub to try it, then boot thru grub to the |
86 |
main system to be able to either look more stuff up or write out to |
87 |
permanent config the bit I'd just figured out in grub by trying it. |
88 |
|
89 |
So I don't claim that my grub2 config is the be all and end all of grub |
90 |
configs, but if/when it comes time for someone to upgrade, just ask, and |
91 |
I can post it, to give people some nice real-world working grub config |
92 |
code examples to follow, the same ones I had such a hard time finding and |
93 |
that I often had to simply try it out until I figured out the bits that |
94 |
the info pages didn't really describe in what I'd call a useful way. |
95 |
|
96 |
Similarly, if you have grub2 config command questions, post them, as it's |
97 |
reasonably likely I've asked myself the same sorts of questions, and |
98 |
ultimately gave up googling for the answer and just tried it until I got |
99 |
it working. |
100 |
|
101 |
Finally, my initial "final" grub2 config was powerful, but brittle and |
102 |
inflexible in some aspects. What I ended up with on the second go round |
103 |
(well, we'll call it config version 2.1 now, as I just today modified it |
104 |
just a bit further after my initr* experiments, which revealed a weakness |
105 |
with version 2.0) is far more flexible, with far less brainlessly |
106 |
duplicated menu option boilerplate for a dozen different menu options |
107 |
doing very small variants of what's otherwise the exact same thing. |
108 |
|
109 |
Basically, I originally had it setup in a menu tree like this: |
110 |
|
111 |
current kernel primary root |
112 |
fallback kernel primary root |
113 |
backups menu |
114 |
primary root |
115 |
current kernel |
116 |
fallback kernel |
117 |
stable kernel |
118 |
backup root |
119 |
current kernel |
120 |
fallback kernel |
121 |
stable kernel |
122 |
backup2 root |
123 |
current kernel |
124 |
fallback kernel |
125 |
stable kernel |
126 |
init=/bin/bash |
127 |
primary root |
128 |
current kernel |
129 |
fallback kernel |
130 |
stable kernel |
131 |
backup root |
132 |
current kernel |
133 |
fallback kernel |
134 |
stable kernel |
135 |
backup2 root |
136 |
current kernel |
137 |
fallback kernel |
138 |
stable kernel |
139 |
single mode |
140 |
primary root |
141 |
current kernel |
142 |
fallback kernel |
143 |
stable kernel |
144 |
backup root |
145 |
current kernel |
146 |
fallback kernel |
147 |
stable kernel |
148 |
backup2 root |
149 |
current kernel |
150 |
fallback kernel |
151 |
stable kernel |
152 |
utils menu |
153 |
reboot |
154 |
halt |
155 |
boothints |
156 |
cat boothints1 |
157 |
cat boothints2 |
158 |
cat boothints3 |
159 |
|
160 |
|
161 |
Now instead of that I have something more like this, much shorter but |
162 |
also much more flexible!: |
163 |
|
164 |
current kernel primary root |
165 |
backups menu |
166 |
boot |
167 |
set kernel.current |
168 |
set kernel.fallback |
169 |
set kernel.stable |
170 |
set root.ssd.primary |
171 |
set root.ssd.secondary |
172 |
set root.rust.1 |
173 |
set root.rust.2 |
174 |
set root.rust.3 |
175 |
set opts.initbash |
176 |
set opts.single |
177 |
set opts.other |
178 |
reset opts |
179 |
utils menu |
180 |
reboot |
181 |
halt |
182 |
boothints |
183 |
browse |
184 |
|
185 |
|
186 |
So now the initial menu only has three items on it, current boot, |
187 |
backups, and utils. There's a timeout on the default current boot, so if |
188 |
I do nothing, it'll boot that without interference. |
189 |
|
190 |
The backups menu allows me to set different options for kernel, root, and |
191 |
general options, or clear the existing general options so defaults are |
192 |
used. When I'm satisfied with the changes I've selected, I choose the |
193 |
boot option, which echoes the kernel command line it'll execute and |
194 |
prompts for confirmation, then executes if I give it. |
195 |
|
196 |
The kernel and root options overwrite any value previously set, while the |
197 |
general options don't overwrite each other, so there's a reset option for |
198 |
that. Note that this way, I have far more flexibility with far less |
199 |
duplicated config, just by selecting the options I want, then hitting the |
200 |
boot option to actually prompt for confirmation and then boot. Before, I |
201 |
couldn't select BOTH single mode AND init=/bin/bash; now I can (tho why |
202 |
one might want both remains an open question, since single mode with bash |
203 |
as init does nothing). And now I have five root options instead of |
204 |
three, with less code duplication to do it. |
205 |
|
206 |
For the general options, initbash simply sets init=/bin/bash, and single |
207 |
simply sets s, to boot into single user mode. Other options simply |
208 |
prompts for manual entry of additional options, as desired. (opts.other |
209 |
is the option I just added today, thus my call it config version 2.1 |
210 |
comment above. Now I don't need to switch to commandline mode just to |
211 |
add another option to my kernel commandline, as I can simply select that |
212 |
menu option and type it in there, before selecting the boot option, |
213 |
confirming that I typed it correctly with the echoed to-be-run kernel |
214 |
comandline, and booting.) |
215 |
|
216 |
On the utils menu, reboot and halt allow me to do that directly from |
217 |
grub. That makes it possible to simply hit the three-finger salute (aka |
218 |
ctrl-alt-del) from in linux to reboot, then select halt in grub, if I'm |
219 |
lazy and would rather do that than reach up to the power button to |
220 |
trigger a system shutdown that way. |
221 |
|
222 |
I initially setup grub2 before grub2's final release, while it was still |
223 |
in beta. One of the betas screwed up the pager functionality, so I had |
224 |
to split my boothints (kernel commandline options I might find useful) |
225 |
notes into several pages, each of which could fit a single screen. Of |
226 |
course that bug was fixed in the general grub2 release, so a single |
227 |
boothints option allows me to page thru a combined longer boothints file, |
228 |
now. |
229 |
|
230 |
And the browse option... uses grub2's search by label command to |
231 |
automatically set some variables appropriately, so instead of manually |
232 |
figuring out which (gpt0,X) value to use to get say the first backup home |
233 |
partition on spinning rust, I can simply use the browse option to set all |
234 |
the vars, then switch to the grub2 commandline and do something like this: |
235 |
|
236 |
set |
237 |
|
238 |
(shows me a list of set vars, so I can pick the one to use) |
239 |
|
240 |
cat $hmr1/user/.bashrc |
241 |
|
242 |
(Prints out the selected file, automatically stopping at each screenfull |
243 |
if the pager var is set, as mine is by default. If that partition/volume |
244 |
happens to be on raid or lvm or whatever, or some exotic filesystem like |
245 |
btrfs or zfs as long as there's a grub2 module for it (as there is for |
246 |
those two), or if it's a compressed file, grub has modules for some types |
247 |
of compression too, a load of the appropriate grub2 modules will let the |
248 |
grub search by label and cat functions work just as they would on a |
249 |
partition directly on the hardware itself, so the file can still be |
250 |
catted. =:^) |
251 |
|
252 |
Like I said it's not necessarily the be-all and end-all of fancy bash |
253 |
configurations, but it should give you a much more concrete idea of just |
254 |
the sort of flexibility and power that grub2 has, and the type of setup |
255 |
one can configure if desired. |
256 |
|
257 |
-- |
258 |
Duncan - List replies preferred. No HTML msgs. |
259 |
"Every nonfree program has a lord, a master -- |
260 |
and if you use the program, he is your master." Richard Stallman |