[gentoo-amd64] Re: grub2 upgrade fail (was Boycott Systemd)

[Duncan]

Barry Schwartz posted on Tue, 23 Sep 2014 00:50:51 -0500 as excerpted:

> Expanding on this:
>> From: Barry Schwartz <chemoelectric@×××××××××××××.org>
>> Date: Tue, 23 Sep 2014 00:42:44 -0500
>>
>> Antoine Martin <antoine@××××××××××.uk> skribis:
>>> "Simple" and the large collection of scripts that is grub2 is not
>>> something I often hear in the same sentence ;)
>>
>> I don’t use any of the scripts, and just have a very simple, hand
>> edited grub config file.
>
> See http://exherbo.org/docs/install-guide.html for how simple it can be
> to use GRUB 2, if you just ignore the hoopla. My own config is more
> complicated; it installs some fonts and has entries for memtest; but
> these are minor niceties.

When I installed grub2 I was running four drives in (mdraid) raid1 mode.  
While most of the system was 4-way raid1, I already had my /boot as two-
way raid1, with a backup /boot on a second two-device raid1.  That 
allowed me to update one grub and/or /boot at a time, leaving the other 
one in place and changing much more slowly.  I run git kernels and 
normally load another git kernel on the "working" /boot every few days, 
updating the backup only with the .0 stable kernel releases.  (I don't 
usually bother with the stable-series .1, and usually switch to the new 
development kernel about the time stable .2 or .3 comes out, so the .0 
releases are my "stable" kernels.)

Between that and the fact that I was already running GPT partitions and 
had already reserved a BIOS partition for grub2's usage when I switched 
to GPT, made the switch to grub2 reasonably easy.

But I too don't use the scripts, and indeed, have the primary scripted 
installer install-masked, so there's no way anything could /possibly/ run 
it accidentally, as it simply doesn't exist /to/ run!

And my grub2 native scripted config is probably one of the more complex 
ones here.  My grub.cfg is a short stub that primarily sets up the main 
grub menu and exports a few vars, with only the primary boot and a couple 
submenus listed on the initial boot menu.

The first submenu is backups.  This loads another config file that lets 
me choose from several kernels (primary, backup, stable, all set in grub 
vars and I simply assign the appropriate one to the bootkernel var), 
choose which root I'm going to boot (working, primary backup, secondary 
backup on another device, again, all set in vars so selecting one simply 
loads the rootselect var from the appropriate one), choose whether I'm 
going to boot systemd or bash as pid1/init (again via vars, with the 
default of course openrc previously, and with both openrc and systemd 
available for awhile when I switched), and yet another choice that gives 
me a prompt to fill in additional kernel-commandline options if I want to 
(again assigned to a grub var, that's normally null).  Finally, there's a 
reset option that resets all these choices back to the defaults, if I 
screw up on one of them.

Actual booting, whether the default boot as chosen from the initial menu, 
or from the backups submenu, loads yet another config file, that simply 
loads all those vars into the appropriate place in the kernel command and 
runs it.  Additionally, it detects (via another var) whether I'm loading 
it from the backups submenu/config, or the default boot, from the main 
menu/config.  If it's the default it simply runs it, if it's loaded from 
the backups submenu, it loads all the vars and displays what it's going 
to do, asking me if that's correct, before actually running it.  If I 
tell it no, it loads the backups menu/config again and lets me try again.

The second submenu/config available from the primary menu is utils.  This 
contains built-in grub-command choices such as reboot/halt, a command 
that loads all my partitions into various vars so I can switch to grub-
command mode and browse arbitrary files from them (using the vars) if 
need be (good for loading the kernel dir to read about kernel commandline 
options if I'm troubleshooting! =:^), an entry that cats out (with the 
grub-pager activated) my grub-notes files with various useful grub and 
kernel-commandline options I've discovered over the years, etc.

Of course I could switch to grub-commandline mode and do most of these 
same things, including directly editing the kernel commandline that grub 
will hand off, but it's nice to have the choices all setup in a nice menu-
based system so I can simply select the appropriate ones, instead. =:^)

And because it's all grub-var based, with many of the basic choices 
already preset in grubenv, changing many of the settings is simply a 
matter of mounting /boot and running grub-editenv from a terminal. =:^)

> (Completely avoiding initrd by simply putting / and /usr on one
> filesystem is another of those measures you wouldn’t think existed if
> your experience were entirely Ubuntu, etc.)

That's how my system is setup, not to avoid an initr* altho it's nice for 
that, but rather, so that everything installed by portage is on the same 
partition as the portage installation database (/var/db/pkg).  I learned 
to do that the hard way, after having a drive die and having to recover 
from backups, but with the backup for /, /var, and /usr, being three 
different backups created at different times, so when I had finished 
restoring from backup, the installed-package database didn't match what 
was actually on / and /usr!  I was still cleaning up from that fiasco, 
finding stale files that hadn't been updated because portage lost track 
of them due to all this, over a year later!

I vowed never again!  So now most of /var along with most of /usr, pretty 
much everything portage installs, is on /, along with the database 
tracking it.  That way, whatever backup I end up booting to and restoring 
from, the installed-package database will match it, because it's on the 
same backup! =:^)

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