info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1040901: Upcoming changes to Debian Linux kernel packages
19 views
Skip to first unread message
Bastian Blank
Sep 24, 2023, 9:10:05 AM9/24/23
to
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
information are in #1040901.
We could just do the minimal change, sign the modules a different way
and let users walk into authenticated failures and other scary error
messages. Or we could change the existing ABI setting on every upload,
creating a new set of binary packages.
But maybe we can enhance the user experience a bit, by reducing the
chance of scarry errors, but with the chance of simple errors like "you
need to reboot". So let's do some more changes and hopefully don't
break the user experience too much. The planned changes are discussed
in more detail.
## Kernel modules will be signed with an ephemeral key
The modules will not longer be signed using the Secure Boot CA like the
EFI kernel image itself. Instead a key will be created during the build
and thrown away after.
Yes, this will make the build unreproducible, but no better solution
currently exists. There are some plans, but no-one is working on them.
If a suitable replacement shows up, we can always switch to that
solution.
## Kernel release value includes complete Debian version
The kernel release is what "uname -r" shows, and how modules are
organized in /lib/modules. This value will include the complete version
of the binary package, so even binNMU will somehow work. This will make
sure the value changes with every upload and modules will not be
compatible already from that check.
Example: 6.5.3-2+b2-cloud-arm64
## Image packages contains more version info
By renaming the kernel packages we try to make several kernels
installable at the same time. In contrast to rpm, where you can have
the same package installed multiple times in different versions, dpkg
only supports a single one at the same time. So the co-installable
versions needs to have different package names.
The packages will include the full upstream version. There exists the
exception of devel builds and uploads to experimental, wich will contain
even less of the version, to avoid new names in that cases.
Example: linux-image-6.5.3-cloud-arm64
There are some drawbacks.
The same upstream version in testing and backports will have the same
package name. Multiple uploads of the same upstream version will have
the same package name, but those rarely happens. Those packages will
not be compatible and a reboot is necessary to be able to load modules
again.
It will not longer be possible to reliably derive the package name from
kernel release (see above), as both values are not really related
anymore.
## Header and tool packages will not longer contain version
The headers packages will not longer include the version. It won't be
reliably possible to derive the package name anyway from the running
kernel.
This means that only headers of one single version can be available on
the system at one time. This might be a bit inconvinient for dkms, as
it can't longer build modules for multiple versions.
But we too often have the problem that image and headers go out of sync
and then you can't find the correct ones anyway.
Example: linux-headers-cloud-arm64
## Installer packages will not longer contain too much version
The installer can only ever handle one version of kernel. Also it got
an internal mechanism to detect which packages belong together
(the Kernel-Version control entry). So we have no need to rename them
and force a matching change in d-i itself just because a new kernel
exists. So it will not longer contain the full version in the package
names if not needed.
## Further work
The changes outlined here try to avoid changes to the initramfs
protocol, aka /etc/kernel/. There are larger change is cooking somehow,
see
https://lists.debian.org/msgid-search/Y2GBkyER...@shell.thinkmo.de
Regards,
Bastian
--
You! What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
information are in #1040901.
We could just do the minimal change, sign the modules a different way
and let users walk into authenticated failures and other scary error
messages. Or we could change the existing ABI setting on every upload,
creating a new set of binary packages.
But maybe we can enhance the user experience a bit, by reducing the
chance of scarry errors, but with the chance of simple errors like "you
need to reboot". So let's do some more changes and hopefully don't
break the user experience too much. The planned changes are discussed
in more detail.
## Kernel modules will be signed with an ephemeral key
The modules will not longer be signed using the Secure Boot CA like the
EFI kernel image itself. Instead a key will be created during the build
and thrown away after.
Yes, this will make the build unreproducible, but no better solution
currently exists. There are some plans, but no-one is working on them.
If a suitable replacement shows up, we can always switch to that
solution.
## Kernel release value includes complete Debian version
The kernel release is what "uname -r" shows, and how modules are
organized in /lib/modules. This value will include the complete version
of the binary package, so even binNMU will somehow work. This will make
sure the value changes with every upload and modules will not be
compatible already from that check.
Example: 6.5.3-2+b2-cloud-arm64
## Image packages contains more version info
By renaming the kernel packages we try to make several kernels
installable at the same time. In contrast to rpm, where you can have
the same package installed multiple times in different versions, dpkg
only supports a single one at the same time. So the co-installable
versions needs to have different package names.
The packages will include the full upstream version. There exists the
exception of devel builds and uploads to experimental, wich will contain
even less of the version, to avoid new names in that cases.
Example: linux-image-6.5.3-cloud-arm64
There are some drawbacks.
The same upstream version in testing and backports will have the same
package name. Multiple uploads of the same upstream version will have
the same package name, but those rarely happens. Those packages will
not be compatible and a reboot is necessary to be able to load modules
again.
It will not longer be possible to reliably derive the package name from
kernel release (see above), as both values are not really related
anymore.
## Header and tool packages will not longer contain version
The headers packages will not longer include the version. It won't be
reliably possible to derive the package name anyway from the running
kernel.
This means that only headers of one single version can be available on
the system at one time. This might be a bit inconvinient for dkms, as
it can't longer build modules for multiple versions.
But we too often have the problem that image and headers go out of sync
and then you can't find the correct ones anyway.
Example: linux-headers-cloud-arm64
## Installer packages will not longer contain too much version
The installer can only ever handle one version of kernel. Also it got
an internal mechanism to detect which packages belong together
(the Kernel-Version control entry). So we have no need to rename them
and force a matching change in d-i itself just because a new kernel
exists. So it will not longer contain the full version in the package
names if not needed.
## Further work
The changes outlined here try to avoid changes to the initramfs
protocol, aka /etc/kernel/. There are larger change is cooking somehow,
see
https://lists.debian.org/msgid-search/Y2GBkyER...@shell.thinkmo.de
Regards,
Bastian
--
You! What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0
Andreas Beckmann
Sep 24, 2023, 5:20:04 PM9/24/23
to
On 24/09/2023 15.01, Bastian Blank wrote:
> ## Kernel modules will be signed with an ephemeral key
>
> The modules will not longer be signed using the Secure Boot CA like the
> EFI kernel image itself. Instead a key will be created during the build
> and thrown away after.
Do I correctly assume that change only affects the modules shipped by
> ## Kernel modules will be signed with an ephemeral key
>
> The modules will not longer be signed using the Secure Boot CA like the
> EFI kernel image itself. Instead a key will be created during the build
> and thrown away after.
the linux-image packages and not third-party modules built with dkms?
> ## Header and tool packages will not longer contain version
> This means that only headers of one single version can be available on
> the system at one time. This might be a bit inconvinient for dkms, as
> it can't longer build modules for multiple versions.
That sounds problematic in case of third party modules. If it is
> the system at one time. This might be a bit inconvinient for dkms, as
> it can't longer build modules for multiple versions.
possible to have multiple linux-image-* packages installed, but only
headers for one of them, the third-party modules will only be available
for one of the kernel versions for sure (maybe there are still old
module builds available, but no guarantee especially after the
third-party module got updated). This will make switching between
different kernel versions difficult to impossible, e.g. it may be hard
to go back to a working older kernel version in case the new one does
not work properly (or the third-party module cannot be built or does not
work for the new version).
Regarding getting the correct linux-header-* packages installed for the
installed linux-image-* packages:
Maybe linux-image-* could have
Recommends: linux-headers-* | no-linux-headers
s.t. the correct linux-headers-* are installed by default (installation
of recommends is enabled by default) for all installed linux-image-*
packages. no-linux-headers would be an opt-out package that can be
installed manually if someone does not want to get linux-headers-*
installed at all. It should never be installed automatically.
For dkms it is hard recommend the correct linux-header-* package, right
now we have
Recommends: linux-headers-generic | linux-headers-686-pae |
linux-headers-amd64 | linux-headers
which does not really work for the non-default kernel flavor, e.g. the
-cloud or -i386 kernel. So some improvement on the kernel side would be
nice here.
Andreas
Bastian Blank
Sep 24, 2023, 7:10:04 PM9/24/23
to
Hi Andreas
On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> >
> > The modules will not longer be signed using the Secure Boot CA like the
> > EFI kernel image itself. Instead a key will be created during the build
> > and thrown away after.
>
> Do I correctly assume that change only affects the modules shipped by the
> linux-image packages and not third-party modules built with dkms?
Yes. Nothing calls for changes to MOK keys, which are used by dkms.
> > ## Header and tool packages will not longer contain version
>
> > This means that only headers of one single version can be available on
> > the system at one time. This might be a bit inconvinient for dkms, as
> > it can't longer build modules for multiple versions.
>
> That sounds problematic in case of third party modules. If it is possible to
> have multiple linux-image-* packages installed, but only headers for one of
> them, the third-party modules will only be available for one of the kernel
> versions for sure (maybe there are still old module builds available, but no
> guarantee especially after the third-party module got updated). This will
> make switching between different kernel versions difficult to impossible,
> e.g. it may be hard to go back to a working older kernel version in case the
> new one does not work properly (or the third-party module cannot be built or
> does not work for the new version).
Already built modules remain until someone deletes it. So you can also
switch back to the still installed older kernel version and it will have
the still working module available.
Yes, you would not be able to build new modules for the older kernel
until you also install the matching headers.
> Regarding getting the correct linux-header-* packages installed for the
> installed linux-image-* packages:
> Maybe linux-image-* could have
> Recommends: linux-headers-* | no-linux-headers
> s.t. the correct linux-headers-* are installed by default (installation of
> recommends is enabled by default) for all installed linux-image-* packages.
> no-linux-headers would be an opt-out package that can be installed manually
> if someone does not want to get linux-headers-* installed at all. It should
> never be installed automatically.
Nack. I actually thought about that. But third-party modules are too
much a special configuration to do that and pay the 50MiB or so penalty
for each system. Also this still have the version skew problem between
linux and linux-signed-*, so will be unreliable.
> For dkms it is hard recommend the correct linux-header-* package, right now
> we have
> Recommends: linux-headers-generic | linux-headers-686-pae |
> linux-headers-amd64 | linux-headers
> which does not really work for the non-default kernel flavor, e.g. the
> -cloud or -i386 kernel. So some improvement on the kernel side would be nice
> here.
I thought about adding a versioned provides with the complete kernel
release string as version, so something like
| Provides: linux-headers (= $(uname -r))
This can then be installed via apt-get and the correct version as long
as the package is available. This however can't be done via
dependencies, because it is dynamic. So dkms would need to actively
make sure it got the correct package, if they are still reachable at
all.
Bastian
--
We have found all life forms in the galaxy are capable of superior
development.
-- Kirk, "The Gamesters of Triskelion", stardate 3211.7
On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> >
> > The modules will not longer be signed using the Secure Boot CA like the
> > EFI kernel image itself. Instead a key will be created during the build
> > and thrown away after.
>
> Do I correctly assume that change only affects the modules shipped by the
> linux-image packages and not third-party modules built with dkms?
> > ## Header and tool packages will not longer contain version
>
> > This means that only headers of one single version can be available on
> > the system at one time. This might be a bit inconvinient for dkms, as
> > it can't longer build modules for multiple versions.
>
> That sounds problematic in case of third party modules. If it is possible to
> have multiple linux-image-* packages installed, but only headers for one of
> them, the third-party modules will only be available for one of the kernel
> versions for sure (maybe there are still old module builds available, but no
> guarantee especially after the third-party module got updated). This will
> make switching between different kernel versions difficult to impossible,
> e.g. it may be hard to go back to a working older kernel version in case the
> new one does not work properly (or the third-party module cannot be built or
> does not work for the new version).
switch back to the still installed older kernel version and it will have
the still working module available.
Yes, you would not be able to build new modules for the older kernel
until you also install the matching headers.
> Regarding getting the correct linux-header-* packages installed for the
> installed linux-image-* packages:
> Maybe linux-image-* could have
> Recommends: linux-headers-* | no-linux-headers
> s.t. the correct linux-headers-* are installed by default (installation of
> recommends is enabled by default) for all installed linux-image-* packages.
> no-linux-headers would be an opt-out package that can be installed manually
> if someone does not want to get linux-headers-* installed at all. It should
> never be installed automatically.
much a special configuration to do that and pay the 50MiB or so penalty
for each system. Also this still have the version skew problem between
linux and linux-signed-*, so will be unreliable.
> For dkms it is hard recommend the correct linux-header-* package, right now
> we have
> Recommends: linux-headers-generic | linux-headers-686-pae |
> linux-headers-amd64 | linux-headers
> which does not really work for the non-default kernel flavor, e.g. the
> -cloud or -i386 kernel. So some improvement on the kernel side would be nice
> here.
release string as version, so something like
| Provides: linux-headers (= $(uname -r))
This can then be installed via apt-get and the correct version as long
as the package is available. This however can't be done via
dependencies, because it is dynamic. So dkms would need to actively
make sure it got the correct package, if they are still reachable at
all.
Bastian
--
We have found all life forms in the galaxy are capable of superior
development.
-- Kirk, "The Gamesters of Triskelion", stardate 3211.7
Andreas Beckmann
Sep 24, 2023, 10:40:04 PM9/24/23
to
On 25/09/2023 00.50, Bastian Blank wrote:
> Already built modules remain until someone deletes it. So you can also
> switch back to the still installed older kernel version and it will have
> the still working module available.
This is what I expect not to work.
> Already built modules remain until someone deletes it. So you can also
> switch back to the still installed older kernel version and it will have
> the still working module available.
Assume I have Linux 6.6 and a third-party gpu driver module installed
(so there are dkms and the Linux 6.6 headers as well) and everything is
working fine.
Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6
which is kept installed) and a new version of the gpu driver (which adds
support for 6.7). So the old gpu module for 6.6 gets removed and a new
one is built for 6.7 only (since there are only 6.7 headers now).
Unfortunately 6.7 breaks some exotic in-tree driver (which I desperately
need), so I need to go back to 6.6. Oops, there is no gpu driver module
any more. Recovery now needs manual intervention.
I'm not sure which class of bugs you are trying to solve with this
proposed unversioned linux-headers change. IMO the current scheme of
linux-headers-$version-$abi-$flavor matching
linux-image-$version-$abi-$flavor works well. But perhaps something
could be improved on the metapackage side. Ideally a user should install
either meta-linux-image-without-headers-$flavor OR
meta-linux-image-with-headers-$flavor (and ideally installing dkms
should "automatically switch" to the with-headers variant, not sure how
this could be done). The current scheme of having to install
linux-image-$flavor AND linux-headers-$flavor is a bit tricky.
I'm open to implement improvements on the dkms side.
Andreas
PS: the proposed "more versioning in the linux-image packages" will
solve some rare dkms issues where modules didn't get rebuilt after
linux-headers-* was upgraded but $(uname -r) didn't change
Bastian Blank
Oct 1, 2023, 6:10:04 AM10/1/23
to
On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it. So you can also
> > switch back to the still installed older kernel version and it will have
> > the still working module available.
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it. So you can also
> > switch back to the still installed older kernel version and it will have
> > the still working module available.
> Assume I have Linux 6.6 and a third-party gpu driver module installed (so
> there are dkms and the Linux 6.6 headers as well) and everything is working
> fine.
> Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6
> which is kept installed) and a new version of the gpu driver (which adds
> support for 6.7). So the old gpu module for 6.6 gets removed and a new one
> is built for 6.7 only (since there are only 6.7 headers now).
Ah, here lays the missconception. No, the 6.6 ones are not removed. Why
> there are dkms and the Linux 6.6 headers as well) and everything is working
> fine.
> Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6
> which is kept installed) and a new version of the gpu driver (which adds
> support for 6.7). So the old gpu module for 6.6 gets removed and a new one
> is built for 6.7 only (since there are only 6.7 headers now).
should they be? The system knows it can't rebuild them.
If the current implementation would remove them, it is a problem there,
not in the concept.
Bastian
--
Superior ability breeds superior ambition.
-- Spock, "Space Seed", stardate 3141.9
Michel Verdier
Oct 1, 2023, 6:20:04 AM10/1/23
to
On 2023-10-01, Bastian Blank wrote:
>> Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6
>> which is kept installed) and a new version of the gpu driver (which adds
>> support for 6.7). So the old gpu module for 6.6 gets removed and a new one
>> is built for 6.7 only (since there are only 6.7 headers now).
>
> Ah, here lays the missconception. No, the 6.6 ones are not removed. Why
> should they be? The system knows it can't rebuild them.
As the old kernel driver is not rebuild it perhaps could break things if
>> Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6
>> which is kept installed) and a new version of the gpu driver (which adds
>> support for 6.7). So the old gpu module for 6.6 gets removed and a new one
>> is built for 6.7 only (since there are only 6.7 headers now).
>
> Ah, here lays the missconception. No, the 6.6 ones are not removed. Why
> should they be? The system knows it can't rebuild them.
libraries/programs are tied on a specific version of the driver
Bastian Blank
Oct 1, 2023, 7:50:05 AM10/1/23
to
Hi Michel
So you upgrade the driver and libaries and suddenly your system fails
until you reboot? Okay, I could imaging NVidia doing something like
tying libraries to kernel modules. At least in the past they replaced
gl libraries that did not longer work with X forwarding.
Could you please name the culprit, or is this just a theoretical
problem?
However what if the new driver does not build with the old kernel?
There are endless possibilities to break this. Which ones are important
and can be supported?
Bastian
--
Well, Jim, I'm not much of an actor either.
until you reboot? Okay, I could imaging NVidia doing something like
tying libraries to kernel modules. At least in the past they replaced
gl libraries that did not longer work with X forwarding.
Could you please name the culprit, or is this just a theoretical
problem?
However what if the new driver does not build with the old kernel?
There are endless possibilities to break this. Which ones are important
and can be supported?
Bastian
--
Well, Jim, I'm not much of an actor either.
Michel Verdier
Oct 1, 2023, 10:40:04 AM10/1/23
to
On 2023-10-01, Bastian Blank wrote:
> So you upgrade the driver and libaries and suddenly your system fails
> until you reboot? Okay, I could imaging NVidia doing something like
> tying libraries to kernel modules. At least in the past they replaced
> gl libraries that did not longer work with X forwarding.
>
> Could you please name the culprit, or is this just a theoretical
> problem?
Yes you named it. Without rebuilding with dkms the old kernel disable
> So you upgrade the driver and libaries and suddenly your system fails
> until you reboot? Okay, I could imaging NVidia doing something like
> tying libraries to kernel modules. At least in the past they replaced
> gl libraries that did not longer work with X forwarding.
>
> Could you please name the culprit, or is this just a theoretical
> problem?
nvidia loading.
> However what if the new driver does not build with the old kernel?
desperately need to boot on the only supposedly working kernel
Sam Hartman
Oct 3, 2023, 10:40:05 AM10/3/23
to
>>>>> "Bastian" == Bastian Blank <wa...@debian.org> writes:
Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
>> On 25/09/2023 00.50, Bastian Blank wrote:
>> > Already built modules remain until someone deletes it. So you
>> can also > switch back to the still installed older kernel
>> version and it will have > the still working module available.
>> Assume I have Linux 6.6 and a third-party gpu driver module
>> installed (so there are dkms and the Linux 6.6 headers as well)
>> and everything is working fine. Then I upgrade the system, which
>> brings Linux 6.7 (along linux-image-6.6 which is kept installed)
>> and a new version of the gpu driver (which adds support for
>> 6.7). So the old gpu module for 6.6 gets removed and a new one is
>> built for 6.7 only (since there are only 6.7 headers now).
Bastian> Ah, here lays the missconception. No, the 6.6 ones are not
Bastian> removed. Why should they be? The system knows it can't
Bastian> rebuild them.
Bastian> If the current implementation would remove them, it is a
Bastian> problem there, not in the concept.
I still think it would help if you would work more on articulating what
problem you are trying to solve with the linux-headers versioning
change. I have read multiple versions of this proposal, and your
follow-ups, and I still do not understand what is prompting the
linux-headers change.
My intuition mirrors others in the conversation that it is problematic
to support multiple kernel versions without also supporting multiple
header versions.
Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
>> On 25/09/2023 00.50, Bastian Blank wrote:
>> > Already built modules remain until someone deletes it. So you
>> can also > switch back to the still installed older kernel
>> version and it will have > the still working module available.
>> Assume I have Linux 6.6 and a third-party gpu driver module
>> installed (so there are dkms and the Linux 6.6 headers as well)
>> and everything is working fine. Then I upgrade the system, which
>> brings Linux 6.7 (along linux-image-6.6 which is kept installed)
>> and a new version of the gpu driver (which adds support for
>> 6.7). So the old gpu module for 6.6 gets removed and a new one is
>> built for 6.7 only (since there are only 6.7 headers now).
Bastian> removed. Why should they be? The system knows it can't
Bastian> rebuild them.
Bastian> If the current implementation would remove them, it is a
Bastian> problem there, not in the concept.
I still think it would help if you would work more on articulating what
problem you are trying to solve with the linux-headers versioning
change. I have read multiple versions of this proposal, and your
follow-ups, and I still do not understand what is prompting the
linux-headers change.
My intuition mirrors others in the conversation that it is problematic
to support multiple kernel versions without also supporting multiple
header versions.
herve
Oct 3, 2023, 11:30:04 AM10/3/23
to
>> 6.7). So the old gpu module for 6.6 gets removed and a new
one is
>> built for 6.7 only (since there are only 6.7 headers now).
Bastian> Ah, here lays the missconception. No, the 6.6 ones are not
Bastian> removed. Why should they be? The system knows it can't
Bastian> rebuild them.
Bastian> If the current implementation would remove them, it is a
Bastian> problem there, not in the concept.
I still think it would help if you would work more on articulating what
problem you are trying to solve with the linux-headers versioning
change. I have read multiple versions of this proposal, and your
follow-ups, and I still do not understand what is prompting the
linux-headers change.
My intuition mirrors others in the conversation that it is problematic
to support multiple kernel versions without also supporting multiple
header versions.
concerning the linux-headers. may i explain what happend to me.
I reinstalled a debian 11.6 some months ago. and last week i had to make virtualbox functioning again. it had to "compile" some kernel modules and need some "headers". my kernel (from the install is 5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64 GNU/Linux) so virtualbox need some 5.10.0-23 headers... you can find 5.10.0.20, 5.10.0.22, 5.10.0.25 in the repos from where the install came from.
I had to surf the web and find a 5.10.0.23 in the web site of an university and wget it to dpkg -i it.
I do not know (maybe i could not even understand) the security reasons/problems of the headers versioning but it seems from my end-user point of view that, the actual situation that lend me to download from a website is the worst possible solution.
hervé
Bjørn Mork
Oct 3, 2023, 1:10:04 PM10/3/23
to
herve <he...@couvelard.com> writes:
> concerning the linux-headers. may i explain what happend to me.
>
> I reinstalled a debian 11.6 some months ago. and last week i had to
> make virtualbox functioning again. it had to "compile" some kernel
> modules and need some "headers". my kernel (from the install is
> 5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64
> GNU/Linux) so virtualbox need some 5.10.0-23 headers... you can find
> 5.10.0.20, 5.10.0.22, 5.10.0.25 in the repos from where the install
> came from.
>
> I had to surf the web and find a 5.10.0.23 in the web site of an
> university and wget it to dpkg -i it.
No, you didn't. You could, and should, simply update the kernel with
> concerning the linux-headers. may i explain what happend to me.
>
> I reinstalled a debian 11.6 some months ago. and last week i had to
> make virtualbox functioning again. it had to "compile" some kernel
> modules and need some "headers". my kernel (from the install is
> 5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64
> GNU/Linux) so virtualbox need some 5.10.0-23 headers... you can find
> 5.10.0.20, 5.10.0.22, 5.10.0.25 in the repos from where the install
> came from.
>
> I had to surf the web and find a 5.10.0.23 in the web site of an
> university and wget it to dpkg -i it.
the latest security fixes, and then install the matching headers from
the same repo.
> I do not know (maybe i could not even understand) the security
> reasons/problems of the headers versioning but it seems from my
> end-user point of view that, the actual situation that lend me to
> download from a website is the worst possible solution.
card. Sorry.
Bjørn
Bastian Blank
Oct 3, 2023, 1:50:04 PM10/3/23
to
Hi Sam
On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change. I have read multiple versions of this proposal, and your
> follow-ups, and I still do not understand what is prompting the
> linux-headers change.
The core problem is that people assume they can get headers matching the
currently running kernel, without upgrading first, see also the parallel
thread. Or freak out because meta packages remain uninstallable in
backports for days.
With this plan you can only get the correct ones by using something
I think like:
| apt satisfy 'linux-headers (= $(uname -r))'
There is somewhere again a maybe possible plan to get meta packages in
place that actually support the case of always providing the headers to
the installed (not running!) kernel.
Then we need to use the same versioning anyway again. In the end I
don't really care, but we need then a way to fix the version skew
between the different source package for the kernel. Aka either redo
larger parts of the linux package (which can never fix it completely),
plus gcc or we change how backports works.
> My intuition mirrors others in the conversation that it is problematic
> to support multiple kernel versions without also supporting multiple
> header versions.
Usually you try to guard against one error. Noone claimed that we can't
work with one error. All the other conversations already have to argue
with two errors at the same time. When should we stop then?
Regards,
Bastian
--
Deflector shields just came on, Captain.
On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change. I have read multiple versions of this proposal, and your
> follow-ups, and I still do not understand what is prompting the
> linux-headers change.
currently running kernel, without upgrading first, see also the parallel
thread. Or freak out because meta packages remain uninstallable in
backports for days.
With this plan you can only get the correct ones by using something
I think like:
| apt satisfy 'linux-headers (= $(uname -r))'
There is somewhere again a maybe possible plan to get meta packages in
place that actually support the case of always providing the headers to
the installed (not running!) kernel.
Then we need to use the same versioning anyway again. In the end I
don't really care, but we need then a way to fix the version skew
between the different source package for the kernel. Aka either redo
larger parts of the linux package (which can never fix it completely),
plus gcc or we change how backports works.
> My intuition mirrors others in the conversation that it is problematic
> to support multiple kernel versions without also supporting multiple
> header versions.
work with one error. All the other conversations already have to argue
with two errors at the same time. When should we stop then?
Regards,
Bastian
--
Deflector shields just came on, Captain.
herve
Oct 3, 2023, 2:40:04 PM10/3/23
to
Bjørn
thank you for your answer.
I remember that linus had the aim to be the less annoying for the
user-expérience. I can understand _your_ point of view to have the
"kernel-three-code" and the "security" card things. the fact is i
didn't choose neither testing, neither sid but stable. And in my
experience upgrading kernel is not always smooth. so I used to
keep the same kernel, until it is important to change, and i have
time to do it. Not when i have to run a wm to finish a job.
It is, from my point of view a "geek" stuff to "delete" the
packages from the repos. _you_ think I _must_ upgrade my kernel.
OK. But if it was so simple their would not have theses messages
on the list. When i tried to install the headers i had no message
i should upgrade, just the packages were not existing (the same
that if there was was a typo). So i surfed the web to find it. How
could i know that i _should_ upgrade to benefit the right to get
some headers ? If i installed them in the same time as the kernel,
i would have them already : which differences in terms of security
(installed in july - installed in september) ?
I just want to point, that i didn't initiate a thread to
complain, i just share my experience on an existing thread about
headers and security. i was not shamming security or else. i was
just saying that the politic to improve security pushed me to
download from the web instead of the repos. is the solution worse
than the disease ? I use linux on the desktop for almost 25 years,
red hat, then fedora, then debian and that never happened until
last week. I was thinking that the difference between free
software and proprietary one is the possibility for free software
user to upgrade when _they_ want and not when the _supplier_
decide they should. and suppress headers is _forcing_ user to
upgrade.
So to conclude, my experience is not a way to propose or impose a solution but to point that there are sometimes between chair and screen some "normal" persons that just want things to run. If the solution proposed by virtualbox (install headers, naming them) could not function, they will install something else. And, if i find alone the solution by some little experience, lots of people won't. Of course you are right about "Running out-of-tree kernel code" but that would not help them.
Linux is not so easy, maybe it is not a good idea to had some
complications. if a kernel is so rapidly "out-of-tree" why let it
in the "stable" distribution ?
my 2 cents.
hervé
ps : i really understand your point of view, i just want to say
it is not in the 10 commandments
Adrian Bunk
Oct 3, 2023, 4:00:04 PM10/3/23
to
On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
>...
If the new kernel has a regression that affects the user, the user
usually has no good choice other than downgrading to the previously-used
kernel and continue using it until a fixed kernel is available.
How will the user get the headers matching this previously-used kernel
that are required until we provide a kernel with the regression fixed?
> Regards,
> Bastian
cu
Adrian
>...
> The core problem is that people assume they can get headers matching the
> currently running kernel, without upgrading first, see also the parallel
> thread.
>...
> currently running kernel, without upgrading first, see also the parallel
> thread.
If the new kernel has a regression that affects the user, the user
usually has no good choice other than downgrading to the previously-used
kernel and continue using it until a fixed kernel is available.
How will the user get the headers matching this previously-used kernel
that are required until we provide a kernel with the regression fixed?
> Regards,
> Bastian
cu
Adrian
Robert Nelson
Oct 3, 2023, 4:10:04 PM10/3/23
to
debian. However since 5.2 there is a kernel config option, which
allows you to build the kernel headers as a module (built-in or
external)..
https://cateee.net/lkddb/web-lkddb/IKHEADERS.html
As long as this was enabled (ignore bugs/regressions), users can go
back and forth on kernel versions as they wish.
Regards,
--
Robert Nelson
https://rcn-ee.com/
Andreas Beckmann
Oct 3, 2023, 6:00:05 PM10/3/23
to
On 03/10/2023 19.30, Bastian Blank wrote:
> thread. Or freak out because meta packages remain uninstallable in
> backports for days.
...
> thread. Or freak out because meta packages remain uninstallable in
> backports for days.
> plus gcc or we change how backports works.
If uninstallable packages in backports are a problem, perhaps backports
needs something like britney to migrate packages from an uploading area
to the publishing area (once a package set is installable, no need for
delays). That should solve the problem where several source packages
need to be updated together. (It would also solve problems with
unsatisfiable dependencies where the backporter-uploaded binaries were
built by accident in sid instead of stable, requiring a binNMU before
migration.)
(but this should be discussed elsewhere)
Andreas
Bastian Blank
Oct 5, 2023, 2:10:05 AM10/5/23
to
Hi Andreas
On Tue, Oct 03, 2023 at 11:58:29PM +0200, Andreas Beckmann wrote:
> That should solve the problem where several source packages need to be
> updated together.
The problem does not come from multiple source packages that need to be
updated together. Instead it comes from the way Debian does signing of
secure boot components. After the linux packages got built and accepted,
an automatic process takes the output and produces a new source package
that is uploaded, built and accepted. So the signed stuff will always
come later (between hours or days in normal cases, but esp for backports
even more then a week later).
Regards,
Bastian
--
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?" stardate 3468.1
On Tue, Oct 03, 2023 at 11:58:29PM +0200, Andreas Beckmann wrote:
> That should solve the problem where several source packages need to be
> updated together.
updated together. Instead it comes from the way Debian does signing of
secure boot components. After the linux packages got built and accepted,
an automatic process takes the output and produces a new source package
that is uploaded, built and accepted. So the signed stuff will always
come later (between hours or days in normal cases, but esp for backports
even more then a week later).
Regards,
Bastian
--
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?" stardate 3468.1
Bastian Blank
Oct 5, 2023, 2:30:04 AM10/5/23
to
On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote:
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk <bu...@debian.org> wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?
The same as now: nowhere, because those packages have been removed from
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk <bu...@debian.org> wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?
the archive already.
And sadly you did not answer the question why a second degree error must
not be worse then a worked around first degree error?
> I know there is a lot of history behind the linux-headers package in
> debian. However since 5.2 there is a kernel config option, which
> allows you to build the kernel headers as a module (built-in or
> external)..
> https://cateee.net/lkddb/web-lkddb/IKHEADERS.html
> As long as this was enabled (ignore bugs/regressions), users can go
> back and forth on kernel versions as they wish.
the build. But it still needs all the static headers, all the support
binaries and scripts (shipped as linux-kbuild-*), which also change with
every version.
Regards,
Bastian
--
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
stardate 4842.6
Sam Hartman
Oct 5, 2023, 10:10:04 AM10/5/23
to
Bastian> The same as now: nowhere, because those packages have been
Bastian> removed from the archive already.
Bastian> And sadly you did not answer the question why a second
Bastian> degree error must not be worse then a worked around first
Bastian> degree error?
I'll admit that I find that phrasing difficult enough that I had to read
it a couple of times and I'm still not sure I've got it.
Let me see if I understand what you are saying.
1) kernel headers will be removed from the archive. So people complain
if they have an old kernel and wish to get kernel headers for it, but
those headers have been removed.
2) If the kernel header version changes but the kernel header package
name does not change (version changed but not uname -r in the new
scheme?), you can have what you think is the right kernel headers but
they do not work with the binaries you have installed.
3) you can run into trouble between testing and backports.
I think that's what you mean by the first-level error.
If not, I'm still confused.
In the second level error case you are talking about is:
1) there is a regression in the kernel
2) someone needs kernel headers for an old kernel they want to downgrade
to.
I don't actually see how this is a second level error.
It appears to be a different first-level error (a regression), and the
downgrade appears to follow naturally from that.
You point out that someone may not be able to get kernel headers for the
downgraded kernel.
a) They might. In the window between a new kernel being introduced into
unstable and the same kernel being introduced into testing there is an
old kernel available with kernel headers.
Similarly if someone needs to downgrade as far as stable, there is a
kernel with headers available in stable.
B) They might already have headers installed. Imagine someone who
installs headers at the same time they install the kernel.
Unless they managed to upgrade the same version of their kernel without
also upgrading their headers, they will still have headers.
They can still build modules against that kernel, either because they
installed a new dkms package, or because one of their dkms packages
upgraded.
I think what you are saying is that
1) the current system is fragile: sometimes you want a kernel headers
that is not available and sometimes you have version skew between the
kernel headers and kernel even though you have both installed.
2) In your system, fewer things are possible, but the combination that
is possible is more likely to work.
And I think people's response is that
they care enough about some of the things you are breaking that they are
willing to accept the fragility.
Bastian> -- Each kiss is as the first. -- Miramanee, Kirk's wife,
Bastian> "The Paradise Syndrome", stardate 4842.6
Bastian> removed from the archive already.
Bastian> And sadly you did not answer the question why a second
Bastian> degree error must not be worse then a worked around first
Bastian> degree error?
I'll admit that I find that phrasing difficult enough that I had to read
it a couple of times and I'm still not sure I've got it.
Let me see if I understand what you are saying.
1) kernel headers will be removed from the archive. So people complain
if they have an old kernel and wish to get kernel headers for it, but
those headers have been removed.
2) If the kernel header version changes but the kernel header package
name does not change (version changed but not uname -r in the new
scheme?), you can have what you think is the right kernel headers but
they do not work with the binaries you have installed.
3) you can run into trouble between testing and backports.
I think that's what you mean by the first-level error.
If not, I'm still confused.
In the second level error case you are talking about is:
1) there is a regression in the kernel
2) someone needs kernel headers for an old kernel they want to downgrade
to.
I don't actually see how this is a second level error.
It appears to be a different first-level error (a regression), and the
downgrade appears to follow naturally from that.
You point out that someone may not be able to get kernel headers for the
downgraded kernel.
a) They might. In the window between a new kernel being introduced into
unstable and the same kernel being introduced into testing there is an
old kernel available with kernel headers.
Similarly if someone needs to downgrade as far as stable, there is a
kernel with headers available in stable.
B) They might already have headers installed. Imagine someone who
installs headers at the same time they install the kernel.
Unless they managed to upgrade the same version of their kernel without
also upgrading their headers, they will still have headers.
They can still build modules against that kernel, either because they
installed a new dkms package, or because one of their dkms packages
upgraded.
I think what you are saying is that
1) the current system is fragile: sometimes you want a kernel headers
that is not available and sometimes you have version skew between the
kernel headers and kernel even though you have both installed.
2) In your system, fewer things are possible, but the combination that
is possible is more likely to work.
And I think people's response is that
they care enough about some of the things you are breaking that they are
willing to accept the fragility.
Bastian> -- Each kiss is as the first. -- Miramanee, Kirk's wife,
Russ Allbery
Oct 5, 2023, 11:30:04 AM10/5/23
to
Sam Hartman <hart...@debian.org> writes:
> B) They might already have headers installed. Imagine someone who
> installs headers at the same time they install the kernel. Unless they
> managed to upgrade the same version of their kernel without also
> upgrading their headers, they will still have headers. They can still
> build modules against that kernel, either because they installed a new
> dkms package, or because one of their dkms packages upgraded.
I am also really confused by this discussion and don't entirely understand
> B) They might already have headers installed. Imagine someone who
> installs headers at the same time they install the kernel. Unless they
> managed to upgrade the same version of their kernel without also
> upgrading their headers, they will still have headers. They can still
> build modules against that kernel, either because they installed a new
> dkms package, or because one of their dkms packages upgraded.
the motivation for the proposed change to kernel headers, but isn't the
situation Sam describes above the normal way Linux kernel headers work and
have worked for years? Kernels come with headers matching the same
version, if you want headers for external modules you install both
packages at the same time via one mechanism or another, and you only
remove the kernel and headers when you're pretty sure you will never use
that kernel again.
When I was using external modules heavily, I routinely kept three or four
old kernels and their corresponding headers installed at the same time so
that I could easily downgrade if I ran into regressions without having to
track down old packages that may have been removed from the archive. This
feels like a normal and somewhat obvious Debian systems administration
thing to do to me.
I realize in the new signing regime every new kernel would have a separate
headers package (as opposed to today where the kernel and headers are
updated in place with the same package name if there is no ABI change),
but to me this doesn't feel like a significant difference for users. I
haven't been paying close attention, so maybe I'm wrong, but I feel like
most kernel package updates have been ABI updates anyway, particularly in
stable.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bastian Blank
Oct 5, 2023, 3:30:03 PM10/5/23
to
Hi
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.
We could encode that in the upstream version. Aka to have
co-installable packages for security updates we do:
- 6.6.1-1
- 6.6.1+1-1
- 6.6.1+2-1
This allows for easy semantic, aka we only care for package names about
the upstream part of the version, which then needs to follow a certain
syntax.
Regards,
Bastian
--
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
We could encode that in the upstream version. Aka to have
co-installable packages for security updates we do:
- 6.6.1-1
- 6.6.1+1-1
- 6.6.1+2-1
This allows for easy semantic, aka we only care for package names about
the upstream part of the version, which then needs to follow a certain
syntax.
Regards,
Bastian
--
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4
Bastian Blank
Oct 7, 2023, 11:00:04 AM10/7/23
to
Moin
On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> ## Kernel modules will be signed with an ephemeral key
This is now
https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.
> ## Image packages contains more version info
>
> Example: linux-image-6.5.3-cloud-arm64
> It will not longer be possible to reliably derive the package name from
> kernel release (see above), as both values are not really related
> anymore.
I missed that apt does something similar (maintainers cced). It wants
to see if a particular package matches the current kernel to make the
autoremove prevention work. That lookup is quite a hard problem.
What should work: We define a new control field. It contains both the
kernel name and a version prefix.
Example:
- Linux 6.6 (would match 6.6-1, 6.6.1-1)
- Linux 6.6.3 (would match 6.6.3-1, but not 6.6.3+2-1)
- Linux 6.6.3+2
The algorithm would be something like this:
- Check $(uname -s) against the first word. Otherwise completely
ignore.
- Check if $(uname -r) matches the version prefix in this field. Mark
as keep if it matches.
- Aggregate packages by version prefix.
- Sort as version, keep newest two(?).
This means:
- Images and headers are always kept with the same versions.
- Different images (-arm64, -rt-arm64) are always kept together.
Counter proposal: Use see the kernel release as debian version and match
on the upstream version. But then we need to re-define what we put into
the kernel release field. In 6.6.1-1-cloud-arm64, the upstream version
is 6.6.1-1-cloud, not 6.6.1 as we would need. We could of course change
that to: 6.6.1-1~cloud+arm64. That should always sort correctly in
regard of the package version.
> ## Header and tool packages will not longer contain version
This is obsolete with the counter proposal of a meta package that always
pulls in image and headers of the same version.
Regards,
Bastian
--
Without followers, evil cannot spread.
-- Spock, "And The Children Shall Lead", stardate 5029.5
On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> ## Kernel modules will be signed with an ephemeral key
https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.
> ## Image packages contains more version info
>
> It will not longer be possible to reliably derive the package name from
> kernel release (see above), as both values are not really related
> anymore.
to see if a particular package matches the current kernel to make the
autoremove prevention work. That lookup is quite a hard problem.
What should work: We define a new control field. It contains both the
kernel name and a version prefix.
Example:
- Linux 6.6 (would match 6.6-1, 6.6.1-1)
- Linux 6.6.3 (would match 6.6.3-1, but not 6.6.3+2-1)
- Linux 6.6.3+2
The algorithm would be something like this:
- Check $(uname -s) against the first word. Otherwise completely
ignore.
- Check if $(uname -r) matches the version prefix in this field. Mark
as keep if it matches.
- Aggregate packages by version prefix.
- Sort as version, keep newest two(?).
This means:
- Images and headers are always kept with the same versions.
- Different images (-arm64, -rt-arm64) are always kept together.
Counter proposal: Use see the kernel release as debian version and match
on the upstream version. But then we need to re-define what we put into
the kernel release field. In 6.6.1-1-cloud-arm64, the upstream version
is 6.6.1-1-cloud, not 6.6.1 as we would need. We could of course change
that to: 6.6.1-1~cloud+arm64. That should always sort correctly in
regard of the package version.
> ## Header and tool packages will not longer contain version
pulls in image and headers of the same version.
Regards,
Bastian
--
Without followers, evil cannot spread.
-- Spock, "And The Children Shall Lead", stardate 5029.5
Bastian Blank
Oct 26, 2023, 8:00:05 AM10/26/23
to
On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote:
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:
No, the first level is always: but the new kernel does not work.
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:
The second is: I need to upgrade external modules.
> I think what you are saying is that
>
> 1) the current system is fragile: sometimes you want a kernel headers
> that is not available and sometimes you have version skew between the
> kernel headers and kernel even though you have both installed.
>
> 2) In your system, fewer things are possible, but the combination that
> is possible is more likely to work.
> And I think people's response is that
> they care enough about some of the things you are breaking that they are
> willing to accept the fragility.
packages and accept that they become uninstallable from time to time.
In the future we might want to split off the modules into it's own
package anyway. That will then allow
- a different image package containing prebuilt UKI,
- a different modules package to replace the special cloud flavours.
Regards,
Bastian
--
Without facts, the decision cannot be made logically. You must rely on
your human intuition.
-- Spock, "Assignment: Earth", stardate unknown
Bastian Blank
Oct 27, 2023, 5:00:04 AM10/27/23
to
On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote:
> > > ## Image packages contains more version info
> > >
> > > Example: linux-image-6.5.3-cloud-arm64
> >
> > > It will not longer be possible to reliably derive the package name from
> > > kernel release (see above), as both values are not really related
> > > anymore.
>
> This package name seems to be missing the Debian release, which is
> > > ## Image packages contains more version info
> > >
> > > Example: linux-image-6.5.3-cloud-arm64
> >
> > > It will not longer be possible to reliably derive the package name from
> > > kernel release (see above), as both values are not really related
> > > anymore.
>
> mandatory to ensure that you can install 6.5.3-2 and 6.5.3-1 in
> parallel, which again is mandatory. That's not something we can
> compromise on; it's absolutely vital that
Sadly in Debian there is no way to make that happen. Think for example
about bin-nmu.
In the end we can approximate it in testing (usually not multiple
releases are migrated, but bin-nmu might show up), stable (where usualy
new upstream releases go in) and security (by uploading as 6.6.1,
6.6.1+1, 6.6.1+2, yes this is a hack, but it reduces the complexity of
the whole system).
Right now I simply don't see a way to not have multiple releases within
the same package, which override each other.
> - you can revert to the kernel you last booted succesfully, i.e. 6.5.3-1
> if 6.5.3-2 is broken (think toolchain broke or something on buildds)
You can revert to 6.5.2, which is a separate package. Or 6.4.
> - the currently booted kernel is not impacted. This means it must be
> able to load additional modules. Some platforms even require
> additional modules to be loaded to reboot, I've seen this on
> laptops.
Could you provide an example?
Then we have to find another way to make sure modules survive unrelated
to what dpkg does. Even right now there is no guarante you can load
modules from a different version at all.
> Needless to say I do not believe that uname -s is necessarily a
> single word.
Please provide an example.
[ Snipped the rest for now, will come back later ]
Bastian
--
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1
0 new messages