Generating a cloud / VM kernel package

[Thomas Goirand]

Dear Kernel maintainers,

As you may know, it's been years that Ubuntu is shipping a kernel
designed for the cloud. Such a kernel is simply a version of the kernel
that is stripped down for running on VMs. The point here is that VMs do
not need all the drivers that we typically build for the generic Debian
kernel (and if one still needs it, a fallback to the generic kernel is
always possible). This makes the kernel binary package a lot smaller,
and also potentially reduces the surface of attack in case of a security
problem. For example, we wouldn't need ax25, appletalk and such, which
are unfortunately automatically loaded in case matching packets are
received by the kernel, and which have been proven to be problematic in
terms of security maintenance. Most hardware drivers would also go away.

Since it is only a mater of *removing* some modules, I don't think
adding a cloud / VM kernel flavor would be a lot of maintenance. Though
of course, as I wouldn't be the one doing it, it is not up to me to
judge the amount of work.

Could we see this happening in Debian? Please let us know your thoughts.

Cheers,

Thomas Goirand (zigo)

Re: Generating a cloud / VM kernel package

[Martin Zobel-Helas]

Hi, 

On Sat Aug 26, 2017 at 11:48:22 +0200, Thomas Goirand wrote:
> Dear Kernel maintainers,
> 
> As you may know, it's been years that Ubuntu is shipping a kernel
> designed for the cloud. Such a kernel is simply a version of the kernel
> that is stripped down for running on VMs. The point here is that VMs do
> not need all the drivers that we typically build for the generic Debian
> kernel (and if one still needs it, a fallback to the generic kernel is
> always possible). This makes the kernel binary package a lot smaller,
> and also potentially reduces the surface of attack in case of a security
> problem. For example, we wouldn't need ax25, appletalk and such, which
> are unfortunately automatically loaded in case matching packets are
> received by the kernel, and which have been proven to be problematic in
> terms of security maintenance. Most hardware drivers would also go away.
> 
> Since it is only a mater of *removing* some modules, I don't think
> adding a cloud / VM kernel flavor would be a lot of maintenance. Though
> of course, as I wouldn't be the one doing it, it is not up to me to
> judge the amount of work.
> 
> Could we see this happening in Debian? Please let us know your thoughts.

I personaly think this is a good idea in general. Most cloud providers
will probably want/love this, esp. when it comes to specifica of their
environments. On the other hand I have some concerns:

a) we need to decide then if we need one kernel flavour for each cloud
provider or if we can agree on a basic set of kernel compile options
that every cloud provider can use.

b) most kernels Debian ships are kernels that have most drivers needed
as modules, so even though the kernel images are big, the kernel should
only load modules it really needs.

Thomas, can you elaborate why you think this a good idea? Is this about
boot time of the kernel image? The thing I really do not want to have is
additional kernel source uploads to the archive for just those cloud
kernel images, but you already considered that a bad idea (from what I
read between your lines).

Cheers,
Martin

-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

Bug#868082: linux-image-4.11.0-1-686: fails to boot on i386 (Soekris net5501)

[Francesco Poli]

Control: found -1 linux/4.12.6-1


On Mon, 17 Jul 2017 09:59:38 +0200 Francesco Poli wrote:

> On Sun, 16 Jul 2017 22:27:10 +0100 Ben Hutchings wrote:
> 
> [...]
> > If you add 'earlyprintk=ttyS0' to the kernel command line and delete
> > 'quiet', does it log anything?
> 
> Hello Ben,
> thanks for your follow up.
> 
> I have just tried with 'earlyprintk=ttyS0' and without 'quiet', but the
> result seems to be the same:
> 
> Booting a command list
> 
>   Loading Linux 4.11.0-1-686 ...
>   Loading initial ramdisk ...
> 
> and then nothing else.

Hello again,
I tested the new kernel version that has recently migrated to Debian
testing.

Unfortunately, I get the same exact boot failure.

And no useful output on the serial console, even with
'earlyprintk=ttyS0' and without 'quiet':

Booting a command list

  Loading Linux 4.12.0-1-686 ...
  Loading initial ramdisk ...

and then nothing else.


Please note that, after the test, I again booted the machine with the
old Linux 4.9.0-3-686 and noticed "recovering journal" for the root
partition among the boot messages.
Hence, I suppose the root filesystem was mounted in read/write mode
during the failed boot of Linux 4.12.0-1-686.
I don't know whether this piece of information may be useful in order
to pinpoint the issue...

Please let me know, in case you need any further information and/or in
case there's some progress on this bug.

Thanks for your time!

Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpDgK1ki6EGB.pgp
Description: PGP signature

Processed: Re: Bug#868082: linux-image-4.11.0-1-686: fails to boot on i386 (Soekris net5501)

[Debian Bug Tracking System]

Processing control commands:

> found -1 linux/4.12.6-1
Bug #868082 [src:linux] linux-image-4.11.0-1-686: fails to boot on i386 
(Soekris net5501)
Marked as found in versions linux/4.12.6-1.

-- 
868082: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868082
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#870185: armel/marvell kernel size

[Roger Shimizu]

On Tue, Aug 22, 2017 at 2:55 AM, Ben Hutchings  wrote:
> On Tue, 2017-08-22 at 01:22 +0900, Roger Shimizu wrote:
>
> Oh I see, that adds section (1 MiB) alignment in several places.
> Surprisingly, the padding isn't completely zero-filled, so it inflates
> the compressed image size too.

Good to know the details.
Pushed the fix to branch master.

>> Added another commit on branch rosh/check-size2, that check the
>> decompressed image size.
>> I confirmed it works. Please kindly review. Thank you!
>
> Please choose a more meaningful name than 'image2' e.g. 'uncompressed-
> image'.
>
> For the size check, you're mostly duplicating the existing check_size()
> function.  It would be preferable to have a single function with some
> extra parameters so that it can do both compressed and uncompressed
> size checks.

Thanks for your review!
Pushed updated commit to branch rosh/check-uncompressed-size.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#870185: armel/marvell kernel size

[Roger Shimizu]

On Sun, Aug 27, 2017 at 1:27 AM, Roger Shimizu  wrote:
> On Tue, Aug 22, 2017 at 2:55 AM, Ben Hutchings  wrote:
>> For the size check, you're mostly duplicating the existing check_size()
>> function.  It would be preferable to have a single function with some
>> extra parameters so that it can do both compressed and uncompressed
>> size checks.

Forgot to give out result of my test run.

$ debian/bin/buildcheck.py debian/build/build_armel_none_marvell armel
none marvell
Can't read ABI reference.  ABI not checked!
Image size 2084434/2097080, using 99.40%.  Under 1% space in
UNRELEASED.  Continuing.
Uncompressed Image size 5934896/7340032, using 80.86%.  Uncompressed
Image fits.  Continuing.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: Generating a cloud / VM kernel package

[Ben Hutchings]

On Sat, 2017-08-26 at 11:48 +0200, Thomas Goirand wrote:
> Dear Kernel maintainers,
> 
> As you may know, it's been years that Ubuntu is shipping a kernel
> designed for the cloud. Such a kernel is simply a version of the kernel
> that is stripped down for running on VMs. The point here is that VMs do
> not need all the drivers that we typically build for the generic Debian
> kernel (and if one still needs it, a fallback to the generic kernel is
> always possible). This makes the kernel binary package a lot smaller,
> and also potentially reduces the surface of attack in case of a security
> problem. For example, we wouldn't need ax25, appletalk and such, which
> are unfortunately automatically loaded in case matching packets are
> received by the kernel,

They aren't.

Ben.

> and which have been proven to be problematic in
> terms of security maintenance. Most hardware drivers would also go away.
> 
> Since it is only a mater of *removing* some modules, I don't think
> adding a cloud / VM kernel flavor would be a lot of maintenance. Though
> of course, as I wouldn't be the one doing it, it is not up to me to
> judge the amount of work.
> 
> Could we see this happening in Debian? Please let us know your thoughts.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
-- 
Ben Hutchings
One of the nice things about standards is that there are so many of
them.



signature.asc
Description: This is a digitally signed message part

Bug#847570: linux-image-4.9.0-rc8-amd64-unsigned: AMDGPU not build with support for GCN1.0 and GCN1.1 VGAs

[xsellier]

Package: linux-image-4.13.0-rc5-amd64
Version: 4.13~rc5-1~exp1
Severity: wishlist
Tags: patch



Dear maintainers,

I have an AMD Radeon R9 290, and I'd like to use the amdgpu driver (= 
vulkan support) without having to recompile the kernel. As Ferdinand 
Pöll told before:



Since 4.9, linux includes experimental support for GCN 1.0 VGAs, but it's not
enabled in the debian builds as well as the support for GCN 1.1 cards (which
isn't new in the kernel anymore). In the kernel build config, you just need to
set CONFIG_DRM_AMDGPU_SI=Y (for GCN1.0-based cards) and CONFIG_DRM_AMDGPU_CIK=Y
(for GCN1.1-based cards). To use amdgpu if it is built into the kernel with the
old gpus users just need to blacklist radeon and upon the next reboot linux
will load amdgpu and users can install amdgpu-pro if they want to or just stick
with the newest free graphics driver.


This option has been enabled by default for GCN 1.0 in other linux 
release like:

- Ubuntu (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1661887)
- SteamOS (https://github.com/ValveSoftware/SteamOS/issues/593)
- Arch (https://wiki.archlinux.org/index.php/AMDGPU#Loading)

Keep up the good work
Regards
Xavier Sellier.

Re: Generating a cloud / VM kernel package

[Ben Hutchings]

On Sat, 2017-08-26 at 12:15 +0200, Martin Zobel-Helas wrote:
[...]
> Thomas, can you elaborate why you think this a good idea? Is this about
> boot time of the kernel image? The thing I really do not want to have is
> additional kernel source uploads to the archive for just those cloud
> kernel images, but you already considered that a bad idea (from what I
> read between your lines).

When the Google Cloud people talked to me about slow booting, it turned
out that reconfiguring initramfs-tools to MODULES=dep made a big
improvement.  That is likely to be a sensible configuration for most
cloud images.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of
them.



signature.asc
Description: This is a digitally signed message part

Bug#872664: linux-image-4.9.0-3-686-pae: Resume from hibernate fails on Thinkpad T60

[Holger Wansing]

I tried to find the problem, and performed some tests found on
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
in »a) Test modes of hibernation«:
I ran all off (one by one):
echo freezer > /sys/power/pm_test
echo devices > /sys/power/pm_test
echo platform > /sys/power/pm_test
echo processors > /sys/power/pm_test
echo core > /sys/power/pm_test
and then hibernated and resumed.
Everything with success !

I also did (from »c) Using the "test_resume" hibernation option«):
# echo test_resume > /sys/power/disk
# echo disk > /sys/power/state
and this succeeded too, several times and reliably.


So this is probably not a kernel issue.
I will try if a BIOS upgrade solves the problem.

thanks

Holger


-- 

Created with Sylpheed 3.5.1 under the   n e w
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/

Please backport 4.12.6-1 for thinkpad x201 user

[Roger Shimizu]

Dear kernel maintainers,

Please kindly help to backport kernel 4.12.6-1, which hits testing
already, and helps thinkpad x201 user according to #859639 [0].
Thank you!

[0] https://bugs.debian.org/859639#30

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1