Bug report: cfs on amd64 mounts but doesn't work
Hi, Following my previous messages to the list I had to report the problem stated below as a bug. Thank you very much to everyone who helped on this issue. Sergio. - Forwarded message from Sergio Mendoza <[EMAIL PROTECTED]> - From: Sergio Mendoza <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: cfs on amd64 mounts but doesn't work Reply-To: [EMAIL PROTECTED] X-Scanner: exiscan *1GVzuS-0007zA-00*9wN5/fPg/mE* X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on mail.astroscu.unam.mx X-Spam-Level: X-Spam-Status: No, score=0.1 required=10.0 tests=FORGED_RCVD_HELO autolearn=failed version=3.0.3 Package: cfs Version: 1.4.1-17 Severity: normal Hi, This bug is amd64 specific. It works fine on 32-bit machines. It has been discussed on debian-amd64 mailing lists: (a) http://lists.debian.org/debian-amd64/2005/07/msg00300.html (b) http://lists.debian.org/debian-amd64/2006/09/msg00338.html Briefly the problem is as follows: $ cmkdir directory Key: Again: $ ls directory $ cfssh directory/ Key: Directory is /var/cfs/.13687.31869 $ ls ls: reading directory .: Input/output error $ echo "Hello world" > test.txt $ cat test.txt Hello world $ echo * * So, as you can see it is possible to read the files, however ls or "echo *" doesn't list the directory contents. Even "ls ./" and related commands will not work. By trying many things I discovered that it is possible to read the contents of the directory by performing the following trick: $ cmkdir directory Key: Again: $ ls directory $ cfssh directory/ Key: Directory is /var/cfs/.13687.31869 $ ls ls: reading directory .: Input/output error $ mkdirhier a/a $ cd a/a/ $ ls $ echo "Hello world" > test.txt $ ls test.txt $ cat test.txt Hello world $ echo * test.txt This is indeed very strange. I can't tell where the error is but my guess is that somehow cfsd is not communicating properly with the nfs daemon. Please note that as far as I am concerned this is an AMD64 only problem. I run cfs on i386 and works perfect! Regards, Sergio. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-amd64 Locale: LANG=C, LC_CTYPE=es_MX (charmap=ISO-8859-1) Versions of packages cfs depends on: ii libc62.3.6.ds1-5 GNU C Library: Shared libraries ii nfs-kernel-server1:1.0.10-1 Kernel NFS server support cfs recommends no packages. -- no debconf information - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: em64t
On Fri, Oct 06, 2006 at 01:34:47PM -0700, Enrique Morfin wrote: > I'm using etch with kernel 2.6.15-1-em64t-p4-smp. > > I want to upgrade the kernel, but the images are: > > linux-image-2.6.17-2-amd64 > > is no smp? or using "smp-alternatives"? > > What about em64t? > > Thanks. As of 2.6.17-9 amd64 only has one flavour, and always supports smp as far as I understand it. Changelog entry: * [amd64] Add smp-alternatives backport. * [amd64] Drop smp flavours. * [amd64] Merge k8 and p4 flavours into a generic one, following upstreams advice. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
em64t
Hi! I'm using etch with kernel 2.6.15-1-em64t-p4-smp. I want to upgrade the kernel, but the images are: linux-image-2.6.17-2-amd64 is no smp? or using "smp-alternatives"? What about em64t? Thanks. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
em64t
Hi! I'm using etch with kernel 2.6.15-1-em64t-p4-smp. I want to upgrade the kernel, but the images are: linux-image-2.6.17-2-amd64 is no smp? or using "smp-alternatives"? What about em64t? Thanks. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] *still* refuses mail
On Fri, Oct 06, 2006 at 12:14:24PM -0400, Aaron M. Ucko wrote: > Even though the amd64 port's been official for half a year, mail to > [EMAIL PROTECTED] continues to bounce, as shown below. I know, and there is little I can do about it. > Meanwhile, could somebody please requeue acl2? Rescheduled. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] *still* refuses mail
Even though the amd64 port's been official for half a year, mail to [EMAIL PROTECTED] continues to bounce, as shown below. Meanwhile, could somebody please requeue acl2? --- Begin Message --- The original message was received at Fri, 6 Oct 2006 10:20:09 -0400 (EDT) >From OUTGOING-AUTH.MIT.EDU [18.7.22.103] - The following addresses had permanent fatal errors - <[EMAIL PROTECTED]> (reason: 550 unknown user) - Transcript of session follows - ... while talking to raff.debian.org.: >>> DATA <<< 550 unknown user 550 5.1.1 <[EMAIL PROTECTED]>... User unknown <<< 503 valid RCPT command must precede DATA Reporting-MTA: dns; biscayne-one-station.mit.edu Received-From-MTA: DNS; OUTGOING-AUTH.MIT.EDU Arrival-Date: Fri, 6 Oct 2006 10:20:09 -0400 (EDT) Final-Recipient: RFC822; amd64@buildd.debian.org Action: failed Status: 5.1.1 Remote-MTA: DNS; raff.debian.org Diagnostic-Code: SMTP; 550 unknown user Last-Attempt-Date: Fri, 6 Oct 2006 10:20:12 -0400 (EDT) Final-Recipient: RFC822; camm@enhanced.com Action: failed Status: 5.0.0 Diagnostic-Code: SMTP; 550 Sender Host Address is listed in bl.spamcop.net Last-Attempt-Date: Fri, 6 Oct 2006 10:20:15 -0400 (EDT) --- Begin Message --- Camm Maguire <[EMAIL PROTECTED]> writes: > Greetings, and thanks! I agree, have been unable to reproduce by > hand. Is there any way I can requeue a package as an ordinary > developer, or must such requests be handled manually via email request > to the buildd admins? I've always been a bit frustrated by this, as > the only sure fire way I have to awake the autobuilders to to upload a > new version, which of course burdens all arches equally. AFAIK, ordinary developers do not have the power to requeue even their own packages; you need to ask a buildd maintainer or (IIRC) a member of the release team (or else upload a build yourself if you have access to a suitable machine). Anyway, I believe I arranged for the amd64 buildd admins to get a copy of my previous message, but I'm explicitly copying them now just in case. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. --- End Message --- --- End Message ---
