Re: Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts

[Ross Vandegrift]

On Mon, May 14, 2018 at 01:38:15PM +0100, Simon McVittie wrote:
> On Sat, 12 May 2018 at 18:26:11 -0700, Ross Vandegrift wrote:
> > It looks like the scope id was added in #644912.  This may be a kernel bug 
> > if
> > the scope id should be accepted.
> 
> I think this might be a bug in whatever user-space tool calls
> getaddrinfo() and passes its result to the kernel, which probably means
> mount.nfs? If the kernel doesn't want to see scope IDs in this context,
> then the user-space tool shouldn't provide them: returning scope IDs is
> part of the getaddrinfo() API.

I did some digging, here's what I found.

mount.nfs accepts scoped ipv6 addresses:
  $ sudo mount.nfs -vf '[fd7d:612b:f36c:0:4d15:7364:6589:dbef%2]:/' /mnt/tmp -o 
nfsvers=4.2
  mount.nfs: timeout set for Mon May 14 19:11:01 2018
  mount.nfs: trying text-based options 
'vers=4.2,addr=fd7d:612b:f36c:0:4d15:7364:6589:dbef%2,clientaddr=fd7d:612b:f36c::4c5'

But mount(2) fails:
  $ sudo mount.nfs -v '[fd7d:612b:f36c:0:4d15:7364:6589:dbef%2]:/' /mnt/tmp -o 
nfsvers=4.2
  mount.nfs: timeout set for Mon May 14 19:12:48 2018
  mount.nfs: trying text-based options 
'nfsvers=4.2,addr=fd7d:612b:f36c:0:4d15:7364:6589:dbef%2,clientaddr=fd7d:612b:f36c::4c5'
  mount.nfs: mount(2): Invalid argument
  mount.nfs: an incorrect mount option was specified

nfs(5) has the following to say about the source argument:
  The server's hostname can be an unqualified hostname, a fully qualified
  domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in square
  brackets.  Link-local and site-local IPv6 addresses must be accompanied by an
  interface identifier.  See ipv6(7) for details on specifying raw IPv6
  addresses.

And ipv6(7) has this to say about the scope id field:
  sin6_scope_id is an ID depending on the scope of the address.  It is new in
  Linux 2.4.  Linux supports it only for link-local addresses, in that case
  sin6_scope_id contains the interface index (see netdevice(7))


Best as I can figure there's three wishlist bugs here:

1. nss-mdns should not return scope id for global addresses
2. mount.nfs should strip scope id unless the address is link-local
3. the kernel should accept & ignore scope id on non-global addresses

Does this seems like a reasonable reading?

Ross

Updating x86 microcode in stable

[Ben Hutchings]

I notice that amd64-microcode and intel-microcode haven't been updated
in stable this year.  (Indeed, amd64-microcode hasn't been updated at
all this year, but I know AMD has issued an update!)

You have updated intel-microcode in backports suites instead.  What's
the reasoning behind this?  I would expect all microcode updates to
meet the criteria for a stable update (fixing instability or data loss
bugs) or security update.

As you probably know, updated microcode is needed to mitigate against
Spectre v2 when running code that has not been rebuilt with the
"retpoline" mitigation, such as when making BIOS/UEFI calls.  I think
it's also needed to support Spectre v2 mitigation in KVM guests running
Windows.

The Linux kernel in stretch has had support for the microcode-based
mitigation since version 4.9.82-1+deb9u1.  I'm currently working on
backporting these changes to jessie, so microcode updates would be
useful there too.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

linux-signed-amd64_1+4.17~rc3+1~exp1_source.changes ACCEPTED into experimental, experimental

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 30 Apr 2018 00:13:06 +0100
Source: linux-signed-amd64
Binary: kernel-image-4.17.0-rc3-amd64-di nic-modules-4.17.0-rc3-amd64-di 
nic-wireless-modules-4.17.0-rc3-amd64-di nic-shared-modules-4.17.0-rc3-amd64-di 
serial-modules-4.17.0-rc3-amd64-di usb-serial-modules-4.17.0-rc3-amd64-di 
ppp-modules-4.17.0-rc3-amd64-di pata-modules-4.17.0-rc3-amd64-di 
cdrom-core-modules-4.17.0-rc3-amd64-di 
firewire-core-modules-4.17.0-rc3-amd64-di scsi-core-modules-4.17.0-rc3-amd64-di 
scsi-modules-4.17.0-rc3-amd64-di loop-modules-4.17.0-rc3-amd64-di 
btrfs-modules-4.17.0-rc3-amd64-di ext4-modules-4.17.0-rc3-amd64-di 
isofs-modules-4.17.0-rc3-amd64-di jfs-modules-4.17.0-rc3-amd64-di 
ntfs-modules-4.17.0-rc3-amd64-di xfs-modules-4.17.0-rc3-amd64-di 
fat-modules-4.17.0-rc3-amd64-di md-modules-4.17.0-rc3-amd64-di 
multipath-modules-4.17.0-rc3-amd64-di usb-modules-4.17.0-rc3-amd64-di 
usb-storage-modules-4.17.0-rc3-amd64-di 
pcmcia-storage-modules-4.17.0-rc3-amd64-di fb-modules-4.17.0-rc3-amd64-di 
input-modules-4.17.0-rc3-amd64-di
 event-modules-4.17.0-rc3-amd64-di mouse-modules-4.17.0-rc3-amd64-di 
nic-pcmcia-modules-4.17.0-rc3-amd64-di pcmcia-modules-4.17.0-rc3-amd64-di 
nic-usb-modules-4.17.0-rc3-amd64-di sata-modules-4.17.0-rc3-amd64-di 
acpi-modules-4.17.0-rc3-amd64-di i2c-modules-4.17.0-rc3-amd64-di 
crc-modules-4.17.0-rc3-amd64-di crypto-modules-4.17.0-rc3-amd64-di 
crypto-dm-modules-4.17.0-rc3-amd64-di efi-modules-4.17.0-rc3-amd64-di 
ata-modules-4.17.0-rc3-amd64-di mmc-core-modules-4.17.0-rc3-amd64-di 
mmc-modules-4.17.0-rc3-amd64-di nbd-modules-4.17.0-rc3-amd64-di 
squashfs-modules-4.17.0-rc3-amd64-di speakup-modules-4.17.0-rc3-amd64-di 
virtio-modules-4.17.0-rc3-amd64-di uinput-modules-4.17.0-rc3-amd64-di 
sound-modules-4.17.0-rc3-amd64-di compress-modules-4.17.0-rc3-amd64-di 
hyperv-modules-4.17.0-rc3-amd64-di udf-modules-4.17.0-rc3-amd64-di 
fuse-modules-4.17.0-rc3-amd64-di linux-image-4.17.0-rc3-amd64
 linux-image-4.17.0-rc3-cloud-amd64
Architecture: source
Version: 1+4.17~rc3+1~exp1
Distribution:  experimental
Urgency: medium
Maintainer: Debian Kernel Team 
Changed-By: Ben Hutchings 
Description:
 acpi-modules-4.17.0-rc3-amd64-di - ACPI support modules (udeb)
 ata-modules-4.17.0-rc3-amd64-di - ATA disk modules (udeb)
 btrfs-modules-4.17.0-rc3-amd64-di - BTRFS filesystem support (udeb)
 cdrom-core-modules-4.17.0-rc3-amd64-di - CDROM support (udeb)
 compress-modules-4.17.0-rc3-amd64-di - lzo modules (udeb)
 crc-modules-4.17.0-rc3-amd64-di - CRC modules (udeb)
 crypto-dm-modules-4.17.0-rc3-amd64-di - devicemapper crypto module (udeb)
 crypto-modules-4.17.0-rc3-amd64-di - crypto modules (udeb)
 efi-modules-4.17.0-rc3-amd64-di - EFI modules (udeb)
 event-modules-4.17.0-rc3-amd64-di - Event support (udeb)
 ext4-modules-4.17.0-rc3-amd64-di - ext2/ext3/ext4 filesystem support (udeb)
 fat-modules-4.17.0-rc3-amd64-di - FAT filesystem support (udeb)
 fb-modules-4.17.0-rc3-amd64-di - Frame buffer support (udeb)
 firewire-core-modules-4.17.0-rc3-amd64-di - Core FireWire drivers (udeb)
 fuse-modules-4.17.0-rc3-amd64-di - FUSE modules (udeb)
 hyperv-modules-4.17.0-rc3-amd64-di - Hyper-V modules (udeb)
 i2c-modules-4.17.0-rc3-amd64-di - i2c support modules (udeb)
 input-modules-4.17.0-rc3-amd64-di - Input devices support (udeb)
 isofs-modules-4.17.0-rc3-amd64-di - ISOFS filesystem support (udeb)
 jfs-modules-4.17.0-rc3-amd64-di - JFS filesystem support (udeb)
 kernel-image-4.17.0-rc3-amd64-di - Linux kernel image and core modules for the 
Debian installer (udeb)
 linux-image-4.17.0-rc3-amd64 - ${unsigned:DescriptionShort} (signed)
 linux-image-4.17.0-rc3-cloud-amd64 - ${unsigned:DescriptionShort} (signed)
 loop-modules-4.17.0-rc3-amd64-di - Loopback filesystem support (udeb)
 md-modules-4.17.0-rc3-amd64-di - RAID and LVM support (udeb)
 mmc-core-modules-4.17.0-rc3-amd64-di - MMC/SD/SDIO core modules (udeb)
 mmc-modules-4.17.0-rc3-amd64-di - MMC/SD card modules (udeb)
 mouse-modules-4.17.0-rc3-amd64-di - Mouse support (udeb)
 multipath-modules-4.17.0-rc3-amd64-di - Multipath support (udeb)
 nbd-modules-4.17.0-rc3-amd64-di - Network Block Device modules (udeb)
 nic-modules-4.17.0-rc3-amd64-di - NIC drivers (udeb)
 nic-pcmcia-modules-4.17.0-rc3-amd64-di - Common PCMCIA NIC drivers (udeb)
 nic-shared-modules-4.17.0-rc3-amd64-di - Shared NIC drivers (udeb)
 nic-usb-modules-4.17.0-rc3-amd64-di - USB NIC drivers (udeb)
 nic-wireless-modules-4.17.0-rc3-amd64-di - Wireless NIC drivers (udeb)
 ntfs-modules-4.17.0-rc3-amd64-di - NTFS filesystem support (udeb)
 pata-modules-4.17.0-rc3-amd64-di - PATA drivers (udeb)
 pcmcia-modules-4.17.0-rc3-amd64-di - Common PCMCIA drivers (udeb)
 pcmcia-storage-modules-4.17.0-rc3-amd64-di - PCMCIA storage drivers (udeb)
 ppp-modules-4.17.0-rc3-amd64-di - PPP drivers (udeb)
 sata-modules-4.17.0-rc3-amd64-di - SATA drivers (udeb)
 scsi-core-modules-4.17.0-rc3-amd64-di - 

Re: Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts

[Ross Vandegrift]

On Mon, May 14, 2018 at 01:38:15PM +0100, Simon McVittie wrote:
> Not including the scope ID in the result of address resolution breaks IPv6
> link-local addressing (fe80:*), and link-local addressing and mDNS are both
> parts of the Zeroconf stack, so they (should) go well together.

Yep, this makes perfect sense - the scope id shouldn't go away entirely.

> Or possibly nss-mdns should be setting the scope ID to the interface
> index for link-local addresses, but not for other addresses? It isn't
> entirely clear to me what nss-mdns is meant to be doing here.

On one hand, rfc4007 11.1 says that the scope id should not be used for
global scope, loopback, and undefined addresses.  On the other, ping &
ssh both saw the scope id and handled it without complaint.


> Workarounds:
> 
> * don't use mDNS (.local names) to find NFS servers; or
> * configure mdns4[_minimal] instead of mdns[_minimal] so .local names
>   resolve to IPv4 addresses

Yea there are workarounds, but I think this use-case is a sensible one
that should be supported.

My home has provider-assigned addressing via DHCPv6 PD, so it isn't
static.  ipv6 wisdom might suggest ULA + DNS instead.  That requires
static addressing or dynamic DNS - both of which are overkill for home
users.  mDNSv6 has been providing a good solution to exactly this.

Ross

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Hi Pradeep,

thanks for your response.

On 14.05.2018 17:48, Pradeep wrote:
> The patch is for NFS client side bug where it was initializing the
> attributes to zero if NFS4ERR_MOVED is returned in LOOKUP; but referral
> was not followed later. This only happens with NFSv4 server and the
> specific error (NFS4ERR_MOVED). 
> 
> It is not related to nfs-ganesha - it can be reproduced with kernel NFS
> as well.
> 
> Are you seeing any regressions with the patch?

I would think so.
Since that patch arrived in Kernel 3.16, it would not even try to follow
the referral as it did before. When I just revert this specific patch
for the kernel, it works.

On the referrer server, we use nfs-ganesha 2.4.5-2 with Christoph's
patch for nfs referral
(https://sources.debian.org/src/nfs-ganesha/2.4.5-2%7Ebpo9+1/debian/patches/nfs-ganesha-nfsrefer.patch).
The actual NFS server is a NetApp cluster.

I'm not so sure right now if it is not maybe a bug in nfs-ganesha (that
maybe even got fixed in the meantime), so I thought, maybe you know.

Thanks,
Moritz



signature.asc
Description: OpenPGP digital signature

Bug#898662: linux-support-4.9.0-6: If I try an installation at debian streatch starting from the old old-stable (debian jessie 8) I have no problem with the network card in question. If instead I try

[root]

Package: linux-support-4.9.0-6
Version: 26
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Good evening everyone. I have the following problem: I have a mainboard asus 
h81m-c with a network card 3: 00.0 Ethernet controller: Realtek Semiconductor 
Co., Ltd. RTL8111 / 8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c).
If I try an installation at debian streatch starting from the old old-stable 
(debian jessie 8) I have no problem with the network card in question. If 
instead I try a clean installation using the firmware-9.4.0-amd64-netinst.iso 1 
time out of 40 times I can get the dynamic IP address from the router. All the 
other times I can not get anything and therefore unable to go on with the 
installation. Even using a static IP address of the same / 24 class I can not 
ping the router. I have this situation with testing too. With other 
distributions (ubuntu, centos, freeebsd, fedora) I have no problem whatsoever. 
I do not know how to move anymore. I ask for help. Even if I had to open a 
bug-reporting on which package should I show it? On the kernel, on the 
debian-installer?

Bug#898648: ProLiant DL380 Gen9 takes forever to reboot

[Ivan Sergio Borgonovo]

Package: linux-image-4.15.0-3-amd64
Version: 4.15.17-1

after running

reboot

machine start shutdown and hangs several minutes with this message on 
console


hpwdt: Unxpected close, not stopping watchdog!

Fans go to maximum speed and machine freeze for several minutes before 
rebooting.

Freezing time are not constant (from 5 extra minutes to over 10 minutes).

Same problem with
linux-image-4.16.0-1-amd64
4.16.5-1

I had to revert to
linux-image-4.14.0-3-amd64
4.14.17-1

thanks

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#898267: [firmware-misc-nonfree] Missing firmware i915/kbl_dmc_ver1_04.bin

[Alexander Kernozhitsky]

В письме от воскресенье, 13 мая 2018 г. 19:20:38 +03 Вы написали:
> Hello,
> 
> could you provide us the kernel logs ? By running dmesg
> or journalctl -b.
> 
> Thanks
> 
> On Wed, May 09, 2018 at 03:55:18PM +0300, Alexander Kernozhitsky wrote:
> > Package: firmware-misc-nonfree
> > Version: 20170823-1
> > Severity: minor
> > 
> > Linux kernel shows me the warning at boot time. It looks like "missing
> > firmware i915/kbl_dmc_ver1_04.bin", but the package contains i915/
> > kbl_dmc_ver1_01.bin. A newer kernel requires 1.04 version. Please update
> > the firmware.
> > 
> > --- System information. ---
> > Architecture:
> > Kernel:   Linux 4.16.0-1-amd64
> > 
> > Debian Release: buster/sid
> > 
> >   990 testing ftp.by.debian.org
> >   500 unstableftp.by.debian.org
> > 
> > --- Package information. ---
> > Package's Depends field is empty.
> > 
> > Package's Recommends field is empty.
> > 
> > Suggests (Version) | Installed
> > ==-+-===
> > initramfs-tools| 0.130

[3.847736] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io
+mem,decodes=io+mem:owns=io+mem
[3.849158] i915 :00:02.0: firmware: failed to load i915/
kbl_dmc_ver1_04.bin (-2)
[3.849163] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[3.849166] i915 :00:02.0: Direct firmware load for i915/
kbl_dmc_ver1_04.bin failed with error -2
[3.849169] i915 :00:02.0: Failed to load DMC firmware i915/
kbl_dmc_ver1_04.bin. Disabling runtime power management.
[3.849171] i915 :00:02.0: DMC firmware homepage: https://01.org/
linuxgraphics/downloads/firmware

This is the part where the error is shown. Or do you need more info from the 
kernel logs?

-
Alexander Kernozhitsky

Re: [linux-stable-3.16.y] tun: allow positive return values on dev_get_valid_name() call

[Ben Hutchings]

On Mon, 2018-05-14 at 15:47 +0200, Sedat Dilek wrote:
> Hi Ben,
> 
> some Debian/jessie systems were caught by the bug-report in [1].
> This issue was recently fixed in an updated Debian kernel for v3.16.y.
> 
> Will you include the patch "tun: allow positive return values on
> dev_get_valid_name() call" [2] in linux-stable-3.16.y upstream?

Yes, I will include all the same regression fixes in the next 3.16-
stable update.

Ben.

> This was a fix for  "tun: call dev_get_valid_name() before
> register_netdevice()" [3].
> Unfortunately, there is not a reference (usually "Fixes:" tag) for this in 
> [2].
> Not sure if this was documented in the meantime like [4] says.
> 
> Thanks in advance.
> 
> Regards,
> - Sedat -
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897427
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c25f65fd1e42685f7ccd80e0621829c105785d9
> [3] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ad646c81b2182f7fa67ec0c8c825e0ee165696d
> [4] https://www.spinics.net/lists/netdev/msg462705.html
-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison



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

[linux-stable-3.16.y] tun: allow positive return values on dev_get_valid_name() call

[Sedat Dilek]

Hi Ben,

some Debian/jessie systems were caught by the bug-report in [1].
This issue was recently fixed in an updated Debian kernel for v3.16.y.

Will you include the patch "tun: allow positive return values on
dev_get_valid_name() call" [2] in linux-stable-3.16.y upstream?
This was a fix for  "tun: call dev_get_valid_name() before
register_netdevice()" [3].
Unfortunately, there is not a reference (usually "Fixes:" tag) for this in [2].
Not sure if this was documented in the meantime like [4] says.

Thanks in advance.

Regards,
- Sedat -

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897427
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c25f65fd1e42685f7ccd80e0621829c105785d9
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ad646c81b2182f7fa67ec0c8c825e0ee165696d
[4] https://www.spinics.net/lists/netdev/msg462705.html

Re: Fixing Linux getrandom() in stable

[Sam Hartman]

> "Thorsten" == Thorsten Glaser  writes:

Thorsten> Adrian Bunk dixit:
>> As an example, what happens if I debootstrap and deploy the
>> resulting filesytem to a large number of identical embedded
>> systems without entropy sources?

Thorsten> Just get into a habit of not doing so, for example by
Thorsten> modifying the image during each writing process.

I'm sorry, but modifying the image before each write is simply not
realistic.

My company has found that it's easy to get suppliers to deploy a static
image to the storage of appliances we're constructing during the
manufacturing process.
They do not have tools for modifying the image.  We do detect first boot
and do things like change filesystem UUIDs.
Mixing in any entropy we can obtain during the first boot is relatively
easy.  However, very quickly, we're going to need to do things like
generate ssh keys for management and generate a few other public keys.

Similar situations show up in cloud environments.  There you can use
virtio-rng or similar.

However, the fact is that when we design systems, we are constrained by
constraints placed by other parts of the process out of our control.
Delivering an image that is static and that will be deployed onto
multiple systems is something that does happen and it happens because
it's the best design tradeoff available.
It does have security implications, and in fact may decrease security of
random numbers overall.  On the other hand, it can increase security of
code integrity and tends to be associated with design methodologies that
create reproducible environments.

So, you can try and sweep static images under the rug, but all you're
doing is dsmissing people with real problems they need to solve.
It would be much more constructive to acknowledge that people will use
static images, discuss the security implications, solve the problems we
can solve, and document the residual security implications so our users
and the broader community are aware of our limitations.

--Sam

Bug#898629: improve battery life on laptop with kernel config

[Hideki Yamane]

Package: linux
Version: 4.17~rc3-1~exp1
Severity: wishlist
Tags: patch

Hi,

 I've found Fedora28 tries to improve battery life on laptop.
 
https://docs.fedoraproject.org/f28/release-notes/sysadmin/Kernel.html#sect-kernel-battery
 
 There are three points.

  1. A new SATA link-powermanagement-policy has been written which mirrors
 Windows defaults: med_power_with_dipm, this has been merged for kernel
 4.15, as part of this change this new policy will be the default on all
 Intel mobile chipsets. This saves aprox. 1.0 - 1.5 Watts of power on an
 idle laptop.
  2. Enable Intel HDA codec power-saving by default with a 1 second timeout.
 This saves aprox. 0.4 Watts of power on an idle laptop.
  3. Enable USB autosuspend for USB bluetooth receivers by default. If all
 other USB devices on the laptop also have USB auto-suspend enabled
 (which typically is true) this saves aprox. 0.4 Watts of power on an idle
 laptop. 


 Can we introduce such improvement into debian kernel? (especially amd64)
 I've tested it with modified 4.17~rc3 kernel as below and powertop, power
 consumption becomes 5.76 w to 4.61 w on my ThinkPad E450.


--- ./linux-4.17~rc3/debian/config/config   2018-04-20 09:33:41.0 
+0900
+++ /home/henrich/linux-4.17~rc3/debian/config/config   2018-05-06 
10:54:04.478447041 +0900
@@ -199,6 +199,7 @@
 CONFIG_SATA_ZPODD=y
 CONFIG_SATA_PMP=y
 CONFIG_SATA_AHCI=m
+CONFIG_SATA_MOBILE_LPM_POLICY=3
 # CONFIG_SATA_AHCI_PLATFORM is not set
 # CONFIG_AHCI_CEVA is not set
 # CONFIG_AHCI_QORIQ is not set
@@ -360,6 +361,7 @@
 ## file: drivers/bluetooth/Kconfig
 ##
 CONFIG_BT_HCIBTUSB=m
+CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y
 CONFIG_BT_HCIBTUSB_BCM=y
 CONFIG_BT_HCIBTUSB_RTL=y
 CONFIG_BT_HCIBTSDIO=m
@@ -7327,7 +7329,8 @@
 CONFIG_SND_HDA_CODEC_CMEDIA=y
 CONFIG_SND_HDA_CODEC_SI3054=y
 CONFIG_SND_HDA_GENERIC=y
-CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
+CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1
+CONFIG_SND_HDA_POWER_SAVE=y
 
 ##
 ## file: sound/pcmcia/Kconfig

Re: Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts

[Simon McVittie]

On Sat, 12 May 2018 at 18:26:11 -0700, Ross Vandegrift wrote:
> After upgrading my laptop from stretch to buster, I'm not able to mount NFS 
> via
> mdns.  I have the following entry in /etc/fstab:
> 
>   vanvanmojo.local:/mnt/storage   /mnt/storage nfs4   
> noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,x-systemd.requires=network-online.target,x-systemd.idle-timeout=10m
> 0   0
> 
> The mount fails with the following log message:
> 
>   stgulik kernel: [  575.329441] NFS: bad IP address specified: 
> addr=2606:6000:4502:1d00:4639:c4ff:fe53:e49b%2
> 
> It looks like the scope id was added in #644912.  This may be a kernel bug if
> the scope id should be accepted.

I think this might be a bug in whatever user-space tool calls
getaddrinfo() and passes its result to the kernel, which probably means
mount.nfs? If the kernel doesn't want to see scope IDs in this context,
then the user-space tool shouldn't provide them: returning scope IDs is
part of the getaddrinfo() API.

Not including the scope ID in the result of address resolution breaks IPv6
link-local addressing (fe80:*), and link-local addressing and mDNS are both
parts of the Zeroconf stack, so they (should) go well together.

Or possibly nss-mdns should be setting the scope ID to the interface
index for link-local addresses, but not for other addresses? It isn't
entirely clear to me what nss-mdns is meant to be doing here.

Workarounds:

* don't use mDNS (.local names) to find NFS servers; or
* configure mdns4[_minimal] instead of mdns[_minimal] so .local names
  resolve to IPv4 addresses

NFS has historically been somewhat fragile against network failures,
so I'm not sure that I can recommend mDNS as a way to find NFS shares.
If your network is sufficiently static and hand-configured that you can
safely put NFS shares in /etc/fstab, then it's probably also sufficiently
static that the NFS server has a stable name, or even a stable IP address.

smcv

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Hello Frank and Pradeep,

I was hoping that you would have some insight on a possible
bug/regression/incompability between nfs-ganesha and the Linux kernel
with a specific patch to which you reacted (see below) in
https://marc.info/?l=linux-nfs=150998968529002=2.

There is no mail about the results of Pradeep's checking whether that
patch is safe for nfs-ganesha on the server side, or whether there were
additional changes needed. Maybe one of you could shed some light on that.

I've created a tracking Debian bug report for our issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898165

Best regards,
Moritz

On 14.05.2018 11:05, Moritz Schlarb wrote:
> Control: tags -1 + patch upstream
> Control: notfound -1 linux/3.16.51-3+deb8u1
> 
> Hi everyone,
> 
> I have identified the upstream commit that introduced this
> bug/regression for us.
> 
> It is c05cefcc72416a37eba5a2b35f0704ed758a9145 "nfs: Fix ugly referral
> attributes"
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c05cefcc72416a37eba5a2b35f0704ed758a9145)
> which seems to have been part of upstream 3.16.54.
> 
> I have manually compiled 3.16.56-1+deb8u1 with that patch reversed and I
> can successfully mount my home directory again.
> 
> Regards,
> 

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Control: tags -1 + patch upstream
Control: notfound -1 linux/3.16.51-3+deb8u1

Hi everyone,

I have identified the upstream commit that introduced this
bug/regression for us.

It is c05cefcc72416a37eba5a2b35f0704ed758a9145 "nfs: Fix ugly referral
attributes"
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c05cefcc72416a37eba5a2b35f0704ed758a9145)
which seems to have been part of upstream 3.16.54.

I have manually compiled 3.16.56-1+deb8u1 with that patch reversed and I
can successfully mount my home directory again.

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Processed: Re: Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + patch upstream
Bug #898165 [src:linux] linux-image-3.16.0-6-amd64: can't mount NFS shares via 
nfs referrals
Added tag(s) patch and upstream.
> notfound -1 linux/3.16.51-3+deb8u1
Bug #898165 [src:linux] linux-image-3.16.0-6-amd64: can't mount NFS shares via 
nfs referrals
No longer marked as found in versions linux/3.16.51-3+deb8u1.

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

linux-signed-amd64_1+4.17~rc3+1~exp1_source.changes is NEW

[Debian FTP Masters]

binary:linux-image-4.17.0-rc3-amd64 is NEW.
binary:linux-image-4.17.0-rc3-cloud-amd64 is NEW.
source:linux-signed-amd64 is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports