Re: Debian Kernel version and ABI in respect of #1040901
On Mon, Jul 24, 2023 at 10:36:47PM +0300, Adrian Bunk wrote: > A policy question is that it might be a good idea to rename the packages > when publishing a regression update for a DSA, that's the only place I see > where this problem might otherwise reach production systems. Adding another modifier later is easy, as long as the overall setup works. Bastian -- Oblivion together does not frighten me, beloved. -- Thalassa (in Anne Mulhall's body), "Return to Tomorrow", stardate 4770.3.
Re: Debian Kernel version and ABI in respect of #1040901
On Sun, Jul 23, 2023 at 09:44:40AM +0200, Bastian Blank wrote: > After a lot of thinking, maybe a solution that allows for incompatible > package updates without renames would be more useful. Something like: > > We uncouple the package names and ABI. The ABI will include the > complete version, so every rebuild will change it. The package names > can include just the upstream version, aka 6.1.1. And in addition: header and other support packages are not longer renamed. So they can only be installed once and need to be searched by the actual version of the image package. In any way, everything is weird and broken. We currently often run into uninstallable meta packages, due to the signing stuff adding a race condition between the availability of the header packages and the image packages. Then people tend to not reboot, so they are searching for older headers, which are already removed. And there is no really good solution. The only real solution would be to always bundle headers and images and install everything. But this will make everything 50MB larger and does not fit for things like the stripped down cloud kernels. Regards, Bastian -- What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, "Metamorphosis", stardate 3219.8
Re: Debian Kernel version and ABI in respect of #1040901
On Sun, Jul 23, 2023 at 09:44:40AM +0200, Bastian Blank wrote: >... > We uncouple the package names and ABI. The ABI will include the > complete version, so every rebuild will change it. That's also what I meant with "It should only be impossible to make them co-installable". > The package names > can include just the upstream version, aka 6.1.1. I am not convinced about that part in all cases. > This means: > - Every module will be compatible always only with the exact version. > - External modules needs rebuilds for every update of a image package. > > We already say: You need to reboot after kernel upgrade, because the ABI > only provides compatibility from older modules to newer kernels. This > would be now enforced by complete lack of compatibility. >... It is under our control when to not rename the packages, to prevent this issue for production systems. A binNMU for a perl transition might reach testing users, but these should not be production systems. When it takes 3 attempts in *stable-pu to get the kernel to build on all release architectures, only the last one will ever reach *stable. A policy question is that it might be a good idea to rename the packages when publishing a regression update for a DSA, that's the only place I see where this problem might otherwise reach production systems. > Regards, > Bastian cu Adrian
Re: Debian Kernel version and ABI in respect of #1040901
On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote: > Please share your thoughts or if we have a better solution overall. After a lot of thinking, maybe a solution that allows for incompatible package updates without renames would be more useful. Something like: We uncouple the package names and ABI. The ABI will include the complete version, so every rebuild will change it. The package names can include just the upstream version, aka 6.1.1. This means: - Every module will be compatible always only with the exact version. - External modules needs rebuilds for every update of a image package. We already say: You need to reboot after kernel upgrade, because the ABI only provides compatibility from older modules to newer kernels. This would be now enforced by complete lack of compatibility. In the end this is what the RedHat world does AFAIK. They can install multiple versions of the same package at the same time, so you have just "kernel" installed in multiple versions. Regards, Bastian -- Murder is contrary to the laws of man and God. -- M-5 Computer, "The Ultimate Computer", stardate 4731.3
Re: Debian Kernel version and ABI in respect of #1040901
On Fri, Jul 14, 2023 at 04:17:34PM +0200, Ben Hutchings wrote: > On Thu, 2023-07-13 at 21:16 +0200, Bastian Blank wrote: > [...] > > ## Proposed behaviour > > > > This tries to make sure everything apart from experimental gets new > > names and ABI on every upload. > > > > * experimental: > > Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4 > > Keep ABI 6.1.0-0-arm64 > Why would that still be acceptable in experimental? What do you mean? We don't check for any ABI incompatibilities forever in experimental builds. And the signature check will refuse to load modules not from the same build if lockdown is enabled. So the ABI as listed in the image and the package just means it is provided in the same package and can be upgraded directly. We can also decide that we don't want to make it that explicit and do: ABI/package name only includes upstream version (6.1.1) and multiple Debian revisions of that will be incompable to each other on lockdown systems, but may work (depending on symvers) on non-lockdown systems. It does not happen often that we do multiple Debian revisions of most upstream version anyway, so people will only feel that if they upgrade directly from backports to a different release of the same version. Bastian -- Fascinating, a totally parochial attitude. -- Spock, "Metamorphosis", stardate 3219.8
Re: Debian Kernel version and ABI in respect of #1040901
Hi On Thu, Jul 13, 2023 at 11:28:31PM +0300, Adrian Bunk wrote: > On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote: > > ### NMU > > Can be easily added back by adding "bX" or so to the ABI. > That would be confusing, bX is naming convention for binNMUs in Debian > revisions. Right. > > ### BinNMU > > > > Is impossible to support. The version change requires changes in the > > names of the created packages. > >... > It should only be impossible to make them co-installable, > or what other reason requires a rename? The contents are incompatible. We can of course completely remove the ability to load modules after a kernel upgrade and then install everything into "linux-image-amd64". Bastian -- Deflector shields just came on, Captain.
Re: Debian Kernel version and ABI in respect of #1040901
On Thu, 2023-07-13 at 21:16 +0200, Bastian Blank wrote: [...] > ## Proposed behaviour > > This tries to make sure everything apart from experimental gets new > names and ABI on every upload. > > * experimental: > Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4 > Keep ABI 6.1.0-0-arm64 [...] Why would that still be acceptable in experimental? Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. signature.asc Description: This is a digitally signed message part
Re: Debian Kernel version and ABI in respect of #1040901
On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote: >... > ### NMU > > Can be easily added back by adding "bX" or so to the ABI. That would be confusing, bX is naming convention for binNMUs in Debian revisions. > ### BinNMU > > Is impossible to support. The version change requires changes in the > names of the created packages. >... It should only be impossible to make them co-installable, or what other reason requires a rename? cu Adrian
Debian Kernel version and ABI in respect of #1040901
Hi folks You might have heard that the masters of Linux Secure Boot, aka shim reviewers, have spoken. They have told us that our way of handling kernel modules is not longer acceptable. For some context see #1040901. This means for us that we have to make sure that kernel and modules can't be mixed between different builds. If we want to continue with the current behaviour, where you can keep old kernels usable, we have to rename packages and kernel internal ABI on every upload. This is the first version of a proposal that should work. But it also ignores some Debian and release policy points to avoid some problematic behaviour. For example it should not possible for package names to grow unrestricted. Please share your thoughts or if we have a better solution overall. Regards, Bastian ## Current behaviour Currently in use are the following types: * experimental: Version 6.1~rc2-3~exp4, 6.1.2-3~exp4 ABI 6.1.0-0-arm64 * unstable/testing/stable: Version 6.1.2-3 ABI 6.1.0-1-arm64 * security/LTS: Version 6.1.2-3~deb12u4 ABI 6.1.0-1-arm64 * backports: Version 6.1.2-3~bpo12+4 ABI 6.1.0-0.bpo.1-arm64 But our version check allows allow more variants, including NMU, BinNMU, local versions, +bpo, ~deb11u1~deb10u1. ## Proposed behaviour This tries to make sure everything apart from experimental gets new names and ABI on every upload. * experimental: Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4 Keep ABI 6.1.0-0-arm64 * unstable/testing/stable: Keep version 6.1.2-3 ABI 6.1.2-3-arm64 * security: Use same version ranges as stable, makes it impossible to do stable and security with the same minor. Version 6.1.2-3 ABI 6.1.2-3-arm64 * backports: Keep version 6.1.2-3~bpo12+4 ABI 6.1.2-3.bpo12.4-arm64 * LTS: Version 6.1.2-3~deb12u4 ABI 6.1.2-3.deb12.4-arm64 * Everything else: Not for Debian archive. Keep version ABI 6.1.2-local ## Removed feature for now ### NMU Can be easily added back by adding "bX" or so to the ABI. ### BinNMU Is impossible to support. The version change requires changes in the names of the created packages. ### Release team prefix The release team mandated debXuY suffix is not used for any stable/security or similar release. Only the LTS one for now uses that. This makes sure we never accrue more then one such suffix in any version, to make sure it does not grow unlimited. New stable uploads always try to gather new upstream minor releases, so we should be safe. -- I have never understood the female capacity to avoid a direct answer to any question. -- Spock, "This Side of Paradise", stardate 3417.3
