Bug#865120: release-notes: document i386/amd64 kernel changes for jessie->stretch

[Stuart Prescott]

Package: release-notes
Severity: important

With Stretch, amd64 flavour kernels are no longer supplied within the i386
Debian architecture (i.e. for a 64 bit kernel with a 32 bit userspace). The
release notes should document that these kernel packages are no longer
offered so that users don't accidentally run unsupported kernels indefinitely
(hence severity:important).

The upgrade path is to enable amd64 as a foreign architecture and then install
the relevant amd64 kernel image.

A 0th draft at some wording for §4.6/4.6.1:

Users of the i386 port are advised that the amd64 flavour of kernel
is no longer included within the i386 port but that these kernels
should instead be installed directly from the amd64 port using the
ability for apt and dpkg to install foreign architecture packages
(known as multiarch).

- check if running i386 userspace with amd64 kernel:
`dpkg --print-architure` is i386, and
`uname -r` ends in amd64

- add amd64 as foreign architecture
`dpkg --add-architecture amd64; apt-get update`

- (install the appropriate kernel metapackage a

[Ben Hutchings]

Post by Stuart Prescott
Package: release-notes
Severity: important
With Stretch, amd64 flavour kernels are no longer supplied within the i386
Debian architecture (i.e. for a 64 bit kernel with a 32 bit userspace). The
release notes should document that these kernel packages are no longer
offered so that users don't accidentally run unsupported kernels indefinitely
(hence severity:important).

[...]

You're quite right, this should have been documented. It might be
worth mentioning linux-headers-amd64 as well. Also, module-assistant
doesn't support foreign architectures but DKMS is fine.

Ben.

[Justin B Rye]

Post by Stuart Prescott
With Stretch, amd64 flavour kernels are no longer supplied within the i386
Debian architecture (i.e. for a 64 bit kernel with a 32 bit userspace). The
release notes should document that these kernel packages are no longer
offered so that users don't accidentally run unsupported kernels indefinitely
(hence severity:important).
The upgrade path is to enable amd64 as a foreign architecture and then install
the relevant amd64 kernel image.

Ben has pointed out a couple of extra things that ought to be
mentioned; I'm basically just nitpicking the spelling and so on.

Post by Stuart Prescott
Users of the i386 port are advised that the amd64 flavour of kernel

We're standardising to en_US, so it's a kernel "flavor" (but no, not
"advized").

Post by Stuart Prescott
is no longer included within the i386 port but that these kernels

i386 isn't exactly a "port"; I'd suggest sticking to "the i386
architecture". However, since the text varies from arch to arch, the
version that's shown to i386 users can afford to be slightly less
wordy about it. I'd suggest:

<para>
Users are advised that the <literal>-amd64</literal> flavor of kernel
is no longer provided for the <literal>i386</literal> architecture.
These kernels

Post by Stuart Prescott
should instead be installed directly from the amd64 port using the
ability for apt and dpkg to install foreign architecture packages
(known as multiarch).

(Perhaps phrase this as "using multiarch, the mechanism allowing the
installation of foreign-architecture packages"?)

Post by Stuart Prescott
`dpkg --print-architure` is i386, and
`uname -r` ends in amd64

Typo: --print-archiTECture.

Here's a version bringing it slightly closer to full sentences:

<itemizedlist>
<listitem>
<para>
To check if you are running <literal>i386</literal> userspace with
<literal>amd64</literal> kernel, run:
<command>dpkg --print-architecture; uname -r</command> (would give
<literal>i386</literal> and a flavor ending in
<literal>-amd64</literal>).
</para>
</listitem>

Post by Stuart Prescott
- add amd64 as foreign architecture
`dpkg --add-architecture amd64; apt-get update`
- (install the appropriate kernel metapackage as described already)

<listitem>
<para>
To add <literal>amd64</literal> as a foreign architecture, run:
<command>dpkg --add-architecture amd64; apt-get update</command>
</para>
</listitem>
<listitem>
<para>
(Install the appropriate kernel metapackage as described above.)
</para>
</listitem>
</itemizedlist>

[Masanori Goto]

Recently I encountered this amd64 kernel issue on my i386 architecture
machine. I think this is useful to be mentioned. Why don't we want to
apply this proposed text?

Post by Ben Hutchings
You're quite right, this should have been documented. It might be
worth mentioning linux-headers-amd64 as well. Also, module-assistant
doesn't support foreign architectures but DKMS is fine.

+1 to linux-headers-amd64. One tricky thing is, this is not officially
supported so module-assistant doesn't work, so that should be clearly
mentioned. I also had some issues to install some kernel related
packages (e.g. virtualbox-dkms) so I'm not sure DKMS is fine or not -
I rather think DMKS also doesn't work but I'd like to hear your
feedback. Should we also mention that?

Based on Justin's feedback, here's the change - who can pick up this
documentation updates?


<para>
Users are advised that the <literal>-amd64</literal> flavor of kernel
is no longer provided for the <literal>i386</literal> architecture.
Instead, these kernels are available and installed directly from amd64
architecture, using multiarch, the mechanism allowing the
installation of foreign-architecture packages.
</para>

<itemizedlist>
<listitem>
<para>
To check if you are running <literal>i386</literal> user space with
<literal>amd64</literal> kernel, run:
<command>dpkg --print-architecture; uname -r</command> (would give
<literal>i386</literal> and a flavor ending in
<literal>-amd64</literal>).
</para>
</listitem>

<listitem>
<para>
To add <literal>amd64</literal> as a foreign architecture, run:
<command>dpkg --add-architecture amd64; apt-get update</command>
</para>
</listitem>
<listitem>
<para>
(Install the appropriate kernel metapackage as described above.)
</para>
</listitem>
</itemizedlist>

<para>
Note that installing kernel modules are not officially supported
through <command>module-assistant</command>.
</para>

[Justin B Rye]

Post by Masanori Goto
Recently I encountered this amd64 kernel issue on my i386 architecture
machine. I think this is useful to be mentioned. Why don't we want to
apply this proposed text?

I don't know anything about how widespread or critical or worthy of
documentation this bug might be, but I notice a couple of lines that
have English language problems sneaking back in.

Post by Masanori Goto
<para>
Users are advised that the <literal>-amd64</literal> flavor of kernel
is no longer provided for the <literal>i386</literal> architecture.
Instead, these kernels are available and installed directly from amd64

"Available and installed" makes it sound as if the kernels are already
automatically installed (and if they can be installed then it's
obvious that they're available). My draft had

These kernels should instead be installed directly from the amd64

(With definite article)

Post by Masanori Goto
architecture, using multiarch, the mechanism allowing the
installation of foreign-architecture packages.
</para>
<itemizedlist>
<listitem>
<para>
To check if you are running <literal>i386</literal> user space with
<command>dpkg --print-architecture; uname -r</command> (would give
<literal>i386</literal> and a flavor ending in
<literal>-amd64</literal>).
</para>
</listitem>
<listitem>
<para>
<command>dpkg --add-architecture amd64; apt-get update</command>
</para>
</listitem>
<listitem>
<para>
(Install the appropriate kernel metapackage as described above.)
</para>
</listitem>
</itemizedlist>
<para>
Note that installing kernel modules are not officially supported
through <command>module-assistant</command>.
</para>

Number agreement fix:

Note that installing kernel modules is not officially supported
through <command>module-assistant</command>.

But hang on, surely that's not true - handling kernel modules is the
one and only thing module-assistant *does* officially support! Don't
you mean something more like this?

Note that <command>module-assistant</command> does not officially
support foreign-architecture kernel modules.

(So maybe it should add "but DKMS does"?)

[Ben Hutchings]

Post by Masanori Goto
Recently I encountered this amd64 kernel issue on my i386 architecture
machine. I think this is useful to be mentioned. Why don't we want to
apply this proposed text?

Post by Ben Hutchings
You're quite right, this should have been documented. It might be
worth mentioning linux-headers-amd64 as well. Also, module-assistant
doesn't support foreign architectures but DKMS is fine.

+1 to linux-headers-amd64. One tricky thing is, this is not officially
supported so module-assistant doesn't work, so that should be clearly
mentioned. I also had some issues to install some kernel related
packages (e.g. virtualbox-dkms) so I'm not sure DKMS is fine or not -
I rather think DMKS also doesn't work but I'd like to hear your
feedback. Should we also mention that?

[...]

Some module packages do their own architecture detection and may fail
when the primary architecture is i386 and the kernel flavour is amd64.
This can happen regardless of what architecture the kernel package is
labelled as! DKMS itself doesn't seem to have a problem with it. At
some point I tested the available DKMS-based packages with this
configuration and reported bugs, but there may have been regressions
since then.

Where module-assistant goes wrong is that it always sets the package
architecture to be the primary architecture. I looked at fixing this,
but there's no one place to fix it as every dependent package
duplicates logic and templates. DKMS doesn't normally build or install
packages, so it doesn't have this problem.

Ben.