RFC: replace linux-virtual with linux-server / tune kernel packages
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | linux (Ubuntu) |
High
|
Andy Whitcroft | ||
Bug Description
We currently build 2 meta packages for easy consumption and automatic kernel upgrades. These are linux-virtual and linux-generic.
The -virtual meta package was created with the general purpose of "support virtual environments", and then extended to include "and common cloud workloads" (adding things like rdb and kvm).
Would it be possible to find a happy medium where we had enough drivers to enable network and block devices and essential server devices but maintained a reasonable install size ? That would enable us to create one set of images for use in cloud enviroments be they on bare metal or hypervisors.
As an example of sizes collected from a cloud image, we have:
release | kernel | apt inst| initrd | /lib/modules
vivid | linux-virtual | 125M | 8M | 34M
vivid | linux-generic | 358M | 27M | 193M
trusty | linux-virtual | 119M | 7M | 31M
trusty | linux-generic | 337M | 24M | 184M
'apt inst' is as reported by apt install after 'apt-get --purge ^linux-.*'
vivid version 3.18.0.11, trusty version 3.13.0.44.51.
both packages share the linux kernel binary which in this case is 5.6M on trusty and 6.3M on vivid.
For a cloud image with default install in the 700M range, the difference between -virtual and -generic is considerable. So it clearly has its value.
However, this value comes at the cost of specialization. If a user installs a server via MAAS or via ISO, they get linux-generic and have some set of modules/kernel function. If they run a cloud image, they have a different set. This is less than desireable as we'd like to say that both cases are "Ubuntu Server". It also means that we have to build "maas images" which are primarily "cloud images with a hardware kernel".
| Changed in linux (Ubuntu): | |
| status: | New → Incomplete |
| Changed in linux (Ubuntu): | |
| status: | Incomplete → New |
| Changed in linux (Ubuntu): | |
| status: | New → Confirmed |
| Patricia Gaughen (gaughen) wrote : | #2 |
No log file needed, Mr Brad Fig automated script.
| Changed in linux (Ubuntu): | |
| assignee: | nobody → Andy Whitcroft (apw) |
| milestone: | none → ubuntu-15.02 |
| tags: | added: kernel-key |
| Changed in linux (Ubuntu): | |
| importance: | Undecided → High |
| tags: |
added: kernel-da-key removed: kernel-key |
| Changed in linux (Ubuntu): | |
| milestone: | ubuntu-15.02 → ubuntu-15.03 |
| Scott Moser (smoser) wrote : | #3 |
So after some discussion, it seems that what we have is not entirely unreasonable.
There would/could be some gain (possbly on the order of 70-80M in /lib/modules). That includes removal of wireless modules, graphics drivers, sound, and some other misc drivers. I'll attach my revised list.
So there is definitely some space to gain from a -server image, however that comes at a development and recurring maintenance cost.
Below the 2 images are "cloud" and "maas", but can be considered "virtual server" and "physical server" for all practical purposes.
The options then are:
a.) keep things as they are, having 2 images for download. Essentially a "ubuntu server + -virtual kernel" for virtual environments and a "ubuntu server + -generic kernel" for hardware.
b.) add new '-server' flavor, and reduce those 2 images to 1. This incurs cost of additional size for virtual users.
c.) add existing -generic flavor everywhere.
It seems that we have 2 different things for good reason. The drivers that are unnecessary in a virtual environment total to be quite large. I think the best thing to do at the omemnt is keep the status-quo (a) and reduce other differences to the 2 images.
We will reduce the delta so that the 2 are really the same other than "hardware enablement" packages (kernel , grub/uefi ... ) and document that cleanly.
| Changed in linux (Ubuntu): | |
| status: | Confirmed → Won't Fix |


This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:
apport-collect 1415634
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.