[Bug 2037799] [NEW] Remove duplications of kernel meta packages and flavours encodings

[Dimitri John Ledkov]

Public bug reported:

Remove duplications of kernel meta packages and flavours

Currently we encode kernel flavours in lots of places:

1) livecd-rootfs code has lots of logic which kernel meta to install, and on which layer.
2) vmlinuz/initrd extraction code currently results encodes mapping of abi & flavour to kenrel stem artifact
3) output artifacts are then encoded, and expected by exact flavour name by ubuntu-cdimage
4) which then has again encoding of which build expects with kernel
5) and then boot-* scripts may have special logic for a kernel too
6) then seeds have to seed the right kernel offline too for offline install to work correctly
7) and then casper specified a different default flavour at runtime too

this is too much, and makes building desktop image that boots into and
installs generic-64k, lowlatency, oem, intel-iot, laptop kernels really
really really difficult

Ideally i wish to eliminate all of these things.

Default kernel for a project should be produced as .kernel
A layer should exist for every offline preinstalled kernel, for direct installation to target.
Or for example, packages to install such kernel should be pre-populated into apt-cache with apt-cache download.
If image offers more than one kernel flavour for install, it should be possible to discover them.
Casper should not be the one writing out /run/kernel-meta-package, it could be set by livecd-rootfs image build process.

** Affects: subiquity
     Importance: Undecided
         Status: New

** Affects: ubuntu-cdimage
     Importance: Undecided
         Status: New

** Affects: casper (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: livecd-rootfs (Ubuntu)
     Importance: Undecided
         Status: New

** Also affects: casper (Ubuntu)
   Importance: Undecided
       Status: New

** Summary changed:

- Remove duplications of kernel meta packages and flavours
+ Remove duplications of kernel meta packages and flavours encodings

** Also affects: subiquity
   Importance: Undecided
       Status: New

** Also affects: ubuntu-cdimage
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to livecd-rootfs in Ubuntu.
https://bugs.launchpad.net/bugs/2037799

Title:
  Remove duplications of kernel meta packages and flavours encodings

Status in subiquity:
  New
Status in Ubuntu CD Images:
  New
Status in casper package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New

Bug description:
  Remove duplications of kernel meta packages and flavours

  Currently we encode kernel flavours in lots of places:

  1) livecd-rootfs code has lots of logic which kernel meta to install, and on which layer.
  2) vmlinuz/initrd extraction code currently results encodes mapping of abi & flavour to kenrel stem artifact
  3) output artifacts are then encoded, and expected by exact flavour name by ubuntu-cdimage
  4) which then has again encoding of which build expects with kernel
  5) and then boot-* scripts may have special logic for a kernel too
  6) then seeds have to seed the right kernel offline too for offline install to work correctly
  7) and then casper specified a different default flavour at runtime too

  this is too much, and makes building desktop image that boots into and
  installs generic-64k, lowlatency, oem, intel-iot, laptop kernels
  really really really difficult

  Ideally i wish to eliminate all of these things.

  Default kernel for a project should be produced as .kernel
  A layer should exist for every offline preinstalled kernel, for direct installation to target.
  Or for example, packages to install such kernel should be pre-populated into apt-cache with apt-cache download.
  If image offers more than one kernel flavour for install, it should be possible to discover them.
  Casper should not be the one writing out /run/kernel-meta-package, it could be set by livecd-rootfs image build process.

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/2037799/+subscriptions