[gentoo-amd64] Re: Can initrd and/or RAID be disabled at boot?

[Duncan <1i5t5.duncan@cox.net>]

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