Bug#616560: umountfs: nothing to unmount if / is on UBI volume
Package: initscripts Version: 2.88dsf-13.1 Severity: important If you have / on UBIFS, named as something with ubi0:xxx, the script /etc/init.d/umountfs has nothing to unmount. Here is a sample /proc/mounts: rootfs / rootfs rw 0 0 none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 none /proc proc rw,nosuid,nodev,noexec,relatime 0 0 none /dev devtmpfs rw,relatime,size=254952k,nr_inodes=63738,mode=755 0 0 none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 ubi0:rootfs / ubifs ro,noatime 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0 varrun /var/run tmpfs rw,nosuid,relatime,mode=755 0 0 varlock /var/lock tmpfs rw,nosuid,nodev,noexec,relatime 0 0 /dev/mmcblk0p3 /var ext2 rw,noatime,errors=continue 0 0 tmpfs /tmp tmpfs rw,relatime 0 0 As you can see, there is / on ubi0:rootfs. There is a regexp in /etc/init.d/umountfs which lists the protected mounts (mountpoints that needs to be kept mounted for the moment). If / is not on something named like /abc.../xyz, the regexp returns all the mountpoints in /proc/mounts. Here is the regexp (line 22): PROTECTED_MOUNTS=$(sed -n '0,/^\/[^ ]* \/ /p' /proc/mounts) You can modify it with something like the following and then it works ! PROTECTED_MOUNTS=$(sed -n '0,/^\/\|^ubi[^ ]* \/ /p' /proc/mounts) But I am not sure that it is a standard way of finding the / mountpoint ! As a countermeasure, I've tried to use a more standard name for the UBIFS device (like /dev/ubi0_0) but when passing this name to the kernel at boot (via root=/dev/ubi0_0s rootfstype=ubifs ), kernel can't find root. Hardware is a Sheevaplug... reportbug is not installed on this computer so the kernel line is not the good one (2.3.32-5, squeeze kernel). -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.35-trunk-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initscripts depends on: ii coreutils 8.5-1GNU core utilities ii debianutils 3.4 Miscellaneous utilities specific t ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii mount 2.17.2-9 Tools for mounting and manipulatin ii sysv-rc 2.88dsf-13.1 System-V-like runlevel change mech ii sysvinit-utils 2.88dsf-13.1 System-V-like utilities Versions of packages initscripts recommends: ii e2fsprogs 1.41.12-2 ext2/ext3/ext4 file system utiliti ii psmisc22.11-1utilities that use the proc file s initscripts suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593243: Fixed in 2.6.32-5-29
Hello, the bug seems to be fixed with 2.6.32-29... Now, I've got no problem for connecting to WPA2 APs with this kernel. The module named rt2860sta works very well. I don't know where was the bug from, but it seems to work well under Squeeze... Good job ! -- Médéric RIBREUX email: mederic.ribr...@gmail.com blog: http://medspx.homelinux.org/blog -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593243: It works with experimental linux-image...
Hello, I have just found the time to try the experimental module which has been renamed rt2800pci in the 2.6.35-1~experimental.3 version of the linux-image-2.6.35-trunk-686 packet (actually, I am using this module to send this message, so it seems to work pretty well). I also take some extra time to test the linux-image-2.6.32-5 (2.6.32-21) and under this version it still doesn't work at all. I don't have the time nor the skills to inspect the code but I can make extended tests if someone wants to guide me. I'm quite surprised to see that this bug seems to only affect few wireless configurations (mine is Ralink on EeeBox with a WPA2 AP). I hope it can be fixed for Squeeze release... -- Médéric RIBREUX email: mederic.ribr...@gmail.com blog: http://medspx.homelinux.org/blog -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593243: linux-image-2.6.32-5-686: WPA2 is not available anymore with rt2860sta (open networks work), upstream driver works too
Package: linux-2.6 Version: 2.6.32-20 Severity: important Since linux-2.6.32-18, the rt2860sta wifi driver is not able to associate against WPA/WPA2 AP with wpa_supplicant. I guess that the problem is linked to bug #574766. After the update from linux-image-2.6.32-5-686 2.6.32-17 to 2.6.32-18, the wpa stops working (nothing has been changed in the config files). It seems that wpa_supplicant can't associate with the AP even if its configuration is good. With open network, it works. This does not comes from a problem of binary firmware as linux-ralink is installed on my computer. Since the failure, the only thing related to wifi that has changed on my system is the kernel and its modules. All the other packets (wpasupplicant, wireless-tools, firmware-ralink) haven't been modified or updated. I tried to use the rt2860-source package but it won't compile at all ! Then, as a workaround, I manually compiled the upstream driver (v2.4.0) and the WPA connexion with wpa_supplicant works really well. I tried to use the sid version of the image (2.6.32-20) but it doesn't work too. I guess that the problem is in the modifications of the rt2860sta module... -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-20) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Thu Aug 12 13:38:27 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=42434b27-e2b8-4029-b098-6d884820a7bb ro quiet ** Not tainted ** Kernel log: [ 4188.005914] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 863 [ 4199.129935] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 1094 [ 4206.149935] ===rt_ioctl_giwscan. 6(6) BSS returned, data-length = 725 [ 4215.169883] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 862 [ 4225.185939] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 862 [ 4235.609913] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1104 [ 4243.721919] ===rt_ioctl_giwscan. 6(6) BSS returned, data-length = 725 [ 4250.837923] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 862 [ 4258.853937] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 888 [ 4263.753933] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 862 [ 4273.081949] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1126 [ 4281.302956] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 988 [ 4286.197937] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 1000 [ 4295.421936] ===rt_ioctl_giwscan. 5(5) BSS returned, data-length = 613 [ 4366.625865] ===rt_ioctl_giwscan. 6(6) BSS returned, data-length = 725 [ 4370.529931] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1093 [ 4380.365964] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 1095 [ 4384.269921] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1199 [ 4388.285909] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 829 [ 4398.309875] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1199 [ 4402.213935] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1199 [ 4406.221937] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1104 [ 4410.233929] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 862 [ 4415.241921] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1232 [ 4419.253919] ===rt_ioctl_giwscan. 6(6) BSS returned, data-length = 725 [ 4423.265932] ===rt_ioctl_giwscan. 10(10) BSS returned, data-length = 1219 [ 4427.281932] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 967 [ 4431.289897] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 1095 [ 4440.113944] ===rt_ioctl_giwscan. 10(10) BSS returned, data-length = 1336 [ .017939] ===rt_ioctl_giwscan. 10(10) BSS returned, data-length = 1325 [ 4449.025930] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1199 [ 4453.037940] ===rt_ioctl_giwscan. 6(6) BSS returned, data-length = 725 [ 4457.049939] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1199 [ 4461.069865] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 1094 [ 4482.001941] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1199 [ 4486.905935] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1093 [ 4490.913857] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 862 [ 4494.925926] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 1000 [ 4498.937930] ===rt_ioctl_giwscan. 7(7) BSS returned, data-length = 957 [ 4502.949933] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1232 [ 4506.961937] ===rt_ioctl_giwscan. 10(10) BSS returned, data-length = 1336 [ 4510.973935] ===rt_ioctl_giwscan. 10(10) BSS returned, data-length = 1336 [ 4514.989931] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 1000 [ 4518.997935] ===rt_ioctl_giwscan. 9(9) BSS returned, data-length = 1104 [ 4523.009859] ===rt_ioctl_giwscan. 10(10) BSS returned, data-length = 1336 [ 4527.025931] ===rt_ioctl_giwscan. 8(8) BSS returned, data-length = 1122 [ 4532.033927] ===rt_ioctl_giwscan. 10(10) BSS returned, data-length = 1336 [ 4536.045921]
Bug#500129: no change with smbclient 3.2.4-1
Hi, The bug is still here with a sid version of smbclient 3.2.4-1 (and same version of samba-common)... My hardware is a 320Gb Iomega Home drive with the latest firmware (K1.08 L1.0 W1.5) and i've got the same problems as described above: cli_list_new: Error: unable to parse name from info level 1. The result is the same wether the directory is empty or not and it only happens with a ls/dir-like command... I guess this hardware is buggy ?? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
