Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann

[The Wanderer]

On 2018-02-26 at 14:55, Ben Hutchings wrote:

> On Mon, 2018-02-26 at 12:07 -0500, The Wanderer wrote:

>> If the automatic DKMS rebuild is expected to be able to produce
>> modules which can work with the running kernel, then clearly the
>> current behavior is buggy in some way, and should be addressed.
> 
> I don't think that's a reasonable expectation.  But I think DKMS
> should not automatically rebuild when installing a version of
> linux-headers- ABINAME that is newer than the currently *installed*
> version of linux- image-ABINAME.

It's possible that it actually doesn't. I believe the rebuild that
triggered the problem, for me, was triggered not by an upgrade of
linux-headers-ABINAME but by an upgrade of virtualbox-dkms; the
linux-headers-* package was upgraded much earlier, I believe on January
21st. (And IIRC the matching linux-image-* package was upgraded at the
same time.)

Off the top of my head, I don't see any potential way for DKMS to know
whether it's being asked to build against the sources of the running
kernel, vs. simply the sources of the currently installed kernel - and
I'm fairly sure that making the correct decision about whether or not to
rebuild when upgrading non-kernel packages would require knowing that.

>> On the other hand, if rebuilding the modules is expected to result
>> in modules which will not load against the running kernel,
>> shouldn't the DKMS machinery detect this condition and refrain from
>> automatically removing the existing (working) modules, at least
>> without an override request of some sort? Or at bare minimum, warn
>> that proceeding with the upgrade will result in functionality loss
>> until a reboot can be carried out?
> 
> If by "removing" you mean unloading a module from the kernel, I
> agree that it should not do this.

The idea of not unloading the module at upgrade time had in fact not
occurred to me. It's an interesting one, and if viable would seem to
offer a way out of the problem, but I'm not sure how viable it would be
in practice.

The upgrade process appears to consist basically of an uninstall
followed by an install. As such, all three of those scenarios would need
to be considered.


As far as I can tell without deeper investigation than I'm currently set
up for, what DKMS currently does at upgrade is to delete the old
modules, build the new ones, unload the old ones, and then load the new
ones. (I'm basing this on the output messages during the upgrade; I've
dug for the place where the underlying commands get run and the messages
get generated, but I haven't found anything I'm confident is the right
place.)

If there's a way to load the new module without unloading the other
first - if, e.g., the kernel will detect the collision and automatically
unload the old one after validating the new - it should be possible to
have DKMS do that, and skip the unload entirely. However, I don't
remember seeing any indication that such a way exists.

If there's a way to detect whether the newly-built modules will be
compatible with the currently-running kernel before trying to load them,
it might be possible to have DKMS skip the unload and subsequent load if
the latter would fail. Again, however, I don't know of any such way.

If neither of those things is possible, then the choices would seem to
be to either never unload (meaning that the old module would remain in
use until sysadmin intervention), or always unload (basically the
current situation).


What DKMS currently does at uninstall time I don't know. Clearly,
however, it would need to unload the module, as otherwise the uninstall
could not be considered complete. However, it's not clear to me that
there's any way for it to be able to tell a "permanent uninstall"
removal from an "upgrade" removal.


At install time, plainly DKMS needs to load the just-built module, but
again it's not clear to me that there's any way for it to tell a "clean
install" build from an "upgrade" build.


(That said, I've also seen my entire system hardlock when upgrading
VirtualBox packages while a VirtualBox VM was running, and it seems very
plausible that the lockup was because a module which was in use by
VirtualBox got automatically unloaded by DKMS. If it's possible to
design so as to avoid that automatic unload, without unacceptable
tradeoffs, that would make managing my upgrades easier.)

> If you mean replacing the module on disk, I disagree; it should
> build modules for the installed kernel version.

Certainly it should, and if there's no way to do that without removing
the existing modules from the disk, then that's what it should do -
possibly with a warning message or even an "are you sure?" prompt, but
still.

I had thought that the DKMS upgrade-time messages about "module was
ACTIVE" and "module version" and "original module" carried the
implication that it was possible to have DKMS managing multiple versions
of a given module for a given kernel at once, but digging deeper seems
to indicate that this 

Bug#890099: Th symlink seems to be invisible to all services

[Giuseppe Bilotta]

With some further testing, it would seem that the issue of not being
able to find/access anything under that path with the intermediate
symlink affects all services,not just nfs. I'm seeing it with
git-daemon-run (which runs via runit), as well as with apache (the
gitweb site is unable to follow those symlinks). I'm completely
stymied at what the cause might be. Is systemd somehow passing a
different view of mounted filesystems to its children?

-- 
Giuseppe "Oblomov" Bilotta

Processed: reassign 891522 to src:linux, found 891522 in linux/4.14.17-1

[Debian Bug Tracking System]

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

> reassign 891522 src:linux 4.14.17-1
Bug #891522 [linux-image-4.14.0-3-amd64] linux-image-4.14.0-3-amd64 - (BUG: 
unable to handle kernel NULL pointer  dereference at 0258)
Bug reassigned from package 'linux-image-4.14.0-3-amd64' to 'src:linux'.
No longer marked as found in versions linux/4.14.17-1.
Ignoring request to alter fixed versions of bug #891522 to the same values 
previously set
Bug #891522 [src:linux] linux-image-4.14.0-3-amd64 - (BUG: unable to handle 
kernel NULL pointer  dereference at 0258)
Marked as found in versions linux/4.14.17-1.
> found 891522 linux/4.14.17-1
Bug #891522 [src:linux] linux-image-4.14.0-3-amd64 - (BUG: unable to handle 
kernel NULL pointer  dereference at 0258)
Ignoring request to alter found versions of bug #891522 to the same values 
previously set
> thanks
Stopping processing here.

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

Processed: reassign 891565 to src:linux, found 891565 in linux/4.15.4-1

[Debian Bug Tracking System]

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

> reassign 891565 src:linux 4.15.4-1
Bug #891565 [linux-image-4.15.0-1-amd64] kernel upgrade related to causing link 
failure at eth0 and wlp2s0
Bug reassigned from package 'linux-image-4.15.0-1-amd64' to 'src:linux'.
No longer marked as found in versions linux/4.15.4-1.
Ignoring request to alter fixed versions of bug #891565 to the same values 
previously set
Bug #891565 [src:linux] kernel upgrade related to causing link failure at eth0 
and wlp2s0
Marked as found in versions linux/4.15.4-1.
> found 891565 linux/4.15.4-1
Bug #891565 [src:linux] kernel upgrade related to causing link failure at eth0 
and wlp2s0
Ignoring request to alter found versions of bug #891565 to the same values 
previously set
> thanks
Stopping processing here.

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

Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann

[Ben Hutchings]

On Mon, 2018-02-26 at 12:07 -0500, The Wanderer wrote:
[...]
> I am still running kernel version 4.14.13-1, although the installed
> version of linux-{image,headers}-4.14.0-3-amd64 is 4.14.17-1; I have not
> rebooted since upgrading the kernel package, and IMO it should not be
> expected that upgrading the kernel will be followed swiftly by a reboot.

In the same way that extensions to a library ABI do not require a new
soname, extensions to the kernel module ABI do not require a change to
its ABI name.  Newly built modules, including in-tree modules, may
depend on those extensions.  Therefore you should not expect to be able
to load new kernel modules between upgrading the kernel and rebooting.

> To the best of my recollection, I have never previously seen it be
> necessary to reboot in order to avoid loss of functionality from a DKMS
> rebuild subsequent to a kernel upgrade.

I think you've just been lucky.

> If the automatic DKMS rebuild is expected to be able to produce modules
> which can work with the running kernel, then clearly the current
> behavior is buggy in some way, and should be addressed.

I don't think that's a reasonable expectation.  But I think DKMS should
not automatically rebuild when installing a version of linux-headers-
ABINAME that is newer than the currently *installed* version of linux-
image-ABINAME.

> On the other hand, if rebuilding the modules is expected to result in
> modules which will not load against the running kernel, shouldn't the
> DKMS machinery detect this condition and refrain from automatically
> removing the existing (working) modules, at least without an override
> request of some sort? Or at bare minimum, warn that proceeding with the
> upgrade will result in functionality loss until a reboot can be carried
> out?

If by "removing" you mean unloading a module from the kernel, I agree
that it should not do this.

If you mean replacing the module on disk, I disagree; it should build
modules for the installed kernel version.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Bug#891565: kernel upgrade related to causing link failure at eth0 and wlp2s0

[Jeffrin Thalakkottoor]

Package: linux-image-4.15.0-1-amd64
Version: 4.15.4-1

i am unable to connect to network because of link problem for
my wired and wireless connection related.
Things work fine with linux-image-4.9.0-4-amd64  package
i use  libc6:amd64  2.26-6  amd64   GNU C Library: Shared libraries
i useuster/sid
a portion of dmesg output is show below. typical full dmesg output is
attached


[  500.056159] [ cut here ]
[  500.056162] rtl8723be: error H2C cmd because of Fw download fail!!!
[  500.056198] WARNING: CPU: 0 PID: 22 at
/build/linux-PFKtCE/linux-4.15.4/drivers/net/wireless/realtek/rtlwifi/rtl8723be/fw.c:227
rtl8723be_fill_h2c_cmd+0x103/0x440 [rtl8723be]
$

--
software engineer
rajagiri school of engineering and technology
[0.00] Linux version 4.15.0-1-amd64 (debian-kernel@lists.debian.org) 
(gcc version 7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.15.4-1 (2018-02-18)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1-amd64 
root=UUID=a054425d-89dc-4d7a-a928-e5a87f57dc8d ro quiet
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x75a76fff] usable
[0.00] BIOS-e820: [mem 0x75a77000-0x75e76fff] reserved
[0.00] BIOS-e820: [mem 0x75e77000-0x76f76fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x76f77000-0x76fb6fff] ACPI data
[0.00] BIOS-e820: [mem 0x76fb7000-0x77ff] usable
[0.00] BIOS-e820: [mem 0x7bc0-0x7fff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xe3ff] reserved
[0.00] BIOS-e820: [mem 0xfea0-0xfeaf] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved
[0.00] BIOS-e820: [mem 0xfed03000-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed08000-0xfed09fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1cfff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfedb] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffa0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00017fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.8 present.
[0.00] DMI: HP HP Notebook/80C5, BIOS F.1E 12/25/2015
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x18 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFC0 mask FFFC0 write-protect
[0.00]   1 base 0FFA0 mask FFFE0 write-protect
[0.00]   2 base 0 mask F8000 write-back
[0.00]   3 base 07C00 mask FFC00 uncachable
[0.00]   4 base 07BC0 mask FFFC0 uncachable
[0.00]   5 base 1 mask F8000 write-back
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: last_pfn = 0x78000 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [(ptrval)] 98000 size 24576
[0.00] BRK [0x14e01d000, 0x14e01dfff] PGTABLE
[0.00] BRK [0x14e01e000, 0x14e01efff] PGTABLE
[0.00] BRK [0x14e01f000, 0x14e01] PGTABLE
[0.00] BRK [0x14e02, 0x14e020fff] PGTABLE
[0.00] BRK [0x14e021000, 0x14e021fff] PGTABLE
[0.00] BRK [0x14e022000, 0x14e022fff] PGTABLE
[0.00] BRK [0x14e023000, 0x14e023fff] PGTABLE
[0.00] BRK [0x14e024000, 0x14e024fff] PGTABLE
[0.00] RAMDISK: [mem 0x3537b000-0x369b4fff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000FE020 24 (v02 HPQOEM)
[0.00] ACPI: XSDT 0x76FB6120 A4 (v01 HPQOEM SLIC-MPC 
0003 HP   0113)
[0.00] ACPI: FACP 0x76FAA000 00010C (v05 HPQOEM SLIC-MPC 
0003 HP   0004)
[0.00] ACPI: DSDT 

Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann

[The Wanderer]

Or in other words: the unexpected behavior here is on the part of DKMS,
in removing working modules when the ones which will be put in as their
replacements do not work, not on the part of the kernel headers (et
cetera) themselves.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#891560: initramfs-tools-core: mkinitramfs ignores compressed module files

[Noah Massey]

Package: initramfs-tools-core
Version: 0.130
Severity: normal
Tags: patch

Dear Maintainer,

Linux 3.18.0 comes with native support for xz compressed modules.
kmod/25-1 adds support for xz compressed modules. Compression allows me
to build custom kernels with much smaller FS impact, so I've been trying
it out.

I built and installed kernel from source (4.14.21, 4.15.5) with XZ
module compression.

$ make menuconfig
 # Enable CONFIG_MODULE_COMPRESS
 # Enable CONFIG_MODULE_COMPRESS_XZ
$ make
$ make modules_install
$ make install

However, after rebooting throug grub the kernel loads the initramfs, but
initramfs fails to find the root filesystem. Examining contents of
the generated /boot/initrd.img*, compared to an uncompressed build, many
modules and /lib/firmware/* are absent.

I was able to generate working initrd.img* files with the following
patch:

==>8==
--- /usr/share/initramfs-tools/hook-functions~  2018-02-23 10:57:27.622691989 
-0500
+++ /usr/share/initramfs-tools/hook-functions   2018-02-23 11:57:55.792649031 
-0500
@@ -212,12 +212,15 @@
fi
fi
while [ $# -ge 1 ]; do
-   exclude="${exclude:-} -name $1 -prune -o "
+   exclude="${exclude:-} -name $1 -prune -o -name $1.xz -prune -o "
shift
done
for kmod in $(find "${MODULESDIR}/${dir}" ${exclude:-} -name '*.ko' 
-printf '%f\n'); do
modules="$modules ${kmod%.ko}"
done
+   for kmod in $(find "${MODULESDIR}/${dir}" ${exclude:-} -name '*.ko.xz' 
-printf '%f\n'); do
+   modules="$modules ${kmod%.ko.xz}"
+   done
manual_add_modules $modules
 }

@@ -313,6 +316,9 @@
*/$pattern.ko)
manual_add_modules $(basename $module .ko)
;;
+   */$pattern.ko.xz)
+   manual_add_modules $(basename $module .ko.xz)
+   ;;
esac
done < $builtin
fi

==>8==
There may be more elegant solutions.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages initramfs-tools-core depends on:
ii  cpio 2.12+dfsg-6
ii  klibc-utils  2.0.4-11
ii  kmod 25-1
ii  udev 237-3

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.27.2-2

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.1-4.3

-- Configuration Files:
/etc/initramfs-tools/initramfs.conf unchanged [not included]
(BUSYBOX=y)

-- no debconf information

Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann

[The Wanderer]

I encountered this error today on upgrade of virtualbox-dkms, I think
from version 5.2.6-dfsg-2 to 5.2.6-dfsg-5. To the best of my knowledge,
I have not carried out any downgrade, either of the kernel or of the
DKMS package.

In my experience, upgrading a DKMS package triggers an automatic rebuild
of the relevant module(s) against installed headers; more specifically,
on removal of the pre-upgrade version the old modules are removed, and
on install of the post-upgrade version the new modules are automatically
built. (The messages printed during this process seem to imply that the
DKMS machinery has the ability to have multiple installed module
versions per kernel, and simply set one or another as active, but I have
never seen this functionality be used.)

I am still running kernel version 4.14.13-1, although the installed
version of linux-{image,headers}-4.14.0-3-amd64 is 4.14.17-1; I have not
rebooted since upgrading the kernel package, and IMO it should not be
expected that upgrading the kernel will be followed swiftly by a reboot.
To the best of my recollection, I have never previously seen it be
necessary to reboot in order to avoid loss of functionality from a DKMS
rebuild subsequent to a kernel upgrade.

If the automatic DKMS rebuild is expected to be able to produce modules
which can work with the running kernel, then clearly the current
behavior is buggy in some way, and should be addressed.

On the other hand, if rebuilding the modules is expected to result in
modules which will not load against the running kernel, shouldn't the
DKMS machinery detect this condition and refrain from automatically
removing the existing (working) modules, at least without an override
request of some sort? Or at bare minimum, warn that proceeding with the
upgrade will result in functionality loss until a reboot can be carried
out?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#891249: linux: unstable kernel/data corruption on ppc64el

[Frédéric Bonnard]

Hi again,
it looks that there was missing bit in some earlier patch included in 4.9
stable kernel : 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.9.y=3146a32b39cd78722869bca6e839b3c59155e012

I tested with this single patch on top of 4.9.82-1+deb9u2 and I could do
some heavy linux compilation without issue.

The latest upstream 4.9.84 has that fix. 

F.

On Mon, 26 Feb 2018 12:33:56 +0100, Frédéric Bonnard  wrote:
> Hi,
> I got this as well, not immediatly though but adding some
> parallelization to the build helped. I'll look into this as well.
> 
> F.
> 
> On Fri, 23 Feb 2018 19:52:35 +0100, Aurelien Jarno  wrote:
> > Source: linux
> > Version: 4.9.82-1+deb9u2
> > Severity: critical
> > Justification: causes serious data corruption
> > 
> > DSA has installed the latest security kernel (4.9.82-1+deb9u2) on the
> > Debian POWER8 machines running ppc64el. While they boot correctly, then
> > programs segfault randomly (apt, sbuild, systemd, etc...). Passing
> > no_rfi_flush to the command line does not change anything. Looking more
> > in details, things looks scarying as some code actually get wrongly
> > executed. Here are some build logs examples:
> > - 
> > https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519399908=0
> > - 
> > https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519396907=0
> > - 
> > https://buildd.debian.org/status/fetch.php?pkg=tk8.5=ppc64el=8.5.19-3=1519362938=0
> > 
> > While in the above case the packages fail to build from source, I guess
> > there are also some cases of undetected corruptions.
> > 
> > I'll try to run the 4.9.80-2 kernel at some point to narrow down the
> > issue.
> > 
> > 


pgplpW7_L8Hs1.pgp
Description: PGP signature

Processed: Re: Bug#891249: linux: unstable kernel/data corruption on ppc64el

[Debian Bug Tracking System]

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

> tag 891249 + fixed-upstream
Bug #891249 [src:linux] linux: unstable kernel/data corruption on ppc64el
Added tag(s) fixed-upstream.
> thanks
Stopping processing here.

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

Bug#891249: linux: unstable kernel/data corruption on ppc64el

[Aurelien Jarno]

tag 891249 + fixed-upstream
thanks

On 2018-02-26 11:01, Breno Leitao wrote:
> Hi,
> 
> On 02/23/2018 03:52 PM, Aurelien Jarno wrote:
> 
> > DSA has installed the latest security kernel (4.9.82-1+deb9u2) on the
> > Debian POWER8 machines running ppc64el. While they boot correctly, then
> > programs segfault randomly (apt, sbuild, systemd, etc...). Passing
> > no_rfi_flush to the command line does not change anything. Looking more
> > in details, things looks scarying as some code actually get wrongly
> > executed. Here are some build logs examples:
> > - 
> > https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519399908=0
> > - 
> > https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519396907=0
> > - 
> > https://buildd.debian.org/status/fetch.php?pkg=tk8.5=ppc64el=8.5.19-3=1519362938=0
> > 
> > While in the above case the packages fail to build from source, I guess
> > there are also some cases of undetected corruptions.
> > 
> > I'll try to run the 4.9.80-2 kernel at some point to narrow down the
> > issue.
> 
> I talked to the powerpc maintainer about this problem, and in fact this is a 
> knew
> problem, since the 4.4 patches were 'backported' to 4.9 without success.
> 
> This is already fixed and in the stable tree already:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/arch/powerpc?h=linux-4.9.y
> 
> I understand that the commit ids are:
>  * 3146a32b39cd78722869bca6e839b3c59155e012
>  * efe8bc07c47fff196bbc0822e249a27ae0574d24
>  * ec0084d082137b73460303b39f4089970a213ad7
> 
> But I suppose that Debian will do a full merge with the stable tree, then, I 
> expect
> that the next release will just work.

Thanks for the quick answer. I confirm that these commit are indeed in
the 4.9.84 stable release, which has been released yesterday. I guess
3146a32b39cd78722869bca6e839b3c59155e012 is the one which fixes the data
corruption.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#891249: linux: unstable kernel/data corruption on ppc64el

[Breno Leitao]

Hi,

On 02/23/2018 03:52 PM, Aurelien Jarno wrote:

> DSA has installed the latest security kernel (4.9.82-1+deb9u2) on the
> Debian POWER8 machines running ppc64el. While they boot correctly, then
> programs segfault randomly (apt, sbuild, systemd, etc...). Passing
> no_rfi_flush to the command line does not change anything. Looking more
> in details, things looks scarying as some code actually get wrongly
> executed. Here are some build logs examples:
> - 
> https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519399908=0
> - 
> https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519396907=0
> - 
> https://buildd.debian.org/status/fetch.php?pkg=tk8.5=ppc64el=8.5.19-3=1519362938=0
> 
> While in the above case the packages fail to build from source, I guess
> there are also some cases of undetected corruptions.
> 
> I'll try to run the 4.9.80-2 kernel at some point to narrow down the
> issue.

I talked to the powerpc maintainer about this problem, and in fact this is a 
knew
problem, since the 4.4 patches were 'backported' to 4.9 without success.

This is already fixed and in the stable tree already:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/arch/powerpc?h=linux-4.9.y

I understand that the commit ids are:
 * 3146a32b39cd78722869bca6e839b3c59155e012
 * efe8bc07c47fff196bbc0822e249a27ae0574d24
 * ec0084d082137b73460303b39f4089970a213ad7

But I suppose that Debian will do a full merge with the stable tree, then, I 
expect
that the next release will just work.

Bug#891249: linux: unstable kernel/data corruption on ppc64el

[Frédéric Bonnard]

Hi,
I got this as well, not immediatly though but adding some
parallelization to the build helped. I'll look into this as well.

F.

On Fri, 23 Feb 2018 19:52:35 +0100, Aurelien Jarno  wrote:
> Source: linux
> Version: 4.9.82-1+deb9u2
> Severity: critical
> Justification: causes serious data corruption
> 
> DSA has installed the latest security kernel (4.9.82-1+deb9u2) on the
> Debian POWER8 machines running ppc64el. While they boot correctly, then
> programs segfault randomly (apt, sbuild, systemd, etc...). Passing
> no_rfi_flush to the command line does not change anything. Looking more
> in details, things looks scarying as some code actually get wrongly
> executed. Here are some build logs examples:
> - 
> https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519399908=0
> - 
> https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519396907=0
> - 
> https://buildd.debian.org/status/fetch.php?pkg=tk8.5=ppc64el=8.5.19-3=1519362938=0
> 
> While in the above case the packages fail to build from source, I guess
> there are also some cases of undetected corruptions.
> 
> I'll try to run the 4.9.80-2 kernel at some point to narrow down the
> issue.
> 
> 


pgpuzLDg7lWW2.pgp
Description: PGP signature

Processed: tagging 891467

[Debian Bug Tracking System]

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

> tags 891467 + confirmed
Bug #891467 [src:linux] linux-image-4.15.4-1-amd64: Hung kernel task after 
rcu_process_callbacks on boot
Added tag(s) confirmed.
> thanks
Stopping processing here.

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

Bug#891522: linux-image-4.14.0-3-amd64 - (BUG: unable to handle kernel NULL pointer dereference at 0000000000000258)

[klak]

Package:linux-image-4.14.0-3-amd64 
Version:4.14.17-1

Dear Maintainer,

after shutdown of all my VMs for backup, the (re)start of the second VM
hangs. Reboot hangs too and only a hard reset helps. Please see the
attached file.

Greets klak



bug_libvirt.txt.gz
Description: application/gzip

Processed: linux-libc-dev: headers from 4.15 cause "redefinition of 'struct in6_addr'" in libreswan

[Debian Bug Tracking System]

Processing control commands:

> affects -1 src:libreswan
Bug #891520 [linux-libc-dev] linux-libc-dev: headers from 4.15 cause 
"redefinition of 'struct in6_addr'" in libreswan
Added indication that 891520 affects src:libreswan

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

Bug#891520: linux-libc-dev: headers from 4.15 cause "redefinition of 'struct in6_addr'" in libreswan

[James Cowgill]

Package: linux-libc-dev
Version: 4.15.4-1
Severity: important
Tags: fixed-upstream
Control: affects -1 src:libreswan
X-Debbugs-CC: libres...@packages.debian.org

Hi,

I noticed libreswan FTBFS in unstable with this error:
> In file included from 
> /<>/programs/pluto/linux-copy/linux/xfrm.h:4:0,
>  from /<>/programs/pluto/kernel_netlink.c:55:
> /usr/include/linux/in6.h:33:8: error: redefinition of 'struct in6_addr'
>  struct in6_addr {
> ^~~~
> In file included from /<>/linux/include/libreswan.h:76:0,
>  from /<>/programs/pluto/kernel_netlink.c:54:
> /usr/include/netinet/in.h:211:8: note: originally defined here
>  struct in6_addr
> ^~~~
> In file included from 
> /<>/programs/pluto/linux-copy/linux/xfrm.h:4:0,
>  from /<>/programs/pluto/kernel_netlink.c:55:
> /usr/include/linux/in6.h:50:8: error: redefinition of 'struct sockaddr_in6'
>  struct sockaddr_in6 {
> ^~~~
> In file included from /<>/linux/include/libreswan.h:76:0,
>  from /<>/programs/pluto/kernel_netlink.c:54:
> /usr/include/netinet/in.h:252:8: note: originally defined here
>  struct sockaddr_in6
> ^~~~
> In file included from 
> /<>/programs/pluto/linux-copy/linux/xfrm.h:4:0,
>  from /<>/programs/pluto/kernel_netlink.c:55:
> /usr/include/linux/in6.h:60:8: error: redefinition of 'struct ipv6_mreq'
>  struct ipv6_mreq {
> ^
> In file included from /<>/linux/include/libreswan.h:76:0,
>  from /<>/programs/pluto/kernel_netlink.c:54:
> /usr/include/netinet/in.h:288:8: note: originally defined here
>  struct ipv6_mreq
> ^
> make[5]: *** [../../mk/depend.mk:34: kernel_netlink.o] Error 1
> make[4]: *** [../../mk/targets.mk:90: all] Error 2
> make[4]: Leaving directory '/<>/programs/pluto'
> make[3]: *** [../mk/targets.mk:90: recursive-all] Error 2
> make[3]: Leaving directory '/<>/programs'
> make[2]: *** [mk/targets.mk:90: recursive-all] Error 2
> make[2]: Leaving directory '/<>'
> make[1]: *** [debian/rules:23: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:6: binary-arch] Error 2
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2

See also this reproducible builds log:
> https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libreswan_3.23-4.rbuild.log

This only happens when using linux headers from 4.15.

I think the cause of this was a change in 4.15 in the if_ether.h header.
It should be fixed by this upstream patch (applied in linus's tree but
not yet in stable):
https://www.spinics.net/lists/stable/msg215023.html

da360299b6734135a5f66d7db458dcc7801c826a
"uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define"

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#891502: ITP: irda-dkms -- IrDA subsystem and device drivers

[Christopher Schramm]

Package: wnpp
Severity: wishlist
Owner: Christopher Schramm 

* Package name: irda-dkms
  Version : 0.1
* URL : https://github.com/cschramm/irda
* License : GPL
  Programming Lang: C
  Description : IrDA subsystem and device drivers

The IrDA subsystem and device drivers got moved to staging and scheduled for
removal upstream in Linux 4.14 [1] and consequently disabled in the Debian
builds [2].

[1] https://lkml.org/lkml/2017/8/27/126
[2] 
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=d12b3a11b2800489cde0be2d74872af04b5b8f36

As I personally do have a use case for IrDA and am sure that I am not the only
one, I moved the code (from 4.15; not compatible to 4.14!) into a GitHub
repository [3], converted the build system to Kbuild files, and added a DKMS
configuration and a Travis CI configuration to check the build with current
kernel releases.

[3] https://github.com/cschramm/irda

I already prepared the packaging files. See [4] for copyright and license.

[4] https://github.com/cschramm/irda/blob/debian/debian/copyright