[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#453747: marked as done (linux-image-2.6.18-5-amd64: inconsistent RPC record marking prevents nfsroot from Solaris NFS server)

Your message dated Mon, 15 Feb 2010 20:18:14 +0100
with message-id <20100215191814.GN9624@baikonur.stro.at>
and subject line Re: Xen || vserver troubles
has caused the Debian Bug report #453747,
regarding linux-image-2.6.18-5-amd64: inconsistent RPC record marking prevents nfsroot from Solaris NFS server
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
453747: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453747
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-2.6.18-5-amd64
Version: 2.6.18.dfsg.1-13etch4
Severity: normal

*** Please type your report below this line ***
While trying to network boot Debian 2.6.18-5-amd64 kernel and mounting
root from an OpenSolaris NFS server boot process hangs like that:
...
Begin: Running /scripts/nfs-premount ...
Done.
<hangs here>

Looking at the network stream with tshark reveals that the RPC request
to server's portmapper is malformed: RPC fragment header states
incorrect fragment size - 4 bytes more. The malformed request never
gets answered by Sun's rpcbind and thus boot process halts.

The RPC request sent looks like this (Ethernet addresses masked out):
0000  ** ** ** ** ** ** ** ** ** ** ** ** 08 00 45 00 ************..E.
0010  00 70 9d a5 40 00 40 06 85 dc 0a 01 01 0b 0a 01 .p..@.@.........
0020  01 fa ad e2 00 6f 5e 6b 77 02 e2 5b 3d 3d 80 18 .....o^kw..[==..
0030  00 2e db ed 00 00 01 01 08 0a ff fe ea a4 20 87 .............. .
0040  d1 46 80 00 00 3c ff e1 76 18 00 00 00 00 00 00 .F...<..v.......
            ^^^^^^^^^^^
0050  00 02 00 01 86 a0 00 00 00 02 00 00 00 03 00 00 ................
0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................
0070  86 a3 00 00 00 03 00 00 00 06 00 00 00 00 f1 af ................
0080  86 4e

The last four bytes (0xf1af864e) are Ethernet trailer and are NOT part
of the TCP payload.

RPC packet analysis:
Remote Procedure Call, Type:Call XID:0xffe17618
    Fragment header: Last fragment, 60 bytes <-- WRONG!
    XID: 0xffe17618 (4292965912)
    Message Type: Call (0)
    RPC Version: 2
    Program: Portmap (100000)
    Program Version: 2
    Procedure: GETPORT (3)
    Credentials
        Flavor: AUTH_NULL (0)
        Length: 0
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0
Portmap GETPORT Call NFS(100003) Version:3 TCP
    [Program Version: 2]
    [V2 Procedure: GETPROT (3)]
    Program: NFS (100003)
    Version: 3
    Proto: TCP (6)
    Port: 0

RPC header (dword at 0x42) states frament size of 0x3c (60) bytes but
fragment is only 0x38 (56) bytes in length.

I've checked with Ubuntu's 2.6.17-12-generic, 2.6.17-10-server and
2.6.22-14-server - they issue RPCs with correct fragment size and are
able to talk to Sun's rpcbind. 2.6.17 calls DUMP while 2.6.2 calls
GETPORT (as 2.6.18 does) with correct fragment size of 56 bytes.

This bug does not shows up when using Linux NFS server since Linux
portmap DOES respond to such malformed RPC requests.

I'm using stock 2.6.18-5-amd64 from Debian Etch 4.0.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

--- End Message ---
--- Begin Message --- 
the 2.6.18 linux images from Etch are no longer supported, thus closing
this bug report.  As both Xen or vserver stayed out of tree it is very
unlikely that they improved a lot since.

With modern hardware kvm or lxc (linux containers) are recommended.
if you still haven't upgraded to Lenny please notice that Etch has
no security support any more as of today:
http://www.debian.org/News/2010/20100121


if you can reproduce said bugs with 2.6.32 linux images from
unstable please shout on said box and bug can be reopened:
reportbug -N <bugnr>

thank you for your report.

--- End Message ---
Reply to: