Bug#1067006: marked as done (rpc-statd.service: State 'stop-sigterm' timed out. Killing.)

Found it on Bookworm as well. Regards Harri

Bug#1067006: marked as done (rpc-statd.service: State 'stop-sigterm' timed out. Killing.)

Hi Salvatore, sorry for not sending a reply. I completely forgot this bug report. Fortunately it appears to be still open. I ran into this problem again just a few minutes ago on running apt upgrade. Several services were restarted in parallel, using "needrestart". journalctl shows: Apr 21

Bug#1067006: rpc-statd.service: State 'stop-sigterm' timed out. Killing.

Package: nfs-common Version: 1:2.6.4-3 Restarting rpc-statd.service (e.g via needrestart at upgrade time) runs into a timeout: Mar 16 20:06:58 lola.afaics.de systemd[1]: rpc-statd.service: State 'stop-sigterm' timed out. Killing. Mar 16 20:06:58 lola.afaics.de systemd[1]: rpc-statd.service:

Re: Bug#1064579: new git url for non-free firmware

It didn't work when I tried, sorry. Seems to be OK now.

Bug#1064579: new git url for non-free firmware

Package: firmware-iwlwifi Version: 20230625-2 The source URL mentioned in the copyright file doesn't work anymore. It seems to be https://kernel.googlesource.com/pub/scm/linux/kernel/git/firmware/linux-firmware now. Same goes for other packages. Regards Harri

Re: why do I have to use backports kernel to make LXC work on Bookworm?

On 2023-12-28 14:40:30, Salvatore Bonaccorso wrote: Because it needs backporting work in 6.1.y upstream, which for John Johansen aimed to work on. You can read about the history and backlog in #1050256 . So far I have not got a reply from John on https://bugs.debian.org/1050256#215 . Oh, I

why do I have to use backports kernel to make LXC work on Bookworm?

Hi folks, apparently LXC is affected by a bug around apparmor support for months, see #1052934 and #1050256. The workaround is to set PrivateNetwork=false (set by default as a security measure) or to use a backports kernel. AFAIU reason is a bug in 6.1. The fix (1cf26c3d2c4c) is not a

Bug#1023384: broken source URL in copyright file, new upstream?

Package: firmware-linux-free Version: 20200122-1 The source mentioned in the copyright file is broken: % git clone https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git Cloning into 'linux-firmware'... fatal: repository

stable vs current hardware ?

Hi folks, what is Debian's policy wrt using the current stable version with current hardware? Am I supposed to create a bug report about linux-signed-amd64 or firmware-nonfree, if (lets say) WLAN is broken on a 1 year old notebook? Use backports or unstable instead? Regards Harri

Bug#1009316: firmware-linux-nonfree: new upstream release (20220610)

metoo. The current nonfree package is more than 12 months old. Thank you very much in advance Harri

Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"

Sure, but why does systemctl complain about rpc-svcgssd.service, if there are no NFS credentials inside? Its perfectly fine to run NFS without cryptographic security, even though /etc/krb5.keytab does exist. I have the impression that the conditionals you mentioned are not complete.

Re: Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"

Hi Salvatore, would it be possible to check if there are some NFS credentials in the krb5.keytab file before issuing an error? Regards Harri

Bug#1002829: please document how to set nfsv4gracetime and nfsv4leasetime

Package: nfs-kernel-server Version: 1:1.3.4-6 I would like to reduce nfsv4gracetime and nfsv4leasetime from 90 sec to something reasonable. Looking through several scripts and systemd config files I figured out that I have to set RPCNFSDOPTS in /etc/default/nfs-server.conf to make a

Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"

Package: nfs-common Version: 1:1.3.4-6 systemd moans about krb5.keytab at boot time ``` # systemctl --failed UNITLOAD ACTIVE SUBDESCRIPTION * rpc-svcgssd.service loaded failed failed RPC security service for NFS server LOAD = Reflects whether the unit definition was

PTE Write access is not set

Package: linux-image-5.10.0-9-amd64 Version: 5.10.70-1 I have found a lot of messages in on 4 Dell R740 (with Perc H740P controller and 7 SSDs in RAID5 plus 1 hot spare) this morning: [Fri Nov 5 07:40:53 2021] DMAR: DRHD: handling fault status reg 2 [Fri Nov 5 07:40:53 2021] DMAR: [DMA Write]

Bug#994077: nfs-server.service fails (because autofs hasn't been started yet?)

PS: Using sysvinit both services are fine.

Bug#994077: nfs-server.service fails (because autofs hasn't been started yet?)

Package: nfs-kernel-server Version: 1:1.3.4-6 After boot the nfs-server is not ready yet: # systemctl status nfs-server * nfs-server.service - NFS server and services Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled) Active: failed (Result:

linux-image-5.10.0-0.bpo.3-amd64: sync gets stuck

Hi folks, using linux-image-5.10.0-0.bpo.3-amd64 (buster-backports) and dd to write an iso image (e.g. ubuntu-20.10-desktop-amd64.iso) to an USB stick: dd stops writing and closes source and destination file handle, but it does not exit. It cannot be interrupted, either. At shutdown time the

Bug#962788:

Actually I cannot say. I haven't seen this problem in a while. And /etc/init.d/nfs-common start does PIPEFS_MOUNTPOINT=/run/rpc_pipefs : mkdir -p "$PIPEFS_MOUNTPOINT" : modprobe sunrpc nfs nfsd mount -t rpc_pipefs rpc_pipefs $PIPEFS_MOUNTPOINT

Re: Bug#962788:

Actually I cannot say. I haven't seen this problem in a while. And /etc/init.d/nfs-common start does PIPEFS_MOUNTPOINT=/run/rpc_pipefs : mkdir -p "$PIPEFS_MOUNTPOINT" : modprobe sunrpc nfs nfsd mount -t rpc_pipefs rpc_pipefs $PIPEFS_MOUNTPOINT

Re: Bug#962788: rpc.idmapd[9725]: main: open(/run/rpc_pipefs/nfs): No such file or directory

PS: /etc/default/nfs-common says NEED_STATD=yes STATDOPTS="-n nasl006.example.com" NEED_IDMAPD=yes NEED_GSSD= PIPEFS_MOUNTPOINT=/var/lib/rpc_pipefs

Bug#962788: rpc.idmapd[9725]: main: open(/run/rpc_pipefs/nfs): No such file or directory

Package: nfs-common Version: 1:1.3.4-2.1 Running "/etc/init.d/nfs-common start" rpc.idmapd failed with rpc.idmapd[9725]: main: open(/run/rpc_pipefs/nfs): No such file or directory Ain't the startup script supposed to create this directory? init is sysv Regards Harri

pciutils up-to-date for Buster backports?

Hi folks, using the 5.5.17 backports kernel: lspci froze the whole pc (at least on a Lenovo p53). Is it possible that we need a backport of the 3.6 pciutils package? I had sent this to the debian-backports list before, but there was no response. Regards Harri

Re: increase kernel.pid_max?

Would it be reasonable to configure these kind of items and limits *independent* of the init system? This would help to avoid unexpected side effects of changing the init system. Thanx in advance Harri

increase kernel.pid_max?

Hi folks, looking at the number of cores and highly parallel applications I wonder if it would be reasonable to increase the default kernel.pid_max (currently 0x8000) to lets say 0x3f? Do you expect negative side effects? Regards Harri

Bug#832609: rpc-gssd.service: fails to start when keytab exists (ActiveDirectory member) but rpcsec_gss_krb5 module is not loaded

I cannot confirm the fix. Even when rpcsec_gss_krb5 *is* loaded, rpc-svcgssd.service still fails for Buster: root@srvl064:/etc# systemctl daemon-reload root@srvl064:/etc# systemctl restart rpc-svcgssd Job for rpc-svcgssd.service failed because the control process exited with error code. See

Bug#943939: kernel dump on switching off USB disk dockingstation

Package: linux-image-4.19.0-6-amd64 Version: 4.19.67-2+deb10u1 When I switched off my USB disk dockingstation (2 slots, 2 Sata disks were inserted) I got a kernel dump: Oct 31 16:26:44 dpcl082 kernel: [22985.418721] usb 6-2: USB disconnect, device number 2 Oct 31 16:26:44 dpcl082 kernel:

Bug#932408: linux-image-4.19.0-5-amd64: kernel panic not syncing

FYI: I had problems with linux-image-4.19.0-5-amd64, too, esp. on writing large amounts of data to an USB block device (USB-C). "sync" got stuck, umount didn't work, host became unresponsive, etc. Reset necessary. linux-image-4.19.0-6-amd64 (in proposed-updates) seems to work better. Regards

fsck on ext4: "WARN Wrong bounce buffer write length: 1024 != 0"

FYI: "fsck -y" on an external USB drive (USB-C, ext4) gave me a ton of messages : [ 191.261939] xhci_hcd :05:00.0: WARN Wrong bounce buffer write length: 1024 != 0 [ 191.263743] xhci_hcd :05:00.0: WARN Wrong bounce buffer write length: 1024 != 0 [ 191.263788] xhci_hcd :05:00.0:

new upstream version 4.19.63

Hi folks, since 4.19.37 there have been quite a number of new versions in upstream's linux-4.19.y branch. I have to support recent hardware for my Debian 9 systems, so I wonder what are your plans for buster and stretch-backports? Regards Harri

Bug#928328: Intel I350-NIC shuts down ports after loosing carrier

Are other Intel NICs affected by this problem as well? Regards Harri

RAID 1 problem with 4.19.16 bpo kernel

Hi folks, Using kernel 4.19.0-0.bpo.2-amd64 on Stretch I had 2 incidents in the past 3 weeks: The PC got stuck, apparently related to md and RAID1 (see the attached logfiles). I have installed 4.19.0-0.bpo.4-amd64 this morning. According to the changelog there were a few changes wrt md and raid

Re: Processing of linux_4.19.28-2~bpo9+1_multi.changes

Hi folks, On 3/30/19 5:47 AM, Debian FTP Masters wrote: linux_4.19.28-2~bpo9+1_multi.changes uploaded successfully to localhost along with the files: linux_4.19.28-2~bpo9+1.dsc linux_4.19.28-2~bpo9+1.debian.tar.xz linux_4.19.28-2~bpo9+1_source.buildinfo

Re: nf_conncount_destroy: general protection fault

Hi Ben, On 2/6/19 8:11 PM, Ben Hutchings wrote: Please open a bug against the version in sid. Done: https://bugs.debian.org/921616 Many thanx Harri

Bug#921616: nf_conncount_destroy: general protection fault

Package: linux-image-4.19.0-2-amd64 Version: 4.19.16-1 I am hit by a general protection fault in netfilter, see https://marc.info/?l=netfilter=154807599219095 . According to upstream the problem has been fixed in 4.19.17. Regards Harri

nf_conncount_destroy: general protection fault

Hi folks, I am hit by a general protection fault in the 4.19.12 backports kernel, see https://marc.info/?l=netfilter=154807599219095 . According to upstream it has been fixed for 4.19.17, which is not in Sid yet. AFAIR I am not allowed to post bug reports about backports. OTOH is is pretty

Buster: 4.19?

Hi folks, is it safe to assume that Buster goes with kernel 4.19.x? Regards Harri

Bug#720898: netinst cd on Haswell: No ethernet card detected

obsolete, please close

Bug#629905: NFS3 mounts are broken after upgrade squeeze --> testing

obsolete (AFAICT), please close

Re: Bug#898060: Stall NFS clients: RPC request reserved 84 but used 272

There were tons of messages, then the network went down. kernel.log: Jun 5 17:33:39 nasl006a kernel: [ 4624.059640] RPC request reserved 84 but used 268 Jun 5 17:33:39 nasl006a kernel: [ 4624.060169] RPC request reserved 84 but used 268 Jun 5 17:33:39 nasl006a kernel: [ 4624.060702] RPC

Bug#898060: Stall NFS clients: RPC request reserved 84 but used 272

metoo I have "rpc request reserved 84 but used 268", but I am not picky. Regards Harri

Re: linux_4.9.47-1.dsc proposed update for a *very* long time

:56 +0200 Ben Hutchings <b...@decadent.org.uk> wrote: > On Thu, 2017-09-28 at 16:50 +0200, Harald Dunkel wrote: > > Hi folks, > > > > what is the story behind linux_4.9.47-1.dsc that popped up > > in p-u on the ftp server more than 2 weeks ago? Looking at

4.9.0-0.bpo.3-amd64: unable to handle kernel paging request at 0000000045810f79

Hi folks, the backported kernel for Jessie (4.9.30-2+deb9u2~bpo8+1) gave me an error message: Oct 9 19:00:02 dpcl083 kernel: [981816.818862] BUG: unable to handle kernel paging request at 45810f79 Oct 9 19:00:02 dpcl083 kernel: [981816.818866] IP: [] __d_lookup+0x4f/0x130 Oct 9

linux_4.9.47-1.dsc proposed update for a *very* long time

Hi folks, what is the story behind linux_4.9.47-1.dsc that popped up in p-u on the ftp server more than 2 weeks ago? Looking at its changelog there are tons of interesting fixes inside. Should I upgrade? Or has it been obsoleted by 4.9.{48..52} in the meantime? Regards Harri

Bug#870598: lvm.conf

On Thu, 3 Aug 2017 11:17:04 + Daniel Sobe wrote: > Providing lvm.conf for both Debian 8 and Debian 9 as suggested. I'm not aware > of any modifications to them. > > I am not sure if this is your problem, but I would suggest to tell lvm2 to ignore the raw devices and

Bug#870694: rpc.svcgssd should silently exit

Package: nfs-common Version: 1:1.3.4-2.1 I am using NFS without Kerberos. Problem: Aug 4 10:32:53 il06 rpc.svcgssd[18935]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - No key table entry found matching nfs/@

Bug#870598: linux-image-4.9.0-3-amd64: DRBD regression from debian 8 to debian 9, SCSI errors in log and drbd going diskless

I would suggest to post /etc/lvm/lvm.conf as well. Regards Harri

Re: linux_4.9.30-2+deb9u2~bpo8+1_multi.changes ACCEPTED into jessie-backports->backports-policy, jessie-backports

Hi folks, What is the relationship between upstream's 4.9.x LTS series and the "regular" kernel in Stretch for x>30? Regards Harri

Re: Bug#864312: BUG: soft lockup - CPU#0 stuck for 22s!

I had a similar effect for kernel linux-image-4.8.0-0.bpo.2-amd64-unsigned (even though a reset on the front panel was sufficient to reboot). Some say this problem has been introduced by memory cgroups. Does this ring a bell? Are you using dockers or LXCs with cgroup_enable=memory ? Regards

Re: and conflict needs to be resolved for backports?

On 06/03/17 15:59, Ben Hutchings wrote: > On Sat, 2017-06-03 at 08:08 +0200, Harald Dunkel wrote: >> >> What would you suggest? > > I would suggest not using linux-libc-dev from jessie-backports. > This workaround is already known; see my first post in this thread. Regards Harri

Re: and conflict needs to be resolved for backports?

On 06/02/17 11:16, Ben Hutchings wrote: > On Thu, 2017-06-01 at 10:37 +0200, Harald Dunkel wrote: >> >> Workaround is to avoid the backports package, but I wonder if it would >> be possible to fix this? How comes that the fix for #822396 doesn't >> work for Jess

and conflict needs to be resolved for backports?

Hi folks, wrt #822396: Using the 4.9.25 backports linux-libc-dev for Jessie I still get the conflict between linux/if.h and net/if.h, e.g. on building strongswan 5.5.3 (see below). Workaround is to avoid the backports package, but I wonder if it would be possible to fix this? How comes that the

Bug#851119: memcg causing freezes on backports kernel

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Laurence, On 04/15/17 18:02, Laurence Parry wrote: > memory cgroups decreased the stability of 4.8, regardless of whether they > were actively being used; we were not actively using them, but still > experienced lockups. Disabling them on the

Re: linux_4.9.13-1~bpo8+1_amd64.changes is NEW

On 03/03/17 16:59, Ben Hutchings wrote: > On Fri, 2017-03-03 at 15:54 +, Ben Hutchings wrote: >> >> linux is still in NEW for all other architectures, and linux-latest and >> linux-signed are waiting for that. > > Actually, it just got accepted, so the other two can be uploaded. > I am

Re: linux_4.9.13-1~bpo8+1_amd64.changes is NEW

> > If you have any questions, you may reply to this email. > Is there a new linux-latest for bpo8 as well? Regards Harri

Re: Processing of linux_4.9.2-2~bpo8+1_amd64.changes

Hi Romain, On 01/31/17 08:35, Romain Francoise wrote: > > It is waiting for approval in the backports NEW queue, which you can > view here: > > https://ftp-master.debian.org/backports-new.html > The source package and some *.debs for arm showed up. Thanx very much Harri

Re: Processing of linux_4.9.2-2~bpo8+1_amd64.changes

Hi folks, On 01/27/17 12:48, Debian FTP Masters wrote: > linux_4.9.2-2~bpo8+1_amd64.changes uploaded successfully to localhost > along with the files: > linux_4.9.2-2~bpo8+1.dsc > linux_4.9.2-2~bpo8+1.debian.tar.xz : is it just me, or did this upload got lost somewhere? I highly appreciate

Bug#851119: memcg causing freezes on backports kernel

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Unfortunately some of the hosts affected most by this problem are LXC servers. They rely upon "cgroup_enable=memory swapaccount=1" on the kernel command line, making sure that I can start containers with memory restrictions. I have to make sure that

Re: vsyscall=none in backports kernel?

Hi Ben, On 01/02/17 14:28, Ben Hutchings wrote: > > It's probably dpkg in a wheezy (or earlier) chroot. > I checked, but all LXCs and Dockers were off. AFAICT it was some forgotten tool execed by /etc/cron.daily/dpkg. /usr/bin/dpkg appears to be innocent, and there are no other executables

vsyscall=none in backports kernel?

Hi folks, Running 4.8.11 from the backports repository for Jessie I found this in kern.log: Jan 1 03:00:53 dpcl082 kernel: [829504.082278] dpkg[24427] vsyscall attempted with vsyscall=none ip:ff600400 cs:33 sp:7fff8cb7c818 ax:ff600400 si:428720 di:7fff8cb7c830 Jan 1 03:00:53

Re: Uploading linux (4.8.15-1)

Hi folks, On 12/19/2016 01:58 PM, Salvatore Bonaccorso wrote: > Hi > > We intend to upload linux version 4.8.15-1 tonight or on Tuesday. > > The upload incorporates the upstream stable updates 4.8.12, 4.8.13, > 4.8.14 and 4.8.15 with various bugfixes and fixed vulnerabilities > (CVE-2016-8399,

Bug#848017: "unable to obtain root (machine) credentials" without gss/krb5i

Package: nfs-common Version: 1:1.2.8-9.2 rpc.svcgssd woes at boot time -- Unit rpc-svcgssd.service has begun starting up. Dec 13 10:04:07 dpcl064.ac.aixigo.de rpc.svcgssd[2019]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more

Bug#822575: debian regression: no more console output after "switching to mgag200drmfb from simple"

On 04/26/2016 04:05 PM, Ben Hutchings wrote: > > I'm guessing that you didn't built the mgag200 driver (CONFIG_DRM_MGA), > right? > Of course its in, as for the official kernel. % grep -i mga /boot/config-4.5.2 CONFIG_DRM_MGA=m CONFIG_DRM_MGAG200=m Would you suggest to

Bug#822575: debian regression: no more console output after "switching to mgag200drmfb from simple"

Without GRUB_GFXMODE and GRUB_GFXPAYLOAD_LINUX I get Apr 26 13:07:57 usbpc kernel: [ 18.245417] AES CTR mode by8 optimization enabled Apr 26 13:07:57 usbpc kernel: [ 18.256518] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) Apr 26 13:07:57 usbpc kernel: [ 18.271819] fbcon: mgadrmfb

Bug#822575: debian regression: no more console output after "switching to mgag200drmfb from simple"

We can focus on 4.5.1-1, even though the regression came up with 4.4.x.

Re: Bug#822575: debian regression: no more console output after "switching to mgag200drmfb from simple"

Without GRUB_GFXMODE and GRUB_GFXPAYLOAD_LINUX I get Apr 26 13:07:57 usbpc kernel: [ 18.245417] AES CTR mode by8 optimization enabled Apr 26 13:07:57 usbpc kernel: [ 18.256518] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) Apr 26 13:07:57 usbpc kernel: [ 18.271819] fbcon: mgadrmfb

Bug#812116: newly built initrd complains about missing init

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yup. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWoGOcAAoJEAqeKp5m04HLqk8H/RLH14ZPiDgZr1yHFCyiGEPY 46snYvavBNa2JBjYZXdwynHTRS9oWApYPTgSAdNYhYJ2Kjbr838hiH9V/5Wv030q yVofhD1bNm7sA1ynflMXdgvvDI8RemNRpmKflG7rRBeZfOHkDxgOXYiT0wNLaoDg

Bug#812116: newly built initrd complains about missing init

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: initramfs-tools Version: 0.121 If I boot the initrd generated by the new tools, then it exits at a busybox prompt, complaining that /bin/init cannot be found. Of course its there. Below are the diffs of lsinitramfs for old and new tools.

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

Bug#760818: orig file vs upstream

Package: linux Version: 3.14.15-2 How comes that linux_3.14.15.orig.tar.xz differs so much from upstream? I understand that some code has to be removed due to licensing restrictions, but shouldn't the remaining changes be included into the quilt set? Regards Harri -- To UNSUBSCRIBE, email to

Re: Uploading linux (3.16.2-1)

Since upstream provides longterm support for 3.14.x I wonder if 3.14.18 and its successors will make it into wheezy-backports? Of course I agree that Unstable should keep pace with the new kernel versions, but for Wheezy I would be highly interested in a reasonably modern longterm kernel. Thanx

Bug#726507: nfs4_reclaim_open_state: unhandled error -10026. Zeroing state

Package: linux-image-3.10-0.bpo.3-amd64 Version: 3.10.11-1~bpo70+1 NFSv4 on my client froze with nfs4_reclaim_open_state: unhandled error -10026. Zeroing state The server (running the same kernel) showed no incident at this time. By now I could not reproduce the problem, though. mount

Bug#578189: please move common headers to /usr/src/linux-headers-`uname -r`

Any news about this? Harri -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e25e9d.3020...@afaics.de

Bug#705579: please consider the kernel module dependencies

Package: initramfs-tools Version: 0.110 Severity: wishlist It would be very nice if mkinitramfs considers the kernel module dependencies when creating the initrd. /lib/modules/\ 3.8.?/modules.dep shows pretty clear that ehci-hcd depends upon ehci-pci, for example. See #700572. This would make

Bug#572339: [squeeze] WARNING at arch/x86/kernel/hpet.c:390 (Re: problem(?) with hpet at boot time)

Hi Jonathan, I've got a new PC in the meantime (running Squeeze and the 3.2.x backports kernel). I am sorry, but the old PC is running Testing now. AFAICS the problem doesn't come up with the 3.2.x kernel. From my side its OK to drop this bug report. Regards Harri -- To UNSUBSCRIBE, email

Bug#670417: backlight dimmed at initrd startup

Package: linux-image-2.6-amd64 Version: 3.2+44 On a Lenovo T420s laptop the screen backlight is dimmed from the power-on default to very low at boot time. This happens after Grub started the kernel and while the Loading initial ramdisk... is shown, but before all the usual hardware

Bug#664463: /conf/conf.d/cryptroot is missing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: initramfs-tools Version: 0.101 Hi folks, I am trying to setup an encrypted logical volume to hold the root filesystem and swap. Hardware a virtual PC created using kvm. Problem: There is no password dialog at boot time. After a minute

Bug#636797: followup on debian bug #636797

On 03/09/12 15:57, Ben Hutchings wrote: On Fri, 2012-03-09 at 13:30 +0100, Harald Dunkel wrote: PS: I just noticed that severity is set to normal. Sorry to say, but I disagree on the severity in this case. If our production environment dies after 200 days uptime, then this is fatal. Why do

Bug#636797: followup on debian bug #636797

Is this bug still relevant for Squeeze's kernel 2.6.32-41 ? Would you recommend to move to the debian-backports kernel instead? Any helpful comment would be highly appreciated. Harri -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble?

Bug#636797: followup on debian bug #636797

PS: I just noticed that severity is set to normal. Sorry to say, but I disagree on the severity in this case. If our production environment dies after 200 days uptime, then this is fatal. Would you mind to adjust the severity of this bug report? Many thanx Harri -- To UNSUBSCRIBE, email to

Bug#633526: vserver kernel breaks ssh public_key authentication on

Sorry for my bad English. Is there something I can do to improve the problem description? Harri -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Bug#633526: vserver kernel breaks ssh public_key authentication on NFS

Package: linux-image-2.6-vserver-amd64 Version: 2.6.32+29 If I use the vserver kernel on a remote host, then I cannot login via ssh and public_key authentication. AFAICS the access rights to my authorized_keys file get corrupted. Before I try to login it shows on the remote host: # ls -l

Bug#629905: NFS3 mounts are broken after upgrade squeeze -- testing

Package: nfs-common Version: 1:1.2.3-2 After the upgrade from squeeze to testing the NFS3 mounts are ignored at boot time. Instead I see a message rpcbind: Cannot open '/var/run/rpcbind/rpcbind.xdr' file for reading, errno 2 (No such file or directory) rpcbind: Cannot open

Bug#625811: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#625811: please don't drop support for Wheezy)

Hi Ben, Sorry, probably I missed the note about dropping Vserver. It seemed to be in wide use and under active development. Pretty disappointing for the Vserver folks, I would guess. Of course I can give lxc a try, but I am a little bit concerned that it might get dropped, too, as soon as the

Bug#625811: please don't drop support for Wheezy

Package: linux-image-2.6-vserver-amd64 Version: 2.6.32+29 Severity: wishlist Hi folks, Would it be possible to continue support for the Linux Vserver kernel in Wheezy? vserver and its kernel patches seems to be under active development. It would be far beyond average scope to apply these

Bug#624791: reiserfs woes on huge write session

On 05/01/11 19:07, Ben Hutchings wrote: That's not the whole of the message, is it? Yes, it is. Of course I googled for messages like this, but there wasn't much to find. Regards Harri -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe.

Bug#624791: reiserfs woes on huge write session

Package: linux-image-2.6.32-5-amd64 Version: 2.6.32-31 I've got a huge file server with about 3.5 TByte disk space (reiserfs), 64 GByte RAM and 2 quadcore CPUs. Trying to copy (rsync) about 2 TByte data to this disk it takes a few minutes, the load goes up to 6 or higher, then there is this

Bug#562737: seems to be back

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With the upgrade to nfs-common 1:1.2.3-1 this problem seems to be back. Using rpcbind instead of portmap (6.0.0-3) nfs-common starts cleanly. nfs-common version 1:1.2.2-5 + portmap didn't show this problem either. rpc.statd -dF shows (using portmap):

Bug#591320: /etc/modprobe.d/initramfs.conf is lost

Package: initramfs-tools Version: 0.97.2 Blacklisting modules on the kernel command line doesn't work. If I set blacklist=bluetooth (just as an example), then the bluetooth module is still loaded. AFAICS the generated /etc/modprobe.d/initramfs.conf is not written to the root file

Bug#591320: /etc/modprobe.d/initramfs.conf is lost

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is the intended behaviour. Is this documented somewhere? This restriction would make the blacklist feature pretty useless, doesn't it? As soon as udev is started in single user mode (using /etc/modprobe.d found on root filesystem) all the

Bug#591320: /etc/modprobe.d/initramfs.conf is lost

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/10 23:53, Ben Hutchings wrote: On Mon, Aug 02, 2010 at 11:14:43PM +0200, Harald Dunkel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is the intended behaviour. Is this documented somewhere? Not specifically

Bug#534417: move /var/lib/nfs/rpc_pipefs to /var/lib?

I am running this setup on 2 HA hosts since I created this bug report. The moved PIPEFS_MOUNTPOINT doesn't make any problems at all. Regards Harri -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#578189: please move common headers to /usr/src/linux-headers-`uname -r`

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: linux-headers-2.6.32-4-common Version: 2.6.32-11 Debian breaks compatibility to upstream's kernel source tree by splitting the header file directory tree into 2 parts. This affects 3rd party software, e.g. the makefiles included in Nvidia's

Bug#532276: nfs-kernel-server stop doesn't

On 04/05/10 23:09, Ben Hutchings wrote: nfsiod seems to be remain running, but I don't think that's a problem. Do you see any other processes or kernel threads running? This is ages old. I am running an upstream kernel now, which doesn't show this problem, except for the nfsiod. I think the

Bug#576641: Can't open /scripts/functions, no backup of initrd made

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: initramfs-tools Version: 0.94 Upgrade failed with Setting up initramfs-tools (0.94) ... Installing new version of config file /etc/kernel/postrm.d/initramfs-tools ... Installing new version of config file

Re: Bug#576641: Can't open /scripts/functions, no backup of initrd made

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/06/10 21:30, maximilian attems wrote: which version of mdadm are you running please post, output of dpkg -l mdadm It is mdadm 3.1.1-1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla -

Re: Bug#576641: Can't open /scripts/functions, no backup of initrd made

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/10 06:07, maximilian attems wrote: can't be the code of mdadm 3.1.1-1 can not produce such an error, but the experimental version 3.1.1-1+incremental+4 is faulty. After removing mdadm I got this: # dpkg -i initramfs-tools_0.94_all.deb

Bug#574758: dkms postinst script called before headers are set up

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: linux-image-2.6.32-4-amd64 Version: 2.6.32-10 It seems that /etc/kernel/postinst.d/dkms is called to rebuild additional kernel modules before the kernel headers are set up. Sample session: Setting up linux-image-2.6.32-4-amd64 (2.6.32-10)

Bug#572339: problem(?) with hpet at boot time

Same problem, as it seems: [ 18.521817] [ cut here ] [ 18.521823] WARNING: at /build/mattems-linux-2.6_2.6.32-9-amd64-NYTFdD/linux-2.6-2.6.32-9/debian/build/source_amd64_none/arch/x86/kernel/hpet.c:392 hpet_next_event+0x52/0x77() [ 18.521825] Hardware name: S3420GP

Bug#572339: problem(?) with hpet at boot time

On 03/04/10 16:19, maximilian attems wrote: thanks, please report upstream on bugzilla.kernel.org, provide full dmesg and oops and let us know the bug nr so that we can keep track of it. aboves linux image has latest 2.6.32.9 stable fixes. Seems to be known already:

  1   2   >