Mark Knecht posted on Thu, 27 Jun 2013 13:52:18 -0700 as excerpted:
> Looking at caps, xattr & filecaps I don't appear to have them selected
> on any packages. (equery hasuse ..., emerge -pv ...)
>
> Similar results as yours for the zgrep:
> With that in mind I may well have needed the -X on the rsync.
Since you don't have any packages with caps/xattr/filecaps set in USE,
you're probably fine in that regard -- you were correct that you didn't
need it. However, as I said, the -X won't hurt.
> However as
> I didn't get a quick response I decided this was a background issue for
> me in a sense.
Makes sense.
> However, I think your comments about gpt & grub2 are VERY good points
> and might work out in my favor long term. I only used 2 partitions on
> the SDD - one for a new boot partition and one for /, my thought being
> that if I installed grub on the SDD then in BIOS I could point at
> /dev/sda to boot off the SDD instead of /dev/sdb. As I think about your
> comments, I could consider backing up the SDD install using rsync -aAvx,
> converting to gpt & grub2 on that device, do my learning and it doesn't
> have to impact my current setup at all. That can all stay on the hard
> drives until I'm ready to get rid of it. It's just a flip of a switch in
> BIOS as to which one I'm using.
That's a good idea.
Two other comments/suggestions regarding grub1 -> grub2 conversion.
1) I found it *EXTREMELY* useful when I was learning grub2, to have two
bootable devices setup, with just a BIOS selector switch to switch
between them, keeping my normal boot setup grub1 until I was pretty much
done experimenting with grub2 on the other one and had it setup the way I
wanted. After I could boot to grub2 and from it to my normal Linux
setup, then and only then did I blow away the grub1 setup that I had been
using for backup while I experimented with grub2. Of course now I have
all three of my current bootable devices (the pair of SSDs and the
spinning rust as backup) configured with separate grub2 instances, so I
can boot to grub2 from any of the three, and from the grub2, load the
kernel and boot to any of my five root filesystems (the primary and
backup btrfs raid1 mode roots on the pair of ssds, and any of the three
roots, primary and first and second backup of the rootfs on the spinning
rust, which I've yet to repartition now that I have the ssds up and
running, tho I intend to at some point, but there's no hurry).
That's FAR less nerve-racking than trying to be sure that you got it
correct enough to at least boot far enough to correct any remaining
issues, on the single working bootable device available, that can be
either grub1 or grub2, but can't have both installed and working at the
same time!
Of course for those without a second installed primary boot device, it's
possible to do the same thing with a USB stick, which is what I probably
would have done if I didn't have the extra installed boot devices around
to try. But either way, leave the existing grub1 alone while you
experiment with grub2 on a different device, only blowing away grub1 once
you have grub2 configured and booting to your satisfaction.
2) There's two methods available for configuring grub2, the automated/
scripted method, and the direct grub.cfg edit method. Certainly YMMV,
but here, the automated/scripted method just didn't cut it. I did use it
for the initial automated conversion from grub1 and the initial bare-
bones grub2 functionality test, to see that it was working at all, but
after that, I quickly switched to the far more powerful direct edit
method, as all I was getting from the automated/scripted method was
frustrated.
Of course most of the documentation and howtos out there are based on the
scripted method. There's certainly info available for the direct edit
method, including the grub info pages installed with the package itself
and the manual on the grub web site if you prefer that to trying to
navigate info pages, but as they're designed more for experts and distro
maintainers than ordinary users (who are expected to use the scripted
interface), the documentation does tend to be a bit vague at various
points.
Which is why I ended up doing a lot of experimentation, because I knew
that there was a command to do basically what I wanted, but finding
either nice examples or command specifics wasn't always easy, so I had to
look stuff up, then reboot to grub to try it, then boot thru grub to the
main system to be able to either look more stuff up or write out to
permanent config the bit I'd just figured out in grub by trying it.
So I don't claim that my grub2 config is the be all and end all of grub
configs, but if/when it comes time for someone to upgrade, just ask, and
I can post it, to give people some nice real-world working grub config
code examples to follow, the same ones I had such a hard time finding and
that I often had to simply try it out until I figured out the bits that
the info pages didn't really describe in what I'd call a useful way.
Similarly, if you have grub2 config command questions, post them, as it's
reasonably likely I've asked myself the same sorts of questions, and
ultimately gave up googling for the answer and just tried it until I got
it working.
Finally, my initial "final" grub2 config was powerful, but brittle and
inflexible in some aspects. What I ended up with on the second go round
(well, we'll call it config version 2.1 now, as I just today modified it
just a bit further after my initr* experiments, which revealed a weakness
with version 2.0) is far more flexible, with far less brainlessly
duplicated menu option boilerplate for a dozen different menu options
doing very small variants of what's otherwise the exact same thing.
Basically, I originally had it setup in a menu tree like this:
current kernel primary root
fallback kernel primary root
backups menu
primary root
current kernel
fallback kernel
stable kernel
backup root
current kernel
fallback kernel
stable kernel
backup2 root
current kernel
fallback kernel
stable kernel
init=/bin/bash
primary root
current kernel
fallback kernel
stable kernel
backup root
current kernel
fallback kernel
stable kernel
backup2 root
current kernel
fallback kernel
stable kernel
single mode
primary root
current kernel
fallback kernel
stable kernel
backup root
current kernel
fallback kernel
stable kernel
backup2 root
current kernel
fallback kernel
stable kernel
utils menu
reboot
halt
boothints
cat boothints1
cat boothints2
cat boothints3
Now instead of that I have something more like this, much shorter but
also much more flexible!:
current kernel primary root
backups menu
boot
set kernel.current
set kernel.fallback
set kernel.stable
set root.ssd.primary
set root.ssd.secondary
set root.rust.1
set root.rust.2
set root.rust.3
set opts.initbash
set opts.single
set opts.other
reset opts
utils menu
reboot
halt
boothints
browse
So now the initial menu only has three items on it, current boot,
backups, and utils. There's a timeout on the default current boot, so if
I do nothing, it'll boot that without interference.
The backups menu allows me to set different options for kernel, root, and
general options, or clear the existing general options so defaults are
used. When I'm satisfied with the changes I've selected, I choose the
boot option, which echoes the kernel command line it'll execute and
prompts for confirmation, then executes if I give it.
The kernel and root options overwrite any value previously set, while the
general options don't overwrite each other, so there's a reset option for
that. Note that this way, I have far more flexibility with far less
duplicated config, just by selecting the options I want, then hitting the
boot option to actually prompt for confirmation and then boot. Before, I
couldn't select BOTH single mode AND init=/bin/bash; now I can (tho why
one might want both remains an open question, since single mode with bash
as init does nothing). And now I have five root options instead of
three, with less code duplication to do it.
For the general options, initbash simply sets init=/bin/bash, and single
simply sets s, to boot into single user mode. Other options simply
prompts for manual entry of additional options, as desired. (opts.other
is the option I just added today, thus my call it config version 2.1
comment above. Now I don't need to switch to commandline mode just to
add another option to my kernel commandline, as I can simply select that
menu option and type it in there, before selecting the boot option,
confirming that I typed it correctly with the echoed to-be-run kernel
comandline, and booting.)
On the utils menu, reboot and halt allow me to do that directly from
grub. That makes it possible to simply hit the three-finger salute (aka
ctrl-alt-del) from in linux to reboot, then select halt in grub, if I'm
lazy and would rather do that than reach up to the power button to
trigger a system shutdown that way.
I initially setup grub2 before grub2's final release, while it was still
in beta. One of the betas screwed up the pager functionality, so I had
to split my boothints (kernel commandline options I might find useful)
notes into several pages, each of which could fit a single screen. Of
course that bug was fixed in the general grub2 release, so a single
boothints option allows me to page thru a combined longer boothints file,
now.
And the browse option... uses grub2's search by label command to
automatically set some variables appropriately, so instead of manually
figuring out which (gpt0,X) value to use to get say the first backup home
partition on spinning rust, I can simply use the browse option to set all
the vars, then switch to the grub2 commandline and do something like this:
set
(shows me a list of set vars, so I can pick the one to use)
cat $hmr1/user/.bashrc
(Prints out the selected file, automatically stopping at each screenfull
if the pager var is set, as mine is by default. If that partition/volume
happens to be on raid or lvm or whatever, or some exotic filesystem like
btrfs or zfs as long as there's a grub2 module for it (as there is for
those two), or if it's a compressed file, grub has modules for some types
of compression too, a load of the appropriate grub2 modules will let the
grub search by label and cat functions work just as they would on a
partition directly on the hardware itself, so the file can still be
catted. =:^)
Like I said it's not necessarily the be-all and end-all of fancy bash
configurations, but it should give you a much more concrete idea of just
the sort of flexibility and power that grub2 has, and the type of setup
one can configure if desired.
--
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
