Bug#847204: nfs-kernel-server: `systemctl status` incorrectly reports server "active" even if not started

On 12/18/2016 11:41 PM, Michael Biebl wrote: > On Tue, 6 Dec 2016 15:15:12 +0100 Riccardo Murri > wrote: >> >> Package: nfs-kernel-server >> Version: 1:1.2.8-9 >> >> The systemd service unit file for `nfs-kernel-server` incorrectly >> reports the service status as "active" even when the NFS server

Re: cross building linux-image packages

On 11/01/2016 12:22 AM, Andrew Worsley wrote: > I tried using pbuilder (based off > https://jodal.no/2015/03/08/building-arm-debs-with-pbuilder/) but -> > qemu-arm-static has bugs (segmentation faults - possibly > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811087 You can use (in your pbuild

Bug#814648: linux kernel backports broken

Hello, On 05/31/2016 10:15 PM, Antoine Beaupré wrote: > On 2016-05-31 16:01:46, Hector Oron wrote: >> Hello, >> >> El 31 may. 2016 9:56 p. m., "Antoine Beaupré" escribió: >> >>> Hi, >>> >>> I still see this problem in debian jessie right now. I can't install the >>> linux kernel backport. >>> >>>

Bug#815787: May be a kernel problem not a pulseaudio one?

On 02/27/2016 10:52 PM, Cristian Ionescu-Idbohrn wrote: >> * [amd64] mm,nvdimm: Disable ZONE_DMA; enable ZONE_DEVICE, NVDIMM_PFN >> - This disables drivers for some AC'97 sound cards > > Alright, but not obvious to me. > > So, what is to do about that? There are people working upstream on

Re: NFS / rpcbind and systemd on Jessie

Hi, On 02/16/2016 06:57 PM, Frédéric SOSSON wrote: > I have an issue with NFS / rpcbind and systemd on Jessie (up2date). > > According to systemctl nfs-common.service and nfs-kernel-server.service > both start properly. > > The issue downs to rpcbind. Here the message from journalctl: > rpcbind

Bug#805252: linux-image-4.2.0-1-amd64: I/O errors when writing to iSCSI volumes

haven't done any tests in that direction. Regards, Christian PS, for reference, upstream discussion on the initiator mailing list that resulted in me finding out that it's not the initiator but the target that was the problem: https://groups.google.com/forum/#!topic/open-iscsi/UE2JJfDmQ7w

Bug#805252: linux-image-4.2.0-1-amd64: I/O errors when writing to iSCSI volumes

Control: tags -1 - fixed-upstream patch Control: notfixed -1 4.4~rc5-1~exp1 Hi, I'm sorry, but the commit in question doesn't help. I just got around to testing this with 4.4-1~exp1, and I verified that the sources do indeed contain the aforementioned patch, and the problem persists. I also tried

Bug#805252: linux-image-4.2.0-1-amd64: I/O errors when writing to iSCSI volumes

Package: src:linux Version: 4.2.6-1 Severity: important Tags: upstream Dear Maintainer, with this kernel version writing to iSCSI volumes will consistently produce I/O errors. It appears as though this happens if a lot of writes are performed at once (but I'm not sure of that). I've seen this in

Re: auto-mount NFS shares on boot

Thanks for taking care of this! Am 2015-07-07 13:03, schrieb Jonas Meurer: Am 2015-06-28 12:54, schrieb Michael Biebl: I suggest to add this simple fix to Jessie by uploading it to stable-proposed-updates. What do you think? Also, do you think that /etc/systemd/system/remote-fs-pre.target.d/nf

Bug#775542: auto-mount NFS shares on boot

On 06/27/2015 08:02 PM, Jonas Meurer wrote: > Am 27.06.2015 um 16:07 schrieb Christian Seiler: >> Could you try to do the following: >> >> 1. create a directory /etc/systemd/system/remote-fs-pre.target.d >> 2. create a file /etc/systemd/system/remote-fs-pre.targe

Bug#775542: auto-mount NFS shares on boot

(Ccing the bugtracker because it appears you've stumbled upon a bug that also a few other people had, see below. Please don't reply to the bugtracker yourself unless you feel it's relevant for the bug report.) Link to thread on debian-user for people reading the bug report: https://lists.debian.or

Bug#769935: linux: Please backport nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait

Source: linux Version: 3.16.7-2 Severity: important Tags: upstream patch Dear Maintainer, in certain circumstances, the kernel may busy-wait indefinitely after processing a SIGKILL to a process when using NFS. There is a patch for this issue that went into 3.17:

Bug#742619: linux: Please reenable CONFIG_SCSI_PROC_FS

Control: found -1 3.16.3-2 Hi, Since the freeze for Jessie is around the corner, I wanted to ask if you have considered enabling this again at least for Jessie? Thank you! Kind regards, Christian -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscrib

Bug#742619: linux: Please reenable CONFIG_SCSI_PROC_FS

Hello, I'm sorry if this seems pushy, but since it is trivial to implement this change, I'd like to ask if you've considered reenabling CONFIG_SCSI_PROC_FS? Thank you! Regards, Christian -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Tro

Bug#742619: linux: Please reenable CONFIG_SCSI_PROC_FS

Package: linux Version: 3.2.54-2 Severity: wishlist Some hardware vendor tools (e.g. HP Library and Tape Tools) still rely on the existence of /proc/scsi. In Squeeze /proc/scsi was re-enabled in linux-2.6 (2.6.32-32) see also #618258 and it is still default upstream: path: root/drivers/scsi

Bug#699283: linux: Build Sandy Bridge EDAC module in kernels that support it

Package: linux Version: 3.2.35-2 Severity: wishlist In the current Wheezy kernel, all EDAC modules are built save for the one for Intel's Sandy Bridge architecture. It would be nice if one could read out EDAC on Sandy Bridge systems, thanks! The missing kernel configuration is: CONFIG_EDAC_

Bug#696321: Launchpad bug for the same issue

I stumbled upon this bug while using a backported kernel on squeeze, and in the process of trying to find a solution, I noticed that there is also a bug report against Ubuntu kernels in launchpad. The patch attached to a comment there that reverts a certain commit seems to solve the problem for me