[Cc Ben as he gave feedback to the last iteration, Luca as he wanted
something actionable]
Hi folks
As I abondened the last try and also learned some new things in the
meantime, I'd like to discuss another try at re-organizing how Debian
does boot loaders and initramfs. This mail mostly tries to get the goals
and requirements straight.
Please provide feedback. Also for missing stuff.
Regards,
Bastian
## Goals
- Setup complete boot entries from packaged and generated files
- Support dumb file systems for /boot by default, so boot loaders can
drop complex file system support.
- Re-create stuff in /boot from scratch
- Remove symlink handling from kernel package
- Single entry point for packages and admins, aka no tool specific
"update-initramfs" anymore
## Requirements
- Read package files in /usr
- Uses observed state, not changes provided by maintainer scripts
- Dumb writes to /boot. No rename, no sym, hard links. Can use ref
links if possible.
- Generate initramfs if needed, creates new entry if re-generated
- Keep older stuff (like previous kernel, initramfs) for a short while
- Possible to support multiple targets, like grub, zipl, flash-kernel
- Multiple inputs, plain kernel, UKI, also in one version
- Combinations of inputs, Xen+Linux
- Completely outside of kernel package
- Backward compatible support for stuff packaged in /boot
- Use config for kernel command line
## Open questions
- How to select default entry if supported, just sort by version and use
newest? This also works somewhat in BLS.
- How to interface with boot loaders, just absorb all knowledge about
config and only run install tools if necessary (like with zipl as
block map based loader)? grub might get support for BLS, at least
there exists a patch somewhere, that will make it easier, and we can
just iterate over config files defining one entry each.
## Prior works
- Current Debian: change based, overwrites by dpkg in /boot, versioned
by ABI
- systemd install-kernel: only BLS as target, which nothing used by
default in Debian can read
More?
## File system layout
Some initial ideas about how stuff could look.
### Boot file system (/boot)
This file system might be shared, so everything is somewhat referenced
to the machine id. This should be somewhat compatible with BLS (type
1).
* /boot/$machineid/
* ./grub/: config snippets, so we can do "no overwrite"
### Distribution file system (/usr)
* /usr/lib/boot/$package(_$modifier)/
* ./data: raw data for item
* ./metadata: info about item in undetermined format
--
I'm a soldier, not a diplomat. I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9
