Control: retitle 673290 nfs-common: rpc.idmapd crashes when given -d
Control: merge 673290 624843
This has been fixed upstream a while ago:
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=df0f8ab7de8d4664ca3d97d71ff2ef80fae24cb4
rpc.idmapd: Remove no longer supported flags from
On 12/02/2015 04:30 PM, Elliott Mitchell wrote:
> You're thinking of the wrong bug. #588675 is the bug # for /proc/mounts
> having "/dev/root" listed as the device for the root filesystem. Your
Indeed, I think I confused this with #656333 ("Please ignore rootfs in
df output"), which may be
On 12/02/2015 01:23 PM, Elliott Mitchell wrote:
> Could you confirm a few things about what you've seen of bug 588675?
>
> Did you observe the behavior prior to Debian wheezy/Linux kernel 3.2?
>
> What type of disk/controller/disk subsystem is on your powerpc system?
>
> From your mention of
On Wed, 14 Aug 2013 at 21:29, Christian Kujau wrote:
On Wed, 14 Aug 2013 at 22:54, Dave Kleikamp wrote:
It looks like the problem is that jfs was using a cookie value of 2 for
a real directory entry, where NFSv4 expect 2 to represent ... This
patch has so far only been lightly tested
messages
and with unique inode numbers, great!
Tested-by: Christian Kujau li...@nerdbynature.de
Thanks for the fix!
Christian.
--
BOFH excuse #442:
Trojan horse ran out of hay
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Wed, 14 Aug 2013 at 22:54, Dave Kleikamp wrote:
It looks like the problem is that jfs was using a cookie value of 2 for
a real directory entry, where NFSv4 expect 2 to represent ... This
patch has so far only been lightly tested.
Hm, a first compile of 3.11-rc5 errors out with:
CC [M]
FWIW, this still happens when both client server are running Linux
3.11.0-rc5 (vanilla).
$ dpkg -l | grep nfs | cut -c-70
ii libnfsidmap2:amd64 0.25-4amd64
ii nfs-common 1:1.2.6-4 amd64
ii nfs-kernel-server
Sorry for the noise, here's another oddity, same setup (client server
running 3.11-rc5):
$ find /mnt/nfs/usr/share/ -name getopt.awk -ls
250724 -rw-r--r-- 1 root root 2237 Mar 16 04:46
/mnt/nfs/usr/share/awk/getopt.awk
250724 -rw-r--r-- 1 root root 2237
On Mon, 12 Aug 2013 at 12:29, J. Bruce Fields wrote:
It might be interesting to get a network trace (something like tcpdump
-s0 -wtmp.pcap; then wireshark tmp.pcap and look at the cookie
fields in the readdir calls and replies.
I've created #60737[0] to track this issue upstream and attached a
Interesting stuff. Out of curiosity I just tried this myself, both client
server are virtual machines running Debian/stable (3.2.0-4-amd64) and I
was able to reproduce this. A test case would be:
## server:
$ apt-get install nfs-kernel-server jfsutils
$ dd if=/dev/zero bs=1M count=256
FWIW, this happens on a different machine too: Debian/wheezy, just
upgraded from sqeeze, but this time in a VMware virtual machine:
[ cut here ]
WARNING: at
/build/buildd-linux_3.2.41-2+deb7u2-i386-G4jjsr/linux-3.2.41/drivers/cpuidle/driver.c:87
Package: src:linux
Version: 3.2.41-2
Severity: normal
Dear Maintainer,
after upgrading from squeeze to wheezy in this VirtualBox VM, the following is
printed
during every bootup:
[ cut here ]
WARNING: at
Package: linux-image-powerpc
Version: 2.6.26+17+lenny1
Severity: important
Please enable CONFIG_EFI_PARTITION in the kernel config. This has been
discussed and fixed for i386 and amd64 in #281905 (for 2.6.8, 2.6.10) but
linux-image-powerpc still ships with CONFIG_EFI_PARTITION unset:
$ grep
Just for the record: gcc-4.3 still fails on a current vanilla kernel with
the same message:
http://nerdbynature.de/bits/2.6.25-git/
(gcc 4.3-20080227-1 with today's 2.6.25-git)
Adding -fno-tree-scev-cprop to KBUILD_CFLAGS did not succeed, the build
fails instantly, please see
hi again,
sorry for the delay, but the bug triggers only when the remote peer
disconnects me - and it does it only once a day.
Marco d'Itri wrote:
reassign 299875 kernel
retitle 299875 CAN-2005-0384: Remote Linux DoS on ppp servers
tag 299875 patch security
yes, it really looks like a pppd
Justin Pryzby wrote:
I assume that you have seen this:
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.4
yes i have*now*. obviously this was a security issue (CAN-2005-0384)
and i *guess* that's why the issue was not discussed in public. what pity
and what a waste of time in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi list,
yesterday i encounterd several oopses with my server. the subject of
this mail is just plain saying that it is all 2.6.8-rc4's fault. the
reality however turned out to be much more complex and confusing so i
try to recapitulate in a
17 matches
Mail list logo
