Server nfs-home reports our clientid is in use
Hi folks, I am running Whezzy on my NFServer and the NFS clients. Kernel is Linux nfs-home.example.com 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt11-1~bpo70+1 (2015-06-08) x86_64 GNU/Linux Problem: Sometimes a client cannot write to /home via NFS anymore. The error message in kern.log on the client says Jul 30 15:53:57 dpcl082 kernel: [2880660.867248] NFS: Server nfs-home reports our clientid is in use Jul 30 15:53:57 dpcl082 kernel: [2880660.867254] NFS: state manager: lease expired failed on NFSv4 server nfs-home with Jul 30 15:54:54 dpcl082 kernel: [2880717.424872] NFS: Server nfs-home reports our clientid is in use Jul 30 15:54:54 dpcl082 kernel: [2880717.424878] NFS: state manager: lease expired failed on NFSv4 server nfs-home with Jul 30 15:55:01 dpcl082 kernel: [2880724.526741] NFS: Server nfs-home reports our clientid is in use Jul 30 15:55:01 dpcl082 kernel: [2880724.526748] NFS: state manager: lease expired failed on NFSv4 server nfs-home with : : I have to umount and mount /home to get read access again. The kern.log on the server doesn't mention this incident. Since I saw NFSv4.1: Fix client id trunking on Linux introduced with 3.16.7-ckt7-1 I wonder if this rings a bell somewhere? By now I saw this problem 4 times within the last week. There are more than 100 NFS clients, using a static mount of /home , i.e. the problem is hard to reproduce. Every helpful comment is highly appreciated. Regards Harri signature.asc Description: PGP signature
Re: [Reproducible-builds] Reproducibility vs signatures
Ben Hutchings: On Mon, 2015-08-03 at 10:27 +0200, Jérémy Bobbio wrote: Ben Hutchings: At some point we're hopefully going to support Secure Boot on amd64. That means there will be a signed kernel image (separate from the current linux-image packages) and a signed GRUB image. The kernel modules in the linux-image packages will also be signed, probably with an ephemeral key. All these signatures will all be embedded within binaries and will of course not be reproducible. The locations of differences will however be predictable. How should we deal with this limited variability? Could source packages or buildinfo describe the expected variations somehow? One way to solve this, although a bit wasteful on resource, is to use the clean rule to perform a first build and create a signature to be added to the source package. That sort of works as long as there's only one architecture we want to do this for. But the ability to verify modules is useful in general so I would like to turn that on for all architectures. Here's a solution I had in my mind when opening my eyes this morning [1]: Ship signatures in a separate source package, e.g. linux-signatures. Have linux-image Recommends linux-signatures. Ideally, I think the signatures should be shipped in extra files. Another solution would be to use xattrs and set them in a postinst script [2]. Or mangle the files in place to add signatures, but that would prevent using debsums. Both linux-image and linux-signatures can be built reproducibly. linux-signatures will have the actual signatures in its source, generated for a specific linux-image version. That way the release process can be: upload new linux, wait for buildds, retrieve results from archive, create linux-signatures, upload linux-signatures. Have linux build reproducibly can help the signers gain exta confidence that the buildd are not compromised by performing extra builds on different systems. What do you think? [1]: Yes, human brains seem to also have background tasks. [2]: xattrs are used by IMA, see https://lwn.net/Articles/488906/ and #766267. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Converting kernel svn to git
We've been talking about this for at least 6 years, and it's well past
time to do it.
(I think most developers are already using git-svn, but that doesn't
properly handle tags and merges so I've never been able to make use of
it.)
I started on a conversion that would include stitching in the upstream
history for the linux package, but that depends on how we store patches
in git and there isn't yet an obvious winner there (git-dpm vs git
-debcherry vs dgit vs ...). If the patches should be applied as git
commits, then we can't represent all of history because sometimes the
patches didn't apply. And featuresets don't fit into this at all.
I think that the best thing to do now is to do a straight conversion of
the debian directory only. We can stitch in upstream later.
Here's where I am with the conversion:
https://anonscm.debian.org/cgit/kernel/temp/
Known bugs:
linux.git
-
Commits tagged 2.6.12-2, 2.6.16-{15,16,17}, 2.6.18.dfsg.1-24etch2,
2.6.26-{17,20} are detached.
Several weird merges in early history.
Many merges in svn are not recorded in git, but this is presumably due
to lack of mergeinfo in old svn versions.
Commit tagged 2.6.24-7 looks like a 4-way merge which shouldn't be
possible in svn! This might be due to svn mergeinfo accumulating
branches.
linux-latest.git
Tip of wheezy branch is detached from its parent
Many merges from sid to wheezy-backports are not recorded
No squeeze branch
linux-tools.git
---
Many merges from sid to trunk are not recorded
firmware-nonfree.git
Tip of wheezy branch is detached from its parent
What do we do with the sid branch?
The 0.19 tag is in a firmware-nonfree subdirectory
Merge before 0.4+etchnhalf.1 should not be recorded as a merge
Ben.
--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
signature.asc
Description: This is a digitally signed message part
Bug#794520: linux-image-4.0.0-2-amd64: AMD A8-7100, no thermal information
On Mon, Aug 03, 2015 at 11:53:19PM -0300, Raphaël wrote: - graphics chipset: - xorg still failing back on VESA: some hope will come from linux 4.2 and the DRM_AMDGPU/amdkfd was wrong. After reading https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780475 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780107 and an update of firmware-linux to testing (= 0.44), the kernel found the firmwares, the module was loaded successfully and X, mesa co started using xserver-xorg-video-radeon. but... - graphics chipset: - backlight: /sys/class/backlight/thinkpad_screen exists using acpi_backlight=vendor, but xrandr (thus xbacklight) complains: Failed to get size of gamma for output default - thermal absent is still true. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150805125401.GA8868@localhost.localdomain
Delivering Digital Solutions
*Hello*, zeni.net Team, * Hope you are doing well, * *We can help your business/organization to earn the identity it needs on the internet as it is the best platform for marketing today. Our services web development in Web Designing includes* 1. Android Development 2. Asp.net development 3. content management system 4. copy writing services 5. cross browser compatibility 6. custom e-commerce website 7. custom website design 8. custom website development 9. custom Word press designs 10. custom Word press theme development 11. data entry services 12. ecommerce development 13. ecommerce solutions 14. Facebook apps development 15. graphics design 16. iPhone ipad apps development 17. joomla development 18. landing page design 19. magento development 20. mobile development 21. multimedia and graphic 22. newsletter template 23. open source customization 24. photo slideshows and galleries 25. Php development 26. search engine optimization 27. social media optimization 28. social media presence 29. social network development 30. table less coding 31. web design 32. web design and development 33. web development 34. Word press development 35.Word press blog customization WORDPRESS DESIGNER *Sounds interesting? Feel free to email us or alternatively you can provide me with your phone number and the best time to call you.* Thanks Regards, Roger Henry Designing Development Consultant Note: If you are not interested, please email with the subject line Remove and I will happy to update my data base --wd/rs---
Bug#794680: drbd kernel module incompatible with drbd-utils - kernel panics
Package: linux Version: 3.16.7-ckt11-1+deb8u2 Severity: critical Hi, TL;DR - please provide a kernel with a newer drbd module (e.g. 8.4.6), as the current version is incompatible with stable's drbd-utils and will result in kernel panics under load. I have the following kernel: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17) This ships with version 8.4.3 of the drbd kernel module (which advertises '(api:1/proto:86-101)'). Using that version of the module with stable's drbd-utils (8.9.2rc1) results in kernel panics under heavy I/O load, fairly repeatedly. A kernel log of a typical crash is attached to this report. I intially reported this issue to Xen (since it happened in a dom0), and they referred me to this blog post: http://blog.chinewalking.com/drbd-kernel-oops-w-trim/ Notably, you will observe that drbd-module =8.4.4 supports trim, whereas 8.4.3 does not. Yet the userland tools arrange to use trim anyway: Aug 4 14:28:24 ophon kernel: [2856757.049680] drbd mws-02474: Agreed to support TRIM on protocol level Following that suggestion, I installed the kernel module 8.4.6 from upstream, and the kernel has stopped panicking. You might argue that drbd upstream's api/proto discrimination is inadequate (and perhaps a bug report should go there), but nonetheless kernel panics are a serious flaw in the kernel (or the offending module) IMAO. Regards, Matthew -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-backports'), (500, 'stable\ ') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Aug 3 16:03:13 opus kernel: [ 1250.026811] drbd mws-priv-1: Starting worker thread (from drbdsetup-84 [12987]) Aug 3 16:03:13 opus kernel: [ 1250.027313] block drbd4: disk( Diskless - Attaching ) Aug 3 16:03:13 opus kernel: [ 1250.027409] drbd mws-priv-1: Method to ensure write ordering: flush Aug 3 16:03:13 opus kernel: [ 1250.027413] block drbd4: max BIO size = 4096 Aug 3 16:03:13 opus kernel: [ 1250.027418] block drbd4: drbd_bm_resize called with capacity == 41941688 Aug 3 16:03:13 opus kernel: [ 1250.027558] block drbd4: resync bitmap: bits=5242711 words=81918 pages=160 Aug 3 16:03:13 opus kernel: [ 1250.027561] block drbd4: size = 20 GB (20970844 KB) Aug 3 16:03:13 opus kernel: [ 1250.032268] block drbd4: Writing the whole bitmap, size changed Aug 3 16:03:13 opus kernel: [ 1250.047827] block drbd4: bitmap WRITE of 160 pages took 4 jiffies Aug 3 16:03:13 opus kernel: [ 1250.061634] block drbd4: 20 GB (5242711 bits) marked out-of-sync by on disk bit-map. Aug 3 16:03:13 opus kernel: [ 1250.180186] block drbd4: bitmap READ of 160 pages took 2 jiffies Aug 3 16:03:13 opus kernel: [ 1250.180291] block drbd4: recounting of set bits took additional 0 jiffies Aug 3 16:03:13 opus kernel: [ 1250.180293] block drbd4: 20 GB (5242711 bits) marked out-of-sync by on disk bit-map. Aug 3 16:03:13 opus kernel: [ 1250.180304] block drbd4: Suspended AL updates Aug 3 16:03:13 opus kernel: [ 1250.180307] block drbd4: disk( Attaching - Inconsistent ) Aug 3 16:03:13 opus kernel: [ 1250.180310] block drbd4: attached to UUIDs 0004::: Aug 3 16:03:13 opus kernel: [ 1250.191161] drbd mws-priv-1: conn( StandAlone - Unconnected ) Aug 3 16:03:13 opus kernel: [ 1250.191183] drbd mws-priv-1: Starting receiver thread (from drbd_w_mws-priv [12989]) Aug 3 16:03:13 opus kernel: [ 1250.191345] drbd mws-priv-1: receiver (re)started Aug 3 16:03:13 opus kernel: [ 1250.191360] drbd mws-priv-1: conn( Unconnected - WFConnection ) Aug 3 16:03:13 opus kernel: [ 1250.689576] drbd mws-priv-1: Handshake successful: Agreed network protocol version 101 Aug 3 16:03:13 opus kernel: [ 1250.689580] drbd mws-priv-1: Agreed to support TRIM on protocol level Aug 3 16:03:13 opus kernel: [ 1250.689616] drbd mws-priv-1: conn( WFConnection - WFReportParams ) Aug 3 16:03:13 opus kernel: [ 1250.689631] drbd mws-priv-1: Starting asender thread (from drbd_r_mws-priv [12992]) Aug 3 16:03:13 opus kernel: [ 1250.737084] block drbd4: max BIO size = 1048576 Aug 3 16:03:13 opus kernel: [ 1250.737091] block drbd4: drbd_sync_handshake: Aug 3 16:03:13 opus kernel: [ 1250.737094] block drbd4: self 0004::: bits:5242711 flags:0 Aug 3 16:03:13 opus kernel: [ 1250.737096] block drbd4: peer 0004::: bits:5242711 flags:0 Aug 3 16:03:13 opus kernel: [ 1250.737098] block drbd4: uuid_compare()=0 by rule 10 Aug 3 16:03:13 opus kernel: [ 1250.737100] block drbd4: No resync, but 5242711 bits in bitmap! Aug 3 16:03:13 opus
Re: Converting kernel svn to git
Hello everyone,
On Wed, Aug 05, 2015 at 12:46:47PM +0100, Ben Hutchings wrote:
We've been talking about this for at least 6 years, and it's well past
time to do it.
thanks a lot Ben for pushing this.
(I think most developers are already using git-svn, but that doesn't
properly handle tags and merges so I've never been able to make use of
it.)
I'd be delighted to fully forget svn usage, as git svn is still a
foreign git.
I started on a conversion that would include stitching in the upstream
history for the linux package, but that depends on how we store patches
in git and there isn't yet an obvious winner there (git-dpm vs git
-debcherry vs dgit vs ...). If the patches should be applied as git
commits, then we can't represent all of history because sometimes the
patches didn't apply. And featuresets don't fit into this at all.
I think that the best thing to do now is to do a straight conversion of
the debian directory only. We can stitch in upstream later.
Here's where I am with the conversion:
https://anonscm.debian.org/cgit/kernel/temp/
cool.
One proposition why not keep this as linux-debian-history-git
and start from scratch with what is inside of the latest svn.
This would reduce the number of branches and tags and might
be a cleaner restart. What do you think?
Known bugs:
linux.git
-
Commits tagged 2.6.12-2, 2.6.16-{15,16,17}, 2.6.18.dfsg.1-24etch2,
2.6.26-{17,20} are detached.
Several weird merges in early history.
Many merges in svn are not recorded in git, but this is presumably due
to lack of mergeinfo in old svn versions.
Commit tagged 2.6.24-7 looks like a 4-way merge which shouldn't be
possible in svn! This might be due to svn mergeinfo accumulating
branches.
linux-latest.git
Tip of wheezy branch is detached from its parent
Many merges from sid to wheezy-backports are not recorded
No squeeze branch
linux-tools.git
---
Many merges from sid to trunk are not recorded
firmware-nonfree.git
Tip of wheezy branch is detached from its parent
What do we do with the sid branch?
The 0.19 tag is in a firmware-nonfree subdirectory
Merge before 0.4+etchnhalf.1 should not be recorded as a merge
On the other hand, none of the known bugs you mention is a show-stopper
for the transition from my side.
kind regards,
--
maks
signature.asc
Description: Digital signature
Processed: Re: Bug#794680: drbd kernel module incompatible with drbd-utils - kernel panics
Processing control commands: tag -1 moreinfo Bug #794680 [linux] drbd kernel module incompatible with drbd-utils - kernel panics Ignoring request to alter tags of bug #794680 to the same tags previously set -- 794680: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794680 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b794680.143880862124485.transcr...@bugs.debian.org
Bug#794680: drbd kernel module incompatible with drbd-utils - kernel panics
Control: tag -1 moreinfo The panic is in a network communication thread, not in anything handling commands from drbd-utils, so I'm not convinced that this has anything to do with the version of the latter. On Wed, 2015-08-05 at 17:17 +0100, Matthew Vernon wrote: [...] Following that suggestion, I installed the kernel module 8.4.6 from upstream, and the kernel has stopped panicking. The current upstream (in-tree) version is 8.4.5 (still with the same API and protocol versions). [...] You might argue that drbd upstream's api/proto discrimination is inadequate (and perhaps a bug report should go there), but nonetheless kernel panics are a serious flaw in the kernel (or the offending module) IMAO. Clearly the driver ought not to crash, but I'm not sure that a wholesale update is the right solution. The first plausible return address on the stack points to the instruction after http://sources.debian.net/src/linux/3.16.7-ckt11-1%2Bdeb8u2/drivers/block/drbd/drbd_receiver.c/#L5443 which implies something went wrong in drbd_recv_short() http://sources.debian.net/src/linux/3.16.7-ckt11-1%2Bdeb8u2/drivers/block/drbd/drbd_receiver.c/#L478. The stack dump (not the call stack) shows: [8800022f3d90] 8800022f3d88 0010 iov.iov_base !!! iov.iov_len msg.msg_name msg.msg_namelen [8800022f3db0] 8800022f3d90 0001 msg.msg_iov = iov msg.msg_iovlen msg.msg_control msg.msg_controllen [8800022f3dd0] 4100 a02577be 880016c92080 0010 msg.msg_flagsreturn address connection-flags header_size received which looks consistent with the stack frame of drbd_recv_short() (plus 16 bytes from the stack frame of drbd_asender()). However iov.iov_base is clearly wrong - it is equal to RSP-8, not the buffer. It's also equal to the faulting RIP. Can you reproduce this with Linux 4.1 (now in unstable)? Can you reproduce this on bare hardware (without Xen)? Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. signature.asc Description: This is a digitally signed message part
Bug#794680: drbd kernel module incompatible with drbd-utils - kernel panics
Hi, On 05/08/15 22:03, Ben Hutchings wrote: Control: tag -1 moreinfo The panic is in a network communication thread, not in anything handling commands from drbd-utils, so I'm not convinced that this has anything to do with the version of the latter. How do you explain a drbd-module update fixing this problem, then? Can you reproduce this with Linux 4.1 (now in unstable)? With the drbd-module version in that kernel, or some other module? Regards, Matthew -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c28807.4030...@cam.ac.uk
Bug#794680: drbd kernel module incompatible with drbd-utils - kernel panics
Control: severity -1 important Control: tag -1 moreinfo On Wed, Aug 05, 2015 at 05:17:54PM +0100, Matthew Vernon wrote: TL;DR - please provide a kernel with a newer drbd module (e.g. 8.4.6), as the current version is incompatible with stable's drbd-utils and will result in kernel panics under load. Please provide commit ids for the kernel changes. You might argue that drbd upstream's api/proto discrimination is inadequate (and perhaps a bug report should go there), but nonetheless kernel panics are a serious flaw in the kernel (or the offending module) IMAO. Still not critical, fixed. Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, The Enterprise Incident, stardate 5027.3 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150805191125.gc17...@shell.waldi.eu.org
Processed: Re: Bug#794680: drbd kernel module incompatible with drbd-utils - kernel panics
Processing control commands: severity -1 important Bug #794680 [linux] drbd kernel module incompatible with drbd-utils - kernel panics Severity set to 'important' from 'critical' tag -1 moreinfo Bug #794680 [linux] drbd kernel module incompatible with drbd-utils - kernel panics Added tag(s) moreinfo. -- 794680: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794680 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b794680.143880233224172.transcr...@bugs.debian.org
Bug#794680: drbd kernel module incompatible with drbd-utils - kernel panics
On Wed, 2015-08-05 at 23:02 +0100, Matthew Vernon wrote: Hi, On 05/08/15 22:03, Ben Hutchings wrote: Control: tag -1 moreinfo The panic is in a network communication thread, not in anything handling commands from drbd-utils, so I'm not convinced that this has anything to do with the version of the latter. How do you explain a drbd-module update fixing this problem, then? I don't have to explain it. Can you reproduce this with Linux 4.1 (now in unstable)? With the drbd-module version in that kernel, or some other module? The in-tree version. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. signature.asc Description: This is a digitally signed message part
