[gentoo-dev] Re: Need design help/input for eclean-kernel

[Duncan]

Michał Górny posted on Thu, 30 Jun 2016 14:38:26 +0200 as excerpted:

> [P]lease reply to this thread with
> a specific /boot layout that you think needs to be handled, with as much
> helpful information as possible -- including possible distinctive
> features and pitfalls.

This is surely more info than you need, but I imagine it's one of the 
more unique and complex layouts you'll see and thus might need additional 
explanation for some bits.  Trouble is I don't know which bits, so...

I have never used eclean-kernel and probably won't as I have my own 
scripts to handle things (as I was doing even back over a decade ago on 
mandrake, before I switched to gentoo), but here's the layout, in case 
you find it useful (or a fun challenge? =:^) to support.

So what I have for boot:

/boot itself is a symlink, normally pointing at /bt, the mountpoint for 
my working boot partition, but setup with /boot as a symlink so I can 
point it at /bk/bt, where I can mount my backup boots on other devices, 
when I want to install grub to them.

/bt, LABEL=bt0238gcn1+35l0 : working boot mountpoint and filesystem when 
mounted, where the /boot symlink normally points.  Filesystem is btrfs 
mixed-blockgroup dup mode.  This is a partition on one of a pair of 238 
GiB (256 GB) Corsair Neutron SSDs.


/bk/bt: mountpoint for my backup boots.  The /boot symlink can be 
adjusted to point here when I want to install grub to one of the backup 
boots.

LABEL=bt0238gcn0+35l1 : primary backup boot filesystem, also btrfs mixed-
blockgroup dup, a partition on the other one of the pair of 238 GiB SSDs.

LABEL=bt0465gsg0+47f0 : secondary backup boot filesystem, reiserfs on a 
partition on a 465 GiB spinning rust seagate.

Various other removable drives and their labels for further backups...

All bootable storage (including removable) is GPT partitioned with both a 
legacy-BIOS partition to which grub2 is installed and an EFI partition 
reserved for future use.  Each installed grub points at the /bt boot 
partition on that device, so I can at least get both a grub prompt and a 
bootable kernel on any of them, even with all other storage 
disconnected.  From there it's up to where I point the kernel using root= 
on the kernel commandline, but FWIW, each grub is configured with a menu 
from which I can choose any of my working or primary or secondary backup 
root.

On each of these boot partitions the filesystem layout is:

amd64/
	64-bit kernels, configs, system-maps, symlinks...

boot -> .

grub/

[x86/]
	[when I had the 32-bit netbook, this was its kernels, etc.]

[A single zero-length file named working, backup, backup2, etc, so I can 
easily confirm which one I actually booted to when testing an updated 
grub install or the like.]


The kernel dirs are laid out as...

$$ ls -1 /bt/amd64

config@
config-4.5.0-dirty
config-4.6.0-dirty
config-4.6.0-rc7-00096-g685764b10-dirty
config.old@
config.stable@
System.map@
System.map-4.5.0-dirty
System.map-4.6.0-dirty
System.map-4.6.0-rc7-00096-g685764b10-dirty
System.map.old@
System.map.stable@
vmlinuz@
vmlinuz-4.5.0-dirty
vmlinuz-4.6.0-dirty
vmlinuz-4.6.0-rc7-00096-g685764b10-dirty
vmlinuz.old@
vmlinuz.stable@


That's three symlinks for each of the map, config and kernel.  They point 
to current, old (previous) and stable.  Since I often test/run and 
occasionally bisect git kernels, current and old often point to git and 
perhaps bisect-bad kernels, and during a bisect I may have nearly a dozen 
kernels and associated files, tho my scripts only maintain the current/
old symlinks.  I update the stable symlink manually, when I consider a 
released version tested well enough locally to be confident doing so.

Only the working boot gets the git kernels.  I update the primary backup 
with the new release-stables each kernel cycle, and only update the 
secondary backup every few kernel cycles.

The git kernel testing and bisects are why I prefer to do my own kernel 
cleanups.  That way I can keep the first git kernel I saw the problem in 
around until I get around to doing a bisect, if the problem hasn't been 
caught and fixed upstream by then, making the bisect easier than it would 
be if I kept updating to see if the problem was fixed, losing track of 
the first bad kernel I saw in the process and thus perhaps forcing 
another round or two of bisection to track down the problem.

And for sure I don't want anything touching the stable symlinks but me, 
manually, when I am sufficiently confident I can do so and won't be left 
in a hole without an easy way to dig myself out as a result.

I use a dracut-built initr*, compressed and appended as an initramfs to 
each kernel built and tested, so once I know the kernel/initramfs 
combination work, I don't have to worry about a buggy initr* update 
breaking older kernels as they have their initramfs builtin.  The dracut-
built initr* is kept on a different filesystem in ordered to leave more 
room in the boot and backups for kernels.


More detailed explanation of likely unique characteristics, and why...:

Most of my primary filesystems are btrfs raid1 (and were on mdraid1 
before that), with a working copy and a primary and secondary backup, all 
on similarly sized partitions, working and primary backup on a pair of 
SSDs, secondary backup on spinning rust.

That doesn't work for /boot, since grub1 (where I originally setup the 
scheme) can only point at one with no way to point at the backup instead, 
and while grub2 can manually load a different /boot, it's extra trouble, 
and I already had the scheme setup and working by then, so I kept what 
worked.

In ordered to facilitate all this, /boot itself is a symlink, that points 
to /bt normally, or to /bk/bt, where I mount the backups if I want to 
install grub to them.  (I simply copy-backup /boot to the backups as 
appropriate, but grub has to be installed to the legacy bios partition on 
each device separately, so I need to switch the /boot symlink temporarily 
when I'm installing grub to the backup devices.)

And I keep track of all working and backups of the various filesystems 
via standardized 15-character LABEL (which I list in fstab to mount by) 
that looks something like this:

bt0238gcn1+35l0

bt=boot (rt=root, hm=home, etc)

0238g=0238 gig

cn=corsair neutron (brand)

1=second 238-gig corsair neutron (0-base)

+=workstation permanent installed (it's also a visual separator)

35l=2013 (last repartitioning), May (5th month), l=day-of-month

0=working copy (on that device at least).

FWIW, filesystem and gpt partition labels are kept in sync (but for the 
device number on raid, of course) so I can uniquely ID within my own 
storage inventory on sight by either one.

bt0238gcn0+35l1 is the backup boot (the tailing 1) on the other 238-gig 
corsair neutron ssd. (Yes, I did put the working boot on device 1, the 
first backup on device 0, oh, well...)  bt0465gsg0+47f0 is the secondary 
backup boot, on the first spinning rust 465-gig seagate, last 
repartitioned in July of 2014.  FWIW, the three roots are rt0238gcnx+35l0 
(working, x in the device number slot as it's a pair-device btrfs raid1), 
rt0238gcnx+35l1 (primary backup), and rt0465gsg0+47f0 (secondary backup, 
but the first rt on the first 465-gig seagate, thus the trailing 0).

Additionally, given the 32-bit netbook I had at one point, and the fact 
that I wanted a standardized /boot layout that would work with both 32-
bit and 64-bit kernels, on both permanently installed drives and USB 
devices that might be used to boot either one, my boot layouts have the 
kernels in dedicated subdirs, in my case, /boot/amd64, and when I had the 
netbook, /boot/x86.  (I used the 64-bit machine with a 32-bit chroot as 
the 32-bit build, so my kernel build scripts had logic/config that looked 
at $HOSTTYPE, IIRC, to decide which kernel to build, which working output 
dir to use, and where to install the kernel.)

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