Re: Testing versatile kernel on Raspberry Pi?

[Ian Campbell]

On Mon, 2016-01-25 at 15:46 +0100, Diederik de Haas wrote:
> > I wasn't aware that any of the RPi support (for any model) had gone
> > upstream.
> 
> It has taken a while, but it seems that major parts are now upstream-ed. 
> See the changelog mentioned earlier.

Great!

[...]
> As I got the impression that support for the RPi was now present in
> upstream and (therefor) the Debian kernels,

The "therefor" won't happen automatically, someone will need to file a
wishlist bug asking for the relevant options to be enabled in the Debian
kernel configuration.

For the RPi's with the newer CPU cores it makes clear sense to do that in
the armhf/armmp kernel flavour (since it is the "multiplatform" flavour,
and the only one we want to support).

For the RPi's with the older cores it wouldn't seem to make much sense to
enable it in the armel/versatile flavour (because I can't see why it fits
there, despite folks apparently adding it there), but equally I'm not sure
we want to be adding new flavours to armel (which is essentially on the
downward slope of the support lifecycle at this stage). Perhaps others
around here feel differently though.

Probably those two cases ought to be separate wishlist bugs for armhf vs
armel.

>  I wanted to offer my help in testing it, if needed.

Once someone does the work to enable them then testing would be valuable
(of course). Perhaps you can take on the former?

Ian.

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Ben Hutchings]

On Thu, 12 Nov 2015 09:49:33 + Ian Campbell  wrote:
> On Wed, 2015-11-11 at 18:46 -0600, Vagrant Cascadian wrote:
[...]
> > Would definitely like to see this, with a recent install on a Wandboard
> > Dual with a USB2 sata disk for the rootfs. It installed fine with
> > jessie's debian-installer, but failed on initial boot.
> > 
> > I worked around it by adding to /etc/initramfs-tools/modules:
> > 
> >   ci_hdrc_imx
> >   phy_mxs_usb
> > 
> > I haven't yet verified if only adding "phy_mxs_usb" instead of both will
> > work.
> > 
> > Had a similar problem with an Odroid-XU4 install (which isn't yet
> > supported by debian-installer), and worked around it similarly, although
> > haven't narrowed down exactly which modules are needed, though I
> > suspect one or both of:
> > 
> >   phy_exynos_usb2
> >   phy_exynos5_usbdrd
> > 
> > 
> > Something that pulls in all the phy-* modules would likely fix the issue
> > in a generic way, rather than playing whack-a-mole with various phy
> > types.
> 
> I think Ben essentially did this in #762042[0], which ends up adding any
> phy-* which are currently loaded to the initramfs. That change appears to
> be in v0.119 while Jessie has v0.120 so perhaps something else is going on.
> 
> ci-* isn't covered by this logic, so that might be it in the first case.
> What is ci-*?

Thaose are the chipidea USB controller drivers, which should get found
through sysfs.

Please can you clear out /etc/initramfs-tools/modules (temporarily) and
run:

    sh -x /usr/sbin/mkinitramfs -o /dev/null 3.16.0-4-armmp >mkinitramfs.log 
2>&1

Then send the log so we can see how this is going wrong.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.

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

Bug#812593: linux-base: saa7134_alsa won't unload, reported in use by kernel

[John Smith]

Package: linux-base
Version: 3.5
Severity: normal
Tags: newcomer

Dear Maintainer,

Here is the summary:

   * What led up to the situation?
 I don't know when this problem first appeared as I was upgrading
regularly and did not need to remove the module. Recently I was forced to do a
fresh install and I needed to find out the card and tuner for the saa7134
module because the i2c system would not detect the correct card. To try
different settings I needed to unload and reload the saa7134 module multiple
times. But failed at the first attempt due to saa7134_alsa module being
reported as in use. Although lsmod says:
Module  Size  Used by
saa7134_alsa   17686  0

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
rmmod -f saa7134_alsa
modprobe -vfr saa7134_alsa

   * What was the outcome of this action?
modprobe reported this error:
modprobe: FATAL: Module saa7134_alsa is in use.
modprobe: ERROR: ../libkmod/libkmod-module.c:777
kmod_module_remove_module() could not remove 'saa7134_alsa': Device or resource
busy

   * What outcome did you expect instead?
removal of the module even without the "force" option, as was the case
in prior kernels.



-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libuuid-perl   0.05-1+b1
ii  udev   215-17+deb8u2
ii  util-linux 2.25.2-6

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information:
  linux-base/disk-id-convert-plan-no-relabel: true
  linux-base/disk-id-manual-boot-loader:
  linux-base/disk-id-update-failed:
  linux-base/do-bootloader-default-changed:
  linux-base/disk-id-convert-auto: true

Processed: found 784688 in 3.16.7-ckt20-1+deb8u2

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 784688 3.16.7-ckt20-1+deb8u2
Bug #784688 [linux-image-3.16.0-4-amd64] Thousands of "xen:balloon: Cannot add 
additional memory (-17) messages" despite dom0 ballooning disabled
Marked as found in versions linux/3.16.7-ckt20-1+deb8u2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
784688: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784688
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#603944: Updated patch

[Ben Hutchings]

On Wed, 2015-12-09 at 20:35 +, Ben Hutchings wrote:
> Serge, I'm sorry this patch hasn't had any attention for so long.
> 
> On Thu, 9 Dec 2010 15:20:28 -0600 "Serge E. Hallyn"  wrote:
> > Here is a patch (against the ubuntu package, just as example)
> > which instead of doing a dumb retry loop, waits for udev.
> >  
> > === modified file 'debian/changelog'
> > --- debian/changelog2010-04-26 15:17:47 +
> > +++ debian/changelog2010-12-08 21:44:32 +
> > @@ -1,3 +1,15 @@
> > +initramfs-tools (0.92bubuntu79) natty; urgency=low
> > +
> > +  * When using multipath, it is possible that mountroot() will race
> > +with udev's renaming of /dev/disk/by-uuid/{rootfs-uuid} from
> > +/dev/sd?? to /dev/mapper/something.  After multipath has grabbed
> > +the /dev/sd?? and until udev completes the rename, mounting
> > +/dev/disk/by-uuid/{rootfs-uuid} will fail with -EBUSY.  In that
> > +case, call 'udevsettle' to wait until udev has finished all its
> > +related actions. (Closes LP: #686832)
> > +
> > + -- Serge Hallyn   Fri, 19 Nov 2010 12:19:43 -0600
> 
> (Bear in mind that I have no experience of using multipath.)
> 
> If one path shows up quickly and the other rather later, can't we still
> end up mounting the single-path device rather than the multipath
> device?  How do we tell when multipath discovery is complete?
> 
> Does it even make sense to specify a multipath device by UUID rather
> than by its device-mapper name?  This certainly isn't supported for
> LVM.

You need to answer these questions, otherwise I'm just going to close
this bug.

Ben.

> >   initramfs-tools (0.92bubuntu78) lucid; urgency=low
> >   
> > * hooks/compcache: Escape $-expansions inside <
> >  
> > === modified file 'scripts/local'
> > --- scripts/local   2009-12-21 23:06:53 +
> > +++ scripts/local   2010-11-20 01:03:26 +
> > @@ -69,10 +69,19 @@
> >     # FIXME This has no error checking
> >     [ -n "${FSTYPE}" ] && modprobe ${FSTYPE}
> >   
> > -   # FIXME This has no error checking
> >     # Mount root
> > -   mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
> > -   mountroot_status="$?"
> > +   tries=0
> > +   ret=1
> > +   while [ $tries -lt 2 -a $ret -ne 0 ]; do
> > +   mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} 
> > ${rootmnt}
> > +   ret=$?
> > +   if [ $ret -ne 0 ]; then
> > +   echo "failed attempt $tries to mount $ROOT as root"
> > +   udevadm settle
> > +   tries=$((tries+1))
> > +   fi
> > +   done
> > +   mountroot_status=$ret
> >     if [ "$LOOP" ]; then
> >     if [ "$mountroot_status" != 0 ]; then
> >     if [ ${FSTYPE} = ntfs ] || [ ${FSTYPE} = vfat ]; then
> >  
> >  
> >  
> >  
-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.

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

Bug#784688: Thousands of "xen:balloon: Cannot add additional memory (-17) messages" despite dom0 ballooning disabled

[Ian Campbell]

On Fri, 2016-01-22 at 21:38 +0200, KSB wrote:
> Seen this behavior on earlier kernels (i.e. 3.14-2-amd64 pkg 3.14.15-2.) 
> and seems to be gone at least in 4.3

That's useful info thanks, I've been unable to pinpoint a culprit for this
for ages now.

Do you have a package version which you know to be good? How confident are
you that it is ok (sometimes the problem is intermittent)?

Lastly, is there any chance you upgraded the Xen packages at the same time?
I'm starting to wonder if maybe this is not a kernel issue.

Ian.

Re: Testing versatile kernel on Raspberry Pi?

[Diederik de Haas]

Thanks for your response :-)

On Monday 25 January 2016 13:23:20 Ian Campbell wrote:
> > I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4
> > kernel  for it. At least it is/was my understanding that the versatile
> > kernel is meant for the Raspberry Pi.
> 
> The versatile kernel is meant for ARM "veratile" development boards, and it
> also happens to be a reasonable platform emulated by QEMU.
> 
> It's not "versatile" in the sense of "adaptable".

I know. A slightly adapted version of the versatile kernel is used to do Pi 
simulation in QEMU and I've (also) created a repo for it: 
https://github.com/diederikdehaas/raspbian-kernel (default branch is 
kernel-3.18.x-qemu).

If you look at the changelog on linux (4.4~rc8-1~exp1) [1] you see the 
Raspberry Pi 2 explicitly mentioned and also references to BCM2836 (=Pi 2), 
BCM2835 (=Pi 1) and vc4 which stands for VideoCore4 which is the graphics chip 
for both the Pi 1 and 2.
Further reports on /. and phoronix [2] suggested that (full?) support for the 
Pi 1 and 2 was added to the upstream kernel and the changelog hinted at that 
as well. (A more recent report on /. [3] indicates that kernel 4.5 is more 
likely and it could be that it is primarily for the Pi 2.)

> I wasn't aware that any of the RPi support (for any model) had gone
> upstream.

It has taken a while, but it seems that major parts are now upstream-ed. 
See the changelog mentioned earlier.

> In any case for the RPi variants which use the older (non-armhf) processor
> you are most likely better off with the Raspbian derived distro than Debian
> armel.

That is correct, but I'm solely talking about the kernel here.

While most of the Raspbian packages work excellent, the kernel has always been 
somewhat of an issue. The Raspberry Pi Foundation (RPF) has their own linux 
kernel repo [4] (forked from upstream) and that has of course the best support 
for the RPi boards. But it is not 'properly packaged' (Debian style) and 
therefor doesn't have a linux-headers-* package [5] and all the other goodies 
I'm accustomed to with Debian kernels.

Plugwash has created Debian style kernels for the RPi, but that has its own 
drawbacks as it can safely be considered a hack and several things aren't 
working properly. And it's also quite a lot of work, which is a problem as 
he's the sole ftp-master/maintainer of the Raspbian repository. This is 
probably the reason that that kernel is still at 3.18, while the distributed 
kernel by the RPF has been on 4.1 for a while now.

As I got the impression that support for the RPi was now present in upstream 
and (therefor) the Debian kernels, I wanted to offer my help in testing it, if 
needed.
And being familiar with both Debian and the RPi and being the lead  
developer/maintainer of the Raspbian NetInstaller [6], I think I'm in a good 
position to do that.

Cheers,
  Diederik

[1] 
http://metadata.ftp-master.debian.org/changelogs/main/l/linux/linux_4.4-1~exp1_changelog
[2] https://www.phoronix.com/scan.php?page=article=linux-44-features
[3] 
http://linux.slashdot.org/story/16/01/24/1329206/linux-45-adds-raspberry-pi-2-support-amd-gpu-re-clocking-intel-kaby-lake
[4] https://github.com/raspberrypi/linux
[5] https://github.com/RPi-Distro/repo/issues/11
[6] https://github.com/debian-pi/raspbian-ua-netinst


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

Bug#812593: marked as done (linux-base: saa7134_alsa won't unload, reported in use by kernel)

[Debian Bug Tracking System]

Your message dated Mon, 25 Jan 2016 14:52:10 +
with message-id <1453733530.3734.208.ca...@decadent.org.uk>
and subject line Re: Bug#812593: linux-base: saa7134_alsa won't unload, 
reported in use by kernel
has caused the Debian Bug report #812593,
regarding linux-base: saa7134_alsa won't unload, reported in use by kernel
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
812593: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812593
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-base
Version: 3.5
Severity: normal
Tags: newcomer

Dear Maintainer,

Here is the summary:

   * What led up to the situation?
 I don't know when this problem first appeared as I was upgrading
regularly and did not need to remove the module. Recently I was forced to do a
fresh install and I needed to find out the card and tuner for the saa7134
module because the i2c system would not detect the correct card. To try
different settings I needed to unload and reload the saa7134 module multiple
times. But failed at the first attempt due to saa7134_alsa module being
reported as in use. Although lsmod says:
Module  Size  Used by
saa7134_alsa   17686  0

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
rmmod -f saa7134_alsa
modprobe -vfr saa7134_alsa

   * What was the outcome of this action?
modprobe reported this error:
modprobe: FATAL: Module saa7134_alsa is in use.
modprobe: ERROR: ../libkmod/libkmod-module.c:777
kmod_module_remove_module() could not remove 'saa7134_alsa': Device or resource
busy

   * What outcome did you expect instead?
removal of the module even without the "force" option, as was the case
in prior kernels.



-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libuuid-perl   0.05-1+b1
ii  udev   215-17+deb8u2
ii  util-linux 2.25.2-6

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information:
  linux-base/disk-id-convert-plan-no-relabel: true
  linux-base/disk-id-manual-boot-loader:
  linux-base/disk-id-update-failed:
  linux-base/do-bootloader-default-changed:
  linux-base/disk-id-convert-auto: true
--- End Message ---
--- Begin Message ---
On Mon, 2016-01-25 at 14:56 +0200, John Smith wrote:
> Package: linux-base
> Version: 3.5
> Severity: normal
> Tags: newcomer
> 
> Dear Maintainer,
> 
> Here is the summary:
> 
>    * What led up to the situation?
>  I don't know when this problem first appeared as I was upgrading
> regularly and did not need to remove the module. Recently I was forced to do a
> fresh install and I needed to find out the card and tuner for the saa7134
> module because the i2c system would not detect the correct card. To try
> different settings I needed to unload and reload the saa7134 module multiple
> times. But failed at the first attempt due to saa7134_alsa module being
> reported as in use. Although lsmod says:
> Module  Size  Used by
> saa7134_alsa   17686  0

This only lists other modules that use it, not any other objects that
have references to the module.

>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> rmmod -f saa7134_alsa
> modprobe -vfr saa7134_alsa
> 
>    * What was the outcome of this action?
> modprobe reported this error:
> modprobe: FATAL: Module saa7134_alsa is in use.
> modprobe: ERROR: ../libkmod/libkmod-module.c:777
> kmod_module_remove_module() could not remove 'saa7134_alsa': Device or 
> resource
> busy

Most likely some process still had the sound device open.

>    * What outcome did you expect instead?
> removal of the module even without the "force" option, as was the case
> in prior kernels.

Module removal is not generally supported, so closing this.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.

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

Re: Testing versatile kernel on Raspberry Pi?

[Ben Hutchings]

On Mon, 2016-01-25 at 15:46 +0100, Diederik de Haas wrote:
> Thanks for your response :-)
> 
> On Monday 25 January 2016 13:23:20 Ian Campbell wrote:
> > > I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4
> > > kernel  for it. At least it is/was my understanding that the versatile
> > > kernel is meant for the Raspberry Pi.
> > 
> > The versatile kernel is meant for ARM "veratile" development boards, and it
> > also happens to be a reasonable platform emulated by QEMU.
> > 
> > It's not "versatile" in the sense of "adaptable".
> 
> I know. A slightly adapted version of the versatile kernel is used to do Pi 
> simulation in QEMU and I've (also) created a repo for it: 
> https://github.com/diederikdehaas/raspbian-kernel (default branch is 
> kernel-3.18.x-qemu).
> 
> If you look at the changelog on linux (4.4~rc8-1~exp1) [1] you see the 
> Raspberry Pi 2 explicitly mentioned and also references to BCM2836 (=Pi 2), 
> BCM2835 (=Pi 1) and vc4 which stands for VideoCore4 which is the graphics 
> chip 
> for both the Pi 1 and 2.
> Further reports on /. and phoronix [2] suggested that (full?) support for the 
> Pi 1 and 2 was added to the upstream kernel and the changelog hinted at that 
> as well. (A more recent report on /. [3] indicates that kernel 4.5 is more 
> likely and it could be that it is primarily for the Pi 2.)
[...]

The armmp kernel flavour should now support the BCM2836 and the Pi 2,
but *not* the BCM2835.  Also, Debian's armhf port is built for ARMv7
whereas the BCM2835 implements ARMv6.  Most of the peripherals are the
same between these two chips, so the driver names include 'bcm2835'.

I haven't yet had confirmation that it actually does work.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.

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

Re: Testing versatile kernel on Raspberry Pi?

[Ian Campbell]

On Sat, 2016-01-16 at 03:22 +0100, Diederik de Haas wrote:
> Hi!
> 
> I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4 kernel 
> for it. At least it is/was my understanding that the versatile kernel is 
> meant 
> for the Raspberry Pi. 

The versatile kernel is meant for ARM "veratile" development boards, and it
also happens to be a reasonable platform emulated by QEMU.

It's not "versatile" in the sense of "adaptable".

I wasn't aware that any of the RPi support (for any model) had gone
upstream.

In any case for the RPi variants which use the older (non-armhf) processor
you are most likely better off with the Raspbian derived distro than Debian
armel.

For the variant with the newer CPU core which is armhf compatible we should
consider enabling support in the armhf kernels, for which support being in
the mainline kernel is a prerequisite.

Ian.

Re: Testing versatile kernel on Raspberry Pi?

[Ian Campbell]

On Mon, 2016-01-25 at 14:56 +, Ben Hutchings wrote:
> On Mon, 2016-01-25 at 15:46 +0100, Diederik de Haas wrote:
> > Thanks for your response :-)
> > 
> > On Monday 25 January 2016 13:23:20 Ian Campbell wrote:
> > > > I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's
> > > > 4.4
> > > > kernel  for it. At least it is/was my understanding that the
> > > > versatile
> > > > kernel is meant for the Raspberry Pi.
> > > 
> > > The versatile kernel is meant for ARM "veratile" development boards,
> > > and it
> > > also happens to be a reasonable platform emulated by QEMU.
> > > 
> > > It's not "versatile" in the sense of "adaptable".
> > 
> > I know. A slightly adapted version of the versatile kernel is used to
> > do Pi 
> > simulation in QEMU and I've (also) created a repo for it: 
> > https://github.com/diederikdehaas/raspbian-kernel (default branch is 
> > kernel-3.18.x-qemu).
> > 
> > If you look at the changelog on linux (4.4~rc8-1~exp1) [1] you see the 
> > Raspberry Pi 2 explicitly mentioned and also references to BCM2836 (=Pi
> > 2), 
> > BCM2835 (=Pi 1) and vc4 which stands for VideoCore4 which is the
> > graphics chip 
> > for both the Pi 1 and 2.
> > Further reports on /. and phoronix [2] suggested that (full?) support
> > for the 
> > Pi 1 and 2 was added to the upstream kernel and the changelog hinted at
> > that 
> > as well. (A more recent report on /. [3] indicates that kernel 4.5 is
> > more 
> > likely and it could be that it is primarily for the Pi 2.)
> [...]
> 
> The armmp kernel flavour should now support the BCM2836 and the Pi 2,

I missed this going in, thanks!

> but *not* the BCM2835.  Also, Debian's armhf port is built for ARMv7
> whereas the BCM2835 implements ARMv6.  Most of the peripherals are the
> same between these two chips, so the driver names include 'bcm2835'.
> 
> I haven't yet had confirmation that it actually does work.

Ian.

Processed: submitter 790722

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> submitter 790722 Stephen Powell 
Bug #790722 [initramfs-tools] mkinitramfs fails with latest udev (>= 220-7) on 
some systems
Changed Bug submitter to 'Stephen Powell ' from 
'Stephen Powell '
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
790722: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790722
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#795833: initramfs-tools: add mountroot failure support to allow meaningful messages and recovery attempts

[Ben Hutchings]

On Wed, 2015-12-09 at 16:05 +, Ben Hutchings wrote:
> On Mon, 17 Aug 2015 10:52:14 +0100 Andy Whitcroft  wrote:
> > Package: initramfs-tools
> > Version: 0.120
> > Severity: normal
> >  
> > Allow hooks to supply specific root mount failure handlers.  These can
> > both report more specific failure reasons, and in some cases may even be
> > able to attempt recovery.  This is useful for more complex scenarios
> > such as LVM and mdadm setups.
> >  
> > We use this in Ubuntu to allow augmented lvm2 and mdadm hooks to recover
> > failed raids and the like.
> >  
> > NOTE: that the splash handling here may well be Ubuntu specific.
> 
> Thanks for your patch.
> 
> Can you explain why this was implemented by extending existing scripts
> rather than by adding a new phase (possibly with stamp files to control
> what they do)?
[...]

I do need some justification of this change.

Also, could we have a meeting (IRC or irl) at some point about the
remaining differences between the Debian/upstream and Ubuntu packages,
and how to resolve them?

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.

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

Re: Testing versatile kernel on Raspberry Pi?

[Diederik de Haas]

On Monday 25 January 2016 15:07:50 Ian Campbell wrote:
> > The armmp kernel flavour should now support the BCM2836 and the Pi 2,
> 
> I missed this going in, thanks!
> 
> > but *not* the BCM2835.  Also, Debian's armhf port is built for ARMv7
> > whereas the BCM2835 implements ARMv6.  Most of the peripherals are the
> > same between these two chips, so the driver names include 'bcm2835'.

Thanks Ian and Ben for the clarification!

> > I haven't yet had confirmation that it actually does work.

I just installed linux-image-4.4.0-trunk-armmp-lpae (as /proc/cpuinfo showed 
lpae) and rebooted ... and that failed completely. I didn't even see the 
message "Uncompressing Linux... done, booting the kernel."

I'll grab the latest RPi firmware files and put that in the device and see 
whether that makes any difference...

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

Bug#807527: [PATCH initramfs-tools 3/3] initramfs-tools.8: Add brief description of configuration hooks and files

[Ben Hutchings]

Control: tag -1 patch pending
---
Closes: #807527
Signed-off-by: Ben Hutchings 
---
 initramfs-tools.8 | 21 +
 1 file changed, 21 insertions(+)

diff --git a/initramfs-tools.8 b/initramfs-tools.8
index ba00295..e6bc5e2 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -130,6 +130,10 @@ loads generic IDE/ATA chipset support on boot.
 Valid boot and hook scripts names consist solely of alphabetics, numerics,
 dashes and underscores. Other scripts are discarded.
 
+.SS Configuration hook scripts
+These are used to override the user configuration where necessary, for
+example to force use of busybox instead of klibc utilities.
+
 .SS Hook scripts
 These are used when an initramfs image is created and not included in the
 image itself. They can however cause files to be included in the image.
@@ -142,6 +146,18 @@ kernel boot in the early user-space before the root 
partition has been
 mounted.
 
 
+.SH CONFIGURATION HOOK SCRIPTS
+
+Configuration hook scripts can be found in
+/usr/share/initramfs-tools/conf-hooks.d.  They are sourced by
+mkinitramfs after the configuration files in /etc and before running
+any hook scripts.  They can override any of the variables documented
+in \fIinitramfs.conf\fR(5), but this should be done only if absolutely
+necessary.  For example, if a package's boot script requires commands
+not provided by klibc-utils, it should also install a configuration
+hook that sets \fBBUSYBOX=y\fR.
+
+
 .SH HOOK SCRIPTS
 
 Hooks can be found in two places: /usr/share/initramfs-tools/hooks and
@@ -156,6 +172,11 @@ according to \fBtheir\fR PREREQ values and executed. This 
mean that currently
 there is no possibility to have a local script (/etc/initramfs-tools) get
 executed before one from the package (/usr/share/initramfs-tools).
 
+If a hook script requires configuration beyond the exported variables
+listed below, it should read a private configuration file that is
+separate from the /etc/initramfs-tools directory.  It \fImust not\fR
+read initramfs-tools configuration files directly.
+
 .SS Header
 In order to support prereqs, each script should begin with the following lines:
 


signature.asc
Description: Digital signature

Bug#807527: [PATCH initramfs-tools 1/3] initramfs-tools.8: Update list of variables exported to hook scripts

[Ben Hutchings]

Signed-off-by: Ben Hutchings 
---
 initramfs-tools.8 | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/initramfs-tools.8 b/initramfs-tools.8
index a276be3..d13aec8 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -280,13 +280,12 @@ allows arch specific hook additions.
 \fB\fI verbose
 corresponds to the verbosity of the update-initramfs run.
 .TP
-\fB\fI KEYMAP
-sets if a keymap needs to be added to initramfs.
+\fB\fI BUSYBOX, KEYMAP, MODULES
+are as described in \fIinitramfs.conf\fR(5).
 .TP
-\fB\fI MODULES
-specifies which kind of modules should land on initramfs.
-This setting shouldn't be overridden by hook script, but can guide them
-on how much they need to include on initramfs.
+\fB\fI BUSYBOXDIR
+is the directory where busybox utilities should be installed from, or
+empty if busybox is not being used.
 
 
 .SH BOOT SCRIPTS



signature.asc
Description: Digital signature

Processed: [PATCH initramfs-tools 3/3] initramfs-tools.8: Add brief description of configuration hooks and files

[Debian Bug Tracking System]

Processing control commands:

> tag -1 patch pending
Bug #807527 [initramfs-tools] initramfs-tools: Please provide an API or best 
practices for custom initramfs hook configuration
Added tag(s) patch and pending.

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

Re: Testing versatile kernel on Raspberry Pi?

[Diederik de Haas]

On Monday 25 January 2016 14:58:27 Ian Campbell wrote:
> > As I got the impression that support for the RPi was now present in
> > upstream and (therefor) the Debian kernels,
> 
> The "therefor" won't happen automatically, someone will need to file a
> wishlist bug asking for the relevant options to be enabled in the Debian
> kernel configuration.
> 
> For the RPi's with the newer CPU cores it makes clear sense to do that in
> the armhf/armmp kernel flavour (since it is the "multiplatform" flavour,
> and the only one we want to support).

I'll give it a try, but first have to learn about the armmp stuff.

Here is the default kernel configuration for the RPi 2: 
https://github.com/raspberrypi/linux/blob/rpi-4.4.y/arch/arm/configs/bcm2709_defconfig
 
(which does not seem part of 
https://sources.debian.net/src/linux/4.4-1~exp1/arch/arm/configs/)

> For the RPi's with the older cores it wouldn't seem to make much sense to
> enable it in the armel/versatile flavour (because I can't see why it fits
> there, despite folks apparently adding it there), but equally I'm not sure
> we want to be adding new flavours to armel (which is essentially on the
> downward slope of the support lifecycle at this stage). Perhaps others
> around here feel differently though.

Bummer for me as it won't solve the issue I hoped it would solve, but I'll try 
other avenues for that. 
But still, thanks for clarifying :-)

Cheers,
  Diederik

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

Re: Testing versatile kernel on Raspberry Pi?

[Sebastian Reichel]

Hi,

On Mon, Jan 25, 2016 at 05:39:40PM +0100, Diederik de Haas wrote:
> On Monday 25 January 2016 14:58:27 Ian Campbell wrote:
> > > As I got the impression that support for the RPi was now present in
> > > upstream and (therefor) the Debian kernels,
> > 
> > The "therefor" won't happen automatically, someone will need to file a
> > wishlist bug asking for the relevant options to be enabled in the Debian
> > kernel configuration.
> > 
> > For the RPi's with the newer CPU cores it makes clear sense to do that in
> > the armhf/armmp kernel flavour (since it is the "multiplatform" flavour,
> > and the only one we want to support).
> 
> I'll give it a try, but first have to learn about the armmp stuff.
> 
> Here is the default kernel configuration for the RPi 2: 
> https://github.com/raspberrypi/linux/blob/rpi-4.4.y/arch/arm/configs/bcm2709_defconfig
>  
> (which does not seem part of 
> https://sources.debian.net/src/linux/4.4-1~exp1/arch/arm/configs/)

The kernel from the Raspberry Pi foundation and the mainline kernel
have different config options, so that won't be of much use. Check
mainline's arch/arm/configs/bcm2835_defconfig instead.

> > For the RPi's with the older cores it wouldn't seem to make much sense to
> > enable it in the armel/versatile flavour (because I can't see why it fits
> > there, despite folks apparently adding it there), but equally I'm not sure
> > we want to be adding new flavours to armel (which is essentially on the
> > downward slope of the support lifecycle at this stage). Perhaps others
> > around here feel differently though.
> 
> Bummer for me as it won't solve the issue I hoped it would solve, but I'll 
> try 
> other avenues for that. But still, thanks for clarifying :-)

Another option would be adding RPi1 support to the armhf armmp
kernel. I guess the benefits of ARMv7 vs ARMv6 is neglectable for
the kernel (no floating point operations and Thumb2 should stay
disabled because of errata 430973 on some older Cortex-A8s [i.e.
on N900]) and one could use armel userland + armmp kernel from armhf.

-- Sebastian


signature.asc
Description: PGP signature

Bug#807527: [PATCH initramfs-tools 2/3] initramfs-tools.8: Add a new section for the general description of scripts

[Ben Hutchings]

Signed-off-by: Ben Hutchings 
---
 initramfs-tools.8 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/initramfs-tools.8 b/initramfs-tools.8
index d13aec8..ba00295 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -125,7 +125,7 @@ loads netconsole linux modules with the chosen args.
 loads generic IDE/ATA chipset support on boot.
 
 
-.SH HOOK SCRIPTS
+.SH SCRIPTS
 
 Valid boot and hook scripts names consist solely of alphabetics, numerics,
 dashes and underscores. Other scripts are discarded.
@@ -142,6 +142,8 @@ kernel boot in the early user-space before the root 
partition has been
 mounted.
 
 
+.SH HOOK SCRIPTS
+
 Hooks can be found in two places: /usr/share/initramfs-tools/hooks and
 /etc/initramfs-tools/hooks. They are executed during generation of the
 initramfs-image and are responsible for including all the necessary components



signature.asc
Description: Digital signature

Bug#790722: mkinitramfs fails with latest udev (>= 220-7) on some systems

[Ben Hutchings]

On Wed, 2015-12-09 at 22:09 +, Ben Hutchings wrote:
[...]
> > By the way, I am still hoping to get my parse_numeric patch, available at
> > http://users.wowway.com/~zlinuxman/kernel/parse_numeric.patch, included in
> > initramfs-tools.
> 
> It's not there any more...
> 
> > The current code cannot handle a kernel composite device number
> > greater than 0xf.  With the patch, it should be able to handle any valid
> > kernel composite device number.
> 
> ...but I sent you my patch for this.  It's also on that git branch.
> 
> Please can you test initramfs-tools built from that branch?  Note that
> this has the binary package split into initramfs-tools and initramfs-
> tools-core, and you'll need to install both.

These changes are now in unstable; please can you confirm whether the
bug is fixed?  If I don't hear from you I'll eventually just close
this.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.

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

Processed: Re: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/*

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #767448 [initramfs-tools] No way to override settings from 
/usr/share/initramfs-tools/conf-hooks.d/*
Added tag(s) moreinfo.

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

Bug#767448: No way to override settings from /usr/share/initramfs-tools/conf-hooks.d/*

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2015-12-11 at 02:43 +, Ben Hutchings wrote:
> On Fri, 31 Oct 2014 06:17:46 +0100 Piotr Jurkiewicz  wrote:
> > Package: initramfs-tools
> >  
> > There is no way for user to override settings from 
> > /usr/share/initramfs-tools/conf-hooks.d.
> >  
> > For example, dropbear package in file /usr/.../conf-hooks.d/dropbear 
> > sets UMASK variable to 0077. User cannot override this with his own 
> > setting in /etc.
> >  
> > The only way to do that is to edit /usr/.../conf-hooks.d/dropbear file 
> > directly and change UMASK. However, such change will be of course 
> > overwritten on a next update of dropbear package.
> 
> Actually, you can use dpkg-divert to rename this file to somewhere else
> that initramfs-tools will ignore it.  dpkg will follow that renaming so
> it won't undo your change.
> 
> > In my opinion, user-provided settings from /etc/* should have priority 
> > over package-provided settings form /usr/*.
> 
> This is a tricky one.  Some packages really do need to override
> initramfs.conf, to enable features they depend on.  I agree we need to
> come up with a better approach for controlling the UMASK variable.

The UMASK variable is *documented* as affecting only the permissions
for the initramfs image (which it doesn't seem to do reliably!) but it
also affects the permissions for the files inside the initramfs.

When dropbear is used in the initramfs, the host private key must be
kept secret and so the initramfs image must not be world-readable.  But
most of the files installed in the initramfs can be world-readable.  Is
that what you want to change?

I don't think we can simply 'fix' the behaviour of UMASK now, because
other packages may depend on it.  I think that the proper fix may
require introducing a new configuration variable, e.g. 'SECRET' that
really only affects the permissions of the initramfs image.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.

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

Bug#784688: Thousands of "xen:balloon: Cannot add additional memory (-17) messages" despite dom0 ballooning disabled

[KSB]

Do you have a package version which you know to be good? How confident are
you that it is ok (sometimes the problem is intermittent)?

Lastly, is there any chance you upgraded the Xen packages at the same time?
I'm starting to wonder if maybe this is not a kernel issue.


Sorry, but there is chance, sadly.

But I checked logs more thoroughly and found it even on more recent kernels:
1) Lot of messages on 3.14-2-amd64 with xen-4.6, 13 domU's.
2) 4.3.0-1-amd64 xen-4.6, only two messages shortly after boot, only 1 
domU running:

[   12.473778] xen:balloon: Cannot add additional memory (-17)
[   21.673298] xen:balloon: Cannot add additional memory (-17)
uptime 17 days.

Previous on same machine was 4.2.0-1-amd64 with more (-17)'s

3) 4.3.0-1-amd64, one month, several reboots, average 4 domU's, and no 
messages


4) 3.16.0-4-amd64, xen-4.1, 22 domU's, uptime 188 days, in last month I 
see only

Jan 7 14:12:08
Jan 7 14:12:08
Jan 7 14:12:08
Jan 7 14:12:08
Jan 7 14:27:47
Jan 7 14:27:47
Jan 7 14:27:47
Jan 7 14:27:48
and this is roughly the time last machine was created(started).

Bug#810821: linux-image-3.16.0-4-amd64: BCM5720 with tg3 module: transmit timed out and then resetting.

[Adam Pribyl]

Package: src:linux
Version: 3.16.7-ckt11-1+deb8u6
Followup-For: Bug #810821

We also experience link dropouts on tg3 with kernel 3.16 from debian on heavily 
used internet GW with NAT. No XEN.

This is very common after few hours of run. 
Jan 17 06:54:17 c kernel: [141903.348634] tg3 :06:00.0 eth0: Link is down
Jan 17 06:54:20 c kernel: [141906.644181] tg3 :06:00.0 eth0: Link is up at 
1000 Mbps, full duplex
Jan 17 06:54:20 c kernel: [141906.644200] tg3 :06:00.0 eth0: Flow control 
is on for TX and on for RX

First usually the WD timeouts then link dropouts occure every then and now. We 
have to switch to 3.2 kernel that does not suffer from that bug.

Jan 13 18:40:44 c kernel: [33660.780023] [ cut here ]
Jan 13 18:40:44 c kernel: [33660.780040] WARNING: CPU: 3 PID: 0 at 
/build/linux-x1KGLI/linux-3.16.7-ckt11/net/sched/sch_generic.c:264 
dev_watchdog+0x236/0x240()
Jan 13 18:40:44 c kernel: [33660.780043] NETDEV WATCHDOG: eth0 (tg3): transmit 
queue 0 timed out
Jan 13 18:40:44 c kernel: [33660.780045] Modules linked in: binfmt_misc 
nf_conntrack_netlink tun nfnetlink nfsd auth_rpcgss oid_registry nfs_acl nfs 
lockd fscache sunrpc 8021q garp stp mrp llc nf_nat_ppt
p nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre xt_nat xt_recent 
iptable_nat nf_nat_ipv4 nf_nat xt_LOG ipt_REJECT nf_conntrack_ipv4 
nf_defrag_ipv4 xt_tcpudp xt_multiport xt_conntrack nf_conntrack ip
table_filter iptable_mangle ip_tables x_tables radeon iTCO_wdt joydev ttm evdev 
iTCO_vendor_support drm_kms_helper drm i2c_algo_bit lpc_ich mfd_core psmouse 
serio_raw pcspkr i2c_i801 processor i2c_core e752x_ed
ac thermal_sys edac_core rng_core shpchp button dummy loop autofs4 ext4 crc16 
mbcache jbd2 sd_mod crc_t10dif crct10dif_generic crct10dif_common hid_generic 
usbhid hid sg sr_mod cdrom ata_generic ehci_pci uhci_h
cd ata_piix ehci_hcd libata usbcore usb_common mptspi scsi_transport_spi 
mptscsih tg3 mptbase ptp pps_core libphy scsi_mod
Jan 13 18:40:44 c kernel: [33660.780142] CPU: 3 PID: 0 Comm: swapper/3 Not 
tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1+deb8u6
Jan 13 18:40:44 c kernel: [33660.780145] Hardware name: IBM eserver xSeries 336 
-[883715Y]-/, BIOS -[APE121AUS-1.06]- 01/17/2005
Jan 13 18:40:44 c kernel: [33660.780148]  0009 8150b4e5 
8800bfb83e28 81067767
Jan 13 18:40:44 c kernel: [33660.780153]   8800bfb83e78 
0005 0003
Jan 13 18:40:44 c kernel: [33660.780158]  8800bb41a000 810677cc 
81777fa8 0030
Jan 13 18:40:44 c kernel: [33660.780164] Call Trace:
Jan 13 18:40:44 c kernel: [33660.780166][] ? 
dump_stack+0x41/0x51
Jan 13 18:40:44 c kernel: [33660.780180]  [] ? 
warn_slowpath_common+0x77/0x90
Jan 13 18:40:44 c kernel: [33660.780185]  [] ? 
warn_slowpath_fmt+0x4c/0x50
Jan 13 18:40:44 c kernel: [33660.780192]  [] ? 
handle_fasteoi_irq+0xee/0x150
Jan 13 18:40:44 c kernel: [33660.780201]  [] ? 
dev_watchdog+0x236/0x240
Jan 13 18:40:44 c kernel: [33660.780205]  [] ? 
dev_graft_qdisc+0x70/0x70
Jan 13 18:40:44 c kernel: [33660.780211]  [] ? 
call_timer_fn+0x31/0x100
Jan 13 18:40:44 c kernel: [33660.780216]  [] ? 
dev_graft_qdisc+0x70/0x70
Jan 13 18:40:44 c kernel: [33660.780221]  [] ? 
run_timer_softirq+0x209/0x2f0
Jan 13 18:40:44 c kernel: [33660.780226]  [] ? 
__do_softirq+0xf1/0x290
Jan 13 18:40:44 c kernel: [33660.780230]  [] ? 
irq_exit+0x95/0xa0
Jan 13 18:40:44 c kernel: [33660.780235]  [] ? 
smp_apic_timer_interrupt+0x45/0x60
Jan 13 18:40:44 c kernel: [33660.780241]  [] ? 
apic_timer_interrupt+0x6d/0x80
Jan 13 18:40:44 c kernel: [33660.780243][] ? 
mwait_idle+0x62/0xa0
Jan 13 18:40:44 c kernel: [33660.780254]  [] ? 
cpu_startup_entry+0x340/0x400
Jan 13 18:40:44 c kernel: [33660.780259]  [] ? 
start_secondary+0x20f/0x2d0
Jan 13 18:40:44 c kernel: [33660.780263] ---[ end trace 6c3fb5d7bc624d1a ]---
Jan 13 18:40:44 c kernel: [33663.204179] tg3 :06:00.0 eth0: Link is down
Jan 13 18:40:47 c kernel: [33666.604558] tg3 :06:00.0 eth0: Link is up at 
1000 Mbps, full duplex
Jan 13 18:40:47 c kernel: [33666.604565] tg3 :06:00.0 eth0: Flow control is 
on for TX and on for RX

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: IBM
product_name: eserver xSeries 336 -[883715Y]-
product_version: 
chassis_vendor: IBM
chassis_version: 
bios_vendor: IBM
bios_version: -[APE121AUS-1.06]-
board_vendor: IBM
board_name: 
board_version: 

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation E7520 Memory Controller Hub 
[8086:3590] (rev 0c)
Subsystem: IBM Device [1014:02dc]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: e752x_edac

00:00.1 Unassigned class [ff00]: Intel Corporation E7525/E7520 Error Reporting 
Registers [8086:3591] (rev 

Bug#812207: CVE-2016-0728

[Ben Hutchings]

On Mon, 2016-01-25 at 17:06 -0800, Zachary Loafman wrote:
> On Jan 25, 2016 4:49 PM, "Ben Hutchings"  wrote:
> > 
> > On Mon, 2016-01-25 at 15:23 -0800, Zachary Loafman wrote:
> > > Can this issue be treated with high importance?
> > 
> > You would have got a faster response if you had reported the bug
> > against a real package name in the first place.
> 
> Apologies, I'm not actually original reporter. I was notified of the bug
> report today and it matches something we found in internal testing after
> using an image that had the CVE fixed. Anyone who updates to fix that CVE
> may run across the same.

Sorry, I should have looked at the messages more closely.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.

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

Bug#812207: CVE-2016-0728

[Akihiro Suda]

> You would have got a faster response if you had reported the bug
> against a real package name in the first place.

I'm sorry for that.

2016-01-26 10:29 GMT+09:00 Ben Hutchings :
> On Mon, 2016-01-25 at 17:06 -0800, Zachary Loafman wrote:
>> On Jan 25, 2016 4:49 PM, "Ben Hutchings"  wrote:
>> >
>> > On Mon, 2016-01-25 at 15:23 -0800, Zachary Loafman wrote:
>> > > Can this issue be treated with high importance?
>> >
>> > You would have got a faster response if you had reported the bug
>> > against a real package name in the first place.
>>
>> Apologies, I'm not actually original reporter. I was notified of the bug
>> report today and it matches something we found in internal testing after
>> using an image that had the CVE fixed. Anyone who updates to fix that CVE
>> may run across the same.
>
> Sorry, I should have looked at the messages more closely.
>
> Ben.
>
> --
> Ben Hutchings
> Q.  Which is the greater problem in the world today, ignorance or apathy?
> A.  I don't know and I couldn't care less.

Bug#812207: linux: AUFS can hang up; Please update to v20160111 or later

[Ben Hutchings]

Control: tag -1 patch moreinfo

On Thu, 21 Jan 2016 15:08:17 + Akihiro Suda  wrote:
> Source: linux-image-3.16.0-4

Please use 'reportbug kernel' to report any future kernel bugs, as that
will select the correct package name automatically.

> Version: 3.16.7-ckt20
> Severity: important
> 
> Dear Maintainer,
> 
> AUFS can hang up (more precisely, produces unkillable processes) with kernel 
> 3.16.7-ckt20 due to commit 296291cdd1629c308114504b850dc343eabc278 appeared 
> in ckt20.
> http://kernel.ubuntu.com/git/ubuntu/linux.git/tag/?h=linux-3.16.y=v3.16.7-ckt20
> http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/?h=linux-3.16.y=475a23000dd8d2f264bab9d6eb71a2a6b9d4de72
> 
> Many docker users have been experiencing this issue: 
> https://github.com/docker/docker/issues/18180
> 
> The issue has been fixed since AUFS v20160111: 
> http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/5345
> So I suggest updating AUFS to v20160111 or later.

We can't do that because it is no longer supported on Linux 3.x (and
not all the changes would be suitable for a stable update, anyway).

> Although I didn't test for 3.16.7, I think merging this commit is enough: 
> https://github.com/sfjro/aufs4-linux/commit/f60d586b7b8cae42bacc603d192810db85278d3c

That and the previous commit appear to be sufficient, though they
needed some minor changes.  Please can you test whether the attached
patches work, following the procedure at
.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.From: "J. R. Okajima" 
Date: Mon, 4 Jan 2016 23:31:56 +0900
Subject: aufs: tiny, extract a new func xino_fwrite_wkq()
Origin: https://github.com/sfjro/aufs4-standalone/commit/44c72b4050c2563cc6053b91c47885e0409943a5
Bug-Debian: https://bugs.debian.org/812207

Signed-off-by: J. R. Okajima 
[bwh: Backported to aufs3.16:
 - s/vfs_writef_t/au_writef_t/
 - Adjust context]
---
 fs/aufs/xino.c | 47 +++
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/fs/aufs/xino.c b/fs/aufs/xino.c
index 44bbede..cde6ce7 100644
--- a/fs/aufs/xino.c
+++ b/fs/aufs/xino.c
@@ -95,35 +95,42 @@ static void call_do_xino_fwrite(void *args)
 	*a->errp = do_xino_fwrite(a->func, a->file, a->buf, a->size, a->pos);
 }
 
+static ssize_t xino_fwrite_wkq(au_writef_t func, struct file *file, void *buf,
+			   size_t size, loff_t *pos)
+{
+	ssize_t err;
+	int wkq_err;
+	struct do_xino_fwrite_args args = {
+		.errp	= ,
+		.func	= func,
+		.file	= file,
+		.buf	= buf,
+		.size	= size,
+		.pos	= pos
+	};
+
+	/*
+	 * it breaks RLIMIT_FSIZE and normal user's limit,
+	 * users should care about quota and real 'filesystem full.'
+	 */
+	wkq_err = au_wkq_wait(call_do_xino_fwrite, );
+	if (unlikely(wkq_err))
+		err = wkq_err;
+
+	return err;
+}
+
 ssize_t xino_fwrite(au_writef_t func, struct file *file, void *buf, size_t size,
 		loff_t *pos)
 {
 	ssize_t err;
 
-	/* todo: signal block and no wkq? */
 	if (rlimit(RLIMIT_FSIZE) == RLIM_INFINITY) {
 		lockdep_off();
 		err = do_xino_fwrite(func, file, buf, size, pos);
 		lockdep_on();
-	} else {
-		/*
-		 * it breaks RLIMIT_FSIZE and normal user's limit,
-		 * users should care about quota and real 'filesystem full.'
-		 */
-		int wkq_err;
-		struct do_xino_fwrite_args args = {
-			.errp	= ,
-			.func	= func,
-			.file	= file,
-			.buf	= buf,
-			.size	= size,
-			.pos	= pos
-		};
-
-		wkq_err = au_wkq_wait(call_do_xino_fwrite, );
-		if (unlikely(wkq_err))
-			err = wkq_err;
-	}
+	} else
+		err = xino_fwrite_wkq(func, file, buf, size, pos);
 
 	return err;
 }
From: "J. R. Okajima" 
Date: Mon, 4 Jan 2016 23:33:09 +0900
Subject: aufs: for 4.3, XINO handles EINTR from the dying process
Origin: https://github.com/sfjro/aufs4-standalone/commit/5e439ff30c92143d9a9ee3401a84e34c9852533b
Bug-Debian: https://bugs.debian.org/812207

By the commit
	296291c 2015-10-23 mm: make sendfile(2) killable
new_sync_write() (or ->write()) may return EINTR ealier even if it can
succeed the operation. It causes an endless loop in aufs
do_xino_fwrite().
Here is a dirty workaround to retry do_xino_fwrite() in another context
(workqueue).

Reported-by: Akihiro Suda 
Tested-by: Akihiro Suda 
See-also: http://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05231.html
Signed-off-by: J. R. Okajima 
[bwh: Backported to aufs3.16: s/vfs_writef_t/au_writef_t/]
---
 fs/aufs/xino.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/fs/aufs/xino.c b/fs/aufs/xino.c
index cde6ce7..e3cab07 100644
--- a/fs/aufs/xino.c
+++ b/fs/aufs/xino.c
@@ -53,6 +53,9 @@ ssize_t xino_fread(vfs_readf_t func, struct file *file, void *kbuf, size_t size,
 
 /* 

Processed: Re: linux: AUFS can hang up; Please update to v20160111 or later

[Debian Bug Tracking System]

Processing control commands:

> tag -1 patch moreinfo
Bug #812207 [linux-image-3.16.0-4-amd64] linux: AUFS can hang up; Please update 
to v20160111 or later
Added tag(s) patch and moreinfo.

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

Processed: reassign 812207 to src:linux, found 812207 in 3.2.73-1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 812207 src:linux 3.16.7-ckt20-1
Bug #812207 [linux-image-3.16.0-4-amd64] linux: AUFS can hang up; Please update 
to v20160111 or later
Bug reassigned from package 'linux-image-3.16.0-4-amd64' to 'src:linux'.
No longer marked as found in versions 3.16.7-ckt20.
Ignoring request to alter fixed versions of bug #812207 to the same values 
previously set
Bug #812207 [src:linux] linux: AUFS can hang up; Please update to v20160111 or 
later
Marked as found in versions linux/3.16.7-ckt20-1.
> found 812207 3.2.73-1
Bug #812207 [src:linux] linux: AUFS can hang up; Please update to v20160111 or 
later
Marked as found in versions linux/3.2.73-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
812207: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812207
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#812207: CVE-2016-0728

[Ben Hutchings]

On Mon, 2016-01-25 at 15:23 -0800, Zachary Loafman wrote:
> Can this issue be treated with high importance?

You would have got a faster response if you had reported the bug
against a real package name in the first place.

> Right now, there is no
> version of jessie-stable or wheezy-backports which is both safe from this
> AUFS hang and safe from CVE-2016-0728, which has a public exploit. The
> current recommendation on https://github.com/docker/docker/issues/18180 is
> to downgrade to a kernel version which is vulnerable to this CVE (I
> believe).

You can possibly mitigate this by using systemtap to disable use of the
keyctl system call, if you don't run anything that needs it (such as an
NFS client).

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.

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

Xen XL blocked on linux-image-4.3.0.1-amd64 4.3.3-5

[Torben Schou Jensen]

Something with Xen is unstable since upgrade to kernel 4.3.0.1.

After 24 hours since last boot I suddenly on Dom0 get:

Jan 25 09:37:01 debian CRON[20287]: (root) CMD (if test -x
/usr/sbin/apticron; then /usr/sbin/apticron --cron; else true; fi) Jan 25
09:37:52 debian kernel: [85204.136136] INFO: task xl:19753 blocked for
more than 120 seconds.
Jan 25 09:37:52 debian kernel: [85204.136179]   Not tainted
4.3.0-1-amd64 #1
Jan 25 09:37:52 debian kernel: [85204.136202] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 25 09:37:52 debian kernel: [85204.136240] xl  D
88018f4ca0c0 0 19753  19749 0x
Jan 25 09:37:52 debian kernel: [85204.136245]  8802080525c0
0286 880179aca0c0 8800744b
Jan 25 09:37:52 debian kernel: [85204.136249]  8800744afe00
81d09114 8802080525c0 
Jan 25 09:37:52 debian kernel: [85204.136252]  81d09118
8158113f 81d09110 815813ca
Jan 25 09:37:52 debian kernel: [85204.136255] Call Trace:
Jan 25 09:37:52 debian kernel: [85204.136265]  [] ? schedule+0x2f/0x70 Jan
25 09:37:52 debian kernel: [85204.136268]  [] ?
schedule_preempt_disabled+0xa/0x10
Jan 25 09:37:52 debian kernel: [85204.136271]  [] ?
__mutex_lock_slowpath+0xb4/0x120
Jan 25 09:37:52 debian kernel: [85204.136274]  [] ? mutex_lock+0x1b/0x30
Jan 25 09:37:52 debian kernel: [85204.136280]  [] ?
xenbus_dev_request_and_reply+0x21/0x90
Jan 25 09:37:52 debian kernel: [85204.136284]  [] ?
xenbus_file_write+0x292/0x520
Jan 25 09:37:52 debian kernel: [85204.136289]  [] ?
__raw_callee_save___pv_queued_spin_unlock+0x11/0x20
Jan 25 09:37:52 debian kernel: [85204.136293]  [] ? vfs_write+0xa1/0x190
Jan 25 09:37:52 debian kernel: [85204.136296]  [] ? SyS_write+0x52/0xc0
Jan 25 09:37:52 debian kernel: [85204.136300]  [] ?
system_call_fast_compare_end+0xc/0x67

After this XL stack is unuseable until next reboot.
All DomU guests continue to run fine.

I have a cron task making "xentop -b -i 1" every 5 min.
Stopping this remove above Call Trace messages, but XL still unuseable
until reboot.

Brgds
Torben Schou Jensen

Bug#812336: [s390x] udeb: include modules to mount ISOs (loop device)

[Hendrik Brueckner]

Hi,

On Sat, Jan 23, 2016 at 10:01:44PM +0100, Philipp Kern wrote:
> On Fri, Jan 22, 2016 at 02:52:09PM +0100, Hendrik Brueckner wrote:
> > for mounting ISO images within the Debian Installer, the loop and ISO file
> > system module udebs are missing and should be included. I will attach a
> > patch to resolve this issue.
> > 
> > These module udebs are required by the the iso-scan/load-iso debian 
> > installer
> > packages.
> 
> that sounds good to me. For context: This makes sense now that KVM is
> supported on s390x and you can attach CD drives to a VM.

Correct.

Another use case is a particular type of installation: Put an ISO image on a
DASD or SCSI disk in future.  In the installer, set the DASD/SCSI disk online
and then use the iso-scan/load-iso modules to mount and search for the ISO
image to proceed installation.  That way, an external network connection might
not be required.

Thanks and kind regards,
  Hendrik

Bug#812540: Add ARCH_HISI for Lemaker HiKey support

[Ian Campbell]

On Sun, 2016-01-24 at 21:21 +0100, Kilian Krause wrote:
> Package: linux
> Version: 4.3.3-7
> Severity: wishlist
> Tags: d-i
> 
> Dear kernel maintainers,
> 
> while trying to get a d-i booted on a Lemaker HiKey, tbm pointed out
> that ARCH_HISI is not (yet) activated on linux.
> 
> Please enable it so we can add HiKey support to Debian.

I suppose it will need more than just ARCH_HISI. Are you able to identify
the full set of options (e.g. drivers and such) which are needed to make
useful Lemaker support? If so I'd appreciate it (if not I can probably try
and dig those out myself, but it might take me a while to around to it).

Lemaker HiKey is the 96boards thing, right? Good to finally see that
hitting upstream, was it properly supported in 4.3.x or should this change
be made in experimental (currently 4.4.x)?

Thanks,
Ian.

Bug#811250: marked as done (other: CPU FAN)

[Debian Bug Tracking System]

Your message dated Mon, 25 Jan 2016 10:37:57 +
with message-id <20160125103757.ga28...@chase.mapreri.org>
and subject line Re: Bug#811250: other: CPU FAN
has caused the Debian Bug report #811250,
regarding other: CPU FAN
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
811250: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811250
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: other
Severity: normal

Dear Maintainer,


   * What led up to the situation?
I installed Debian Jessie on my Dell E6410, everything seem to work 
fine, except a CPU fan spinning at the maximum speed at all times. 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I searched on-line and in forums, seeing that other people who are 
using Dell E6410 with Debian Jessie have a same loud and fast spinning CPU fan. 
No solution was advised by anyone so far. 

   * What was the outcome of this action?
None, the CPU Fan just continue spinning at the maximum speed and its just very 
distracting. When laptop running off the battery, it seems to drain a battery 
much faster comparing to Ubuntu 14.04 LTS

   * What outcome did you expect instead?
I am hopping for some one in Dev team to look in to this issue and maybe write 
out a guide for the Dell E6410 users specifically, or to check if this is 
global issue for a laptop users. 


-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Sun, Jan 24, 2016 at 09:44:44PM -0800, DM wrote:
> Hello Mr. Rizzolo, I have to apologize, this was absolutely a user error on
> my part.

don't worry, happens.

> The CPU fan was actually working as expected... the noise came from the HDD
> (the HDD with a spindle) and NOT the CPU.
> 
> I'm sorry for taking your time. This ticket/report is not valid and the OS
> performs as expected.
> 
> There is problems with Gnome3 itself... all design (the UI controls/window
> borders just huge and there is no simple way to scale it back) but the OS
> itself works perfectly fine.
> 
> Please close this ticket. I do apologize once again.

OK, closing.

> 
> Thank you.
> 
> DM
> 
> On Sun, Jan 17, 2016 at 3:27 AM, Mattia Rizzolo  wrote:
> 
> > control: reassign src:linux
> >
> > On Sun, Jan 17, 2016 at 12:52:55AM -0800, Damien wrote:
> > > Package: other
> >
> > Package:other is not a thing... your email reached 3 people top, who
> > read undelivearable bug emails.
> >
> > >* What led up to the situation?
> > >   I installed Debian Jessie on my Dell E6410, everything seem to
> > work fine, except a CPU fan spinning at the maximum speed at all times.
> > >
> > >* What exactly did you do (or not do) that was effective (or
> > >  ineffective)?
> > >   I searched on-line and in forums, seeing that other people who are
> > using Dell E6410 with Debian Jessie have a same loud and fast spinning CPU
> > fan.
> > > No solution was advised by anyone so far.
> > >
> > >* What was the outcome of this action?
> > > None, the CPU Fan just continue spinning at the maximum speed and its
> > just very distracting. When laptop running off the battery, it seems to
> > drain a battery much faster comparing to Ubuntu 14.04 LTS
> > >
> > >* What outcome did you expect instead?
> > > I am hopping for some one in Dev team to look in to this issue and maybe
> > write out a guide for the Dell E6410 users specifically, or to check if
> > this is global issue for a laptop users.
> >
> > Let's see what the linux maintainers say.
> >
> > --
> > regards,
> > Mattia Rizzolo
> >
> > GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> > more about me:  http://mapreri.org  : :'  :
> > Launchpad user: https://launchpad.net/~mapreri  `. `'`
> > Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
> >

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc

Re: Xen XL blocked on linux-image-4.3.0.1-amd64 4.3.3-5

[Ian Campbell]

On Mon, 2016-01-25 at 10:53 +0100, Torben Schou Jensen wrote:
> Something with Xen is unstable since upgrade to kernel 4.3.0.1.

This is fixed in 4.3.3-7 I believe as bug #810472.

Ian.

Processed: tagging 812540

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 812540 + moreinfo
Bug #812540 [linux] Add ARCH_HISI for Lemaker HiKey support
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
812540: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812540
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems