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
