Ok... got it reproduced on 2.6.18.dfsg.1-13etch4: What I just did: - bootstrap a new lenny domU, run it with kernel 2.6.18-xen-amd64 (2.6.18.dfsg.1-13etch4) - install libfuse2 and fuse-utils 2.7.0-2 (from snapshot.debian.net) - create a user account, add it to the fuse group, load fuse module etc - log in as the new regular user - create a sshfs mount to another host - actually *use* the mount - important!! - just open a random textfile with less or whatever, but cd into it and do something there... - as root: apt-get upgrade the fuse stuff to 2.7.0-3
fuse:~# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: fuse-utils libfuse2 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/140kB of archives. After unpacking 0B of additional disk space will be used. Do you want to continue [Y/n]? (Reading database ... 10096 files and directories currently installed.) Preparing to replace fuse-utils 2.7.0-2 (using .../fuse-utils_2.7.0-3_amd64.deb) ... Unpacking replacement fuse-utils ... Preparing to replace libfuse2 2.7.0-2 (using .../libfuse2_2.7.0-3_amd64.deb) ... Unpacking replacement libfuse2 ... Setting up libfuse2 (2.7.0-3) ... Setting up fuse-utils (2.7.0-3) ... creating fuse device node... udev active, devices will be created in /dev/.static/dev/ creating fuse group... /etc/init.d/fuse: line 30: 3985 Segmentation fault mount -t fusectl fusectl $MOUNTPOINT >/dev/null 2>&1 Message from [EMAIL PROTECTED] at Tue Oct 30 21:20:37 2007 ... fuse kernel: invalid opcode: 0000 [1] SMP fuse:~# /var/log/syslog shows the same error with call trace: Oct 30 21:20:37 fuse kernel: ----------- [cut here ] --------- [please bite here ] --------- Oct 30 21:20:37 fuse kernel: Kernel BUG at fs/fuse/control.c:82 Oct 30 21:20:37 fuse kernel: invalid opcode: 0000 [1] SMP Oct 30 21:20:37 fuse kernel: CPU 1 [..snip..] fusermount -u hangs when the user tries to umount the sshfs mount. A system halt executed by root hangs... fuse:~# halt Broadcast message from [EMAIL PROTECTED] (pts/0) (Tue Oct 30 21:23:21 2007): The system is going down for system halt NOW! logging in with xm console shows a /bin/umount -i /path/to/sshfsmount that's blocking: 4393 pts/1 D 0:00 /bin/umount -i /path/to/sshfsmount 4998 pts/0 D+ 0:00 shutdown -h 0 w I cannot kill dash nine or do anything to stop this process 4393... So I have to do a xm destroy from the dom0. When the sshfs mount I made was not in use upgrading libfuse/fuse-utils went just fine, and afterwards the sshfs mount was gone, so I guess it was umounted during the fuse upgrade. I guess there's a pointer to what is going wrong actually? Now... let's try 2.6.18.dfsg.1-16: What I did: - install the linux-image/modules 2.6.18.dfsg.1-16_amd64.deb in dom0 - install the linux-modules 2.6.18.dfsg.1-16_amd64.deb in the domU - install fuse-foobar 2.7.0-2 again in the domU - start the domU with kernel 2.6.18.dfsg.1-16 - log in as the existing regular user - create a sshfs mount to another host - actually *use* the mount; just open a random textfile with less or whatever, but cd into it and do something there... - as root: apt-get upgrade the fuse stuff to 2.7.0-3 fuse:~# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: fuse-utils libfuse2 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/140kB of archives. After unpacking 0B of additional disk space will be used. Do you want to continue [Y/n]? (Reading database ... 10097 files and directories currently installed.) Preparing to replace fuse-utils 2.7.0-2 (using .../fuse-utils_2.7.0-3_amd64.deb) ... Unpacking replacement fuse-utils ... Preparing to replace libfuse2 2.7.0-2 (using .../libfuse2_2.7.0-3_amd64.deb) ... Unpacking replacement libfuse2 ... Setting up libfuse2 (2.7.0-3) ... Setting up fuse-utils (2.7.0-3) ... creating fuse device node... udev active, devices will be created in /dev/.static/dev/ creating fuse group... fuse:~# Looks good... Let's see what happened to the mount? fuse:~# mount | grep sshfs [EMAIL PROTECTED]:/home/knorrie on /home/knorrie/bla type fuse (rw,nosuid,nodev,max_read=65536,user=knorrie) It still exists... The other session where this user was accessing a file on the remote mounted system still responds... It seems the existing mount was not touched. So... It seems 2.6.18.dfsg.1-16 fixes this issue, like you suggested. Perhaps you can shed some light on what exactly was the issue? :) Perhaps just installing and re-installing 2.7.0-3 over again would trigger the same situation, but I did choose to reproduce it in a way it was most like how things went yesterday. Have fun, Hans van Kranenburg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
