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
