Bug#767624: qemu-kvm: Package bridge-utils is autoremoved after system update
2014-11-02 12:41 GMT+01:00 Michael Tokarev m...@tls.msk.ru: Obviuously not an operator error. There has been a dependency for bridge-utils in the past, that depency has now been removed which causes apt to mark bridge-utils as not needed when it clearly still is in use, as it was on my installation. So what do you suggest? To keep old and long obsolete dependencies as dependencies forever? I suggest that changes to packages that could break networking are at least documented. I have checked the changelog for qemu-kvm and I can't find any reference to bridge-utils being removed. There wasn't any info in listed changes during the upgrade either. The only way to get the machine back on the network was to log on locally on the console. Not exactly an ideal situation if the machine is in a different location. A rule of thumb is to see which packages are being removed by autoremove, and verify if you still use any of them. Or just don't use autoremove (it is not enabled by default). It was an old machine with a lot of updates being applied, the autoremove list was 92 packages long. Easy to miss a dependency package that you haven't manually installed. It could have been automatically replaced by a compatible package, how should I know that autoremove would break my system? If you still disagree, please start discussion on debian-users or open a bug against linux-general package. Because this is how debian packaging system has always worked and - hopefully - will continue working. It is not in any way a bug in qemu, quite the contrary - it'd be a bug in qemu if it still listed bridge-utils in dependencies while this package is actually not used by it anymore. I consider not documenting the removal of a dependency - leading to a possible removal of a package that could break networking - a bug. What you do with the filed bug is up to you. /Daniel
Bug#767624: qemu-kvm: Package bridge-utils is autoremoved after system update
Package: qemu-kvm Version: 2.1+dfsg-5+b1 Severity: important Dear Maintainer, * What led up to the situation? I updated my Jessie system. * What exactly did you do (or not do) that was effective (or ineffective)? Had to remove bridge information from /etc/network/interfaces. * What was the outcome of this action? Restored network access. After updating the system (upgrade and dist-upgrade) and a reboot, bridge-utils (and many other packages) were removed by autoremove. After reboot the network no longer worked. Manually removed bridge informaton from /etc/network/interfaces, got the network running again and reinstalled bridge-utils, which solved the problem. The problem is not caused by bridge-utils, it is caused by the erroneous removal of bridge-utils by apt-get autoremove. I have qemu-kvm and related packages installed, there seems to be a missing dependency. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu-kvm depends on: ii qemu-system-x86 2.1+dfsg-5+b1 qemu-kvm recommends no packages. qemu-kvm suggests no packages. -- no debconf information Start-Date: 2014-11-01 14:06:53 Commandline: /usr/bin/apt-get dist-upgrade Install: libqt5script5:amd64 (5.3.2+dfsg-2, automatic), libxkbcommon-x11-0:amd64 (0.4.3-2, automatic), libwinpr-thread0.1:amd64 (1.1.0~git20140921.1.440916e+dfsg1-2+b1, automatic), libjsr305-java:amd64 (0.1~+svn49-4, automatic), liblog-message-perl:amd64 (0.8-1, automatic), libavformat56:amd64 (2.4.2-dmo2, automatic), libkblog4:amd64 (4.14.2-1, automatic), libvirt-daemon:amd64 (1.2.9-3, automatic), libqt5concurrent5:amd64 (5.3.2+dfsg-4+b1, automatic), geoclue-2.0:amd64 (2.1.8-1, automatic), libmspub-0.1-1:amd64 (0.1.1-2, automatic), qtserialport5-doc:amd64 (5.3.2-2, automatic), libavresample2:amd64 (2.4.2-dmo2, automatic), python-ipaddr:amd64 (2.1.11-2, automatic), libblas-common:amd64 (1.2.20110419-10, automatic), python-cffi:amd64 (0.8.6-1, automatic), qtdeclarative5-dev-tools:amd64 (5.3.2-4, automatic), libguava-java:amd64 (17.0-1, automatic), xdg-user-dirs:amd64 (0.15-2, automatic), libparams-util-perl:amd64 (1.07-2+b1, automatic), libfreerdp-client1.1:amd64 (1.1.0~git20140921.1. 440916e+dfsg1-2+b1, automatic), kdepim-kresources:amd64 (4.14.1-1, automatic), libavfilter5:amd64 (2.4.2-dmo2, automatic), qtwebkit5-examples-doc:amd64 (5.3.2+dfsg-2, automatic), libokularcore5:amd64 (4.14.1-1+b1, automatic), libwinpr-utils0.1:amd64 (1.1.0~git20140921.1.440916e+dfsg1-2+b1, automatic), libwpg-0.3-3:amd64 (0.3.0-3, automatic), libisc-export95:amd64 (9.9.5.dfsg-4.3, automatic), libqt5declarative5:amd64 (5.3.2-3, automatic), libfreerdp-core1.1:amd64 (1.1.0~git20140921.1.440916e+dfsg1-2+b1, automatic), qtquick1-5-dev-tools:amd64 (5.3.2-3, automatic), gir1.2-gtk-vnc-2.0:amd64 (0.5.3-1.3, automatic), qtenginio5-doc:amd64 (5.3.2-2, automatic), libasm4-java:amd64 (5.0.3-1, automatic), libappindicator1:amd64 (0.4.92-3, automatic), libkdcraw23:amd64 (4.14.0-1, automatic), libmbim-glib4:amd64 (1.10.0-2, automatic), libwinpr-synch0.1:amd64 (1.1.0~git20140921.1.440916e+dfsg1-2+b1, automatic), gir1.2-spice-client-glib-2.0:amd64 (0.25-1+b1, automatic), libbalooxapian4:amd64 (4.14.2 -1, automatic), linux-image-3.16-3-amd64:amd64 (3.16.5-1, automatic), libqt5sql5-sqlite:amd64 (5.3.2+dfsg-4+b1, automatic), libexiv2-13:amd64 (0.24-4, automatic), liblognorm1:amd64 (1.0.1-3, automatic), libwinpr-pool0.1:amd64 (1.1.0~git20140921.1.440916e+dfsg1-2+b1, automatic), libwebpmux1:amd64 (0.4.1-1.2+b2, automatic), libmwaw-0.3-3:amd64 (0.3.1-2, automatic), libvisio-0.1-1:amd64 (0.1.0-2, automatic), libx265-31:amd64 (1.3-dmo1, automatic), qt5-doc:amd64 (5.3.2-3, automatic), python-defusedxml:amd64 (0.4.1-2, automatic), qtbase5-doc:amd64 (5.3.2-3, automatic), libepoxy0:amd64 (1.2-1, automatic), libjim0.75:amd64 (0.75-1, automatic), python-wxgtk3.0:amd64 (3.0.1.1+dfsg-2, automatic), python-pyasn1-modules:amd64 (0.0.5-0.1, automatic), libbalooqueryparser4:amd64 (4.14.2-1, automatic), libzip2:amd64 (0.11.2-1.1, automatic), libqt5opengl5:amd64 (5.3.2+dfsg-4+b1, automatic), python-pycparser:amd64 (2.10+dfsg-3, automatic), qml-module-qtquick-layouts:amd64 (5.3.2-2, automatic), libwin pr-handle0.1:amd64 (1.1.0~git20140921.1.440916e+dfsg1-2+b1, automatic), libindicator7:amd64 (0.5.0-2, automatic), libwinpr-crt0.1:amd64 (1.1.0~git20140921.1.440916e+dfsg1-2+b1, automatic), qtsvg5-doc:amd64 (5.3.2-2, automatic), libass5:amd64 (0.10.2-3, automatic), libmbim-proxy:amd64 (1.10.0-2, automatic), libvlccore8:amd64 (2.2.0~pre4-dmo4, automatic), libxen-4.4:amd64 (4.4.1-3, automatic), libwebpdemux1:amd64 (0.4.1-1.2+b2, automatic), libfreerdp-cache1.1:amd64
Bug#745061: libdrm2: [drm] stuck on render ring
Looks like this has been resolved by some update, no hangs for a few weeks. Don't know what the problem was, but the last [drm] stuck on render ring entry in the logs is from april 27th: Apr 27 09:23:53 chieftec kernel: [60145.969920] [drm] stuck on render ring Apts history log for the 27th contains these upgrades: Start-Date: 2014-04-27 06:32:28 Commandline: /usr/bin/apt-get upgrade Upgrade: python-samba:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), winbind:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), samba:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), xserver-xorg-core:amd64 (1.15.0.901-1, 1.15.1-1), samba-dsdb-modules:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), libnss-winbind:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), xserver-common:amd64 (1.15.0.901-1, 1.15.1-1), samba-common-bin:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), samba-libs:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), libpam-winbind:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), libwbclient0:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), samba-vfs-modules:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), samba-common:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2), libsmbclient:amd64 (4.1.6+dfsg-1, 4.1.7+dfsg-2) End-Date: 2014-04-27 06:32:40 The machine was (re)booted at Apr 27 09:25:08. I'm guessing that one of the xserver updates solved the problem. 2014-04-17 19:25 GMT+02:00 Daniel Lindgren dali.s...@gmail.com: Package: libdrm2 Version: 2.4.52-1 Severity: important Dear Maintainer, Graphics hangs intermittently in Debian testing, this was in dmesg after several seconds of non responsive graphics: [ 430.954914] [drm] stuck on render ring [ 430.954918] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 430.954919] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 430.954920] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI - DRM/Intel [ 430.954920] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 430.954921] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 430.957326] [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x316e000 ctx 1) at 0x316e004 There are also various graphics issues, e g the mouse cursor often becomes a square block of lines. Tried reporting the bug at bugs.freedesktop.org but their bugzilla is broken(!). Tried attaching GPU crash dump to this report, wasn't allowed. Debian package info: Package: xorg Version: 1:7.7+7 Architecture: amd64 Package: xserver-xorg-video-intel Source: xserver-xorg-video-intel (2:2.21.15-2) Version: 2:2.21.15-2+b1 Architecture: amd64 Package: libdrm2 Source: libdrm Version: 2.4.52-1 Architecture: amd64 Package: libdrm-intel1 Source: libdrm Version: 2.4.52-1 Architecture: amd64 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libdrm2 depends on: ii libc6 2.18-4 ii multiarch-support 2.18-4 libdrm2 recommends no packages. libdrm2 suggests no packages.
Bug#745061: libdrm2: [drm] stuck on render ring
Package: libdrm2 Version: 2.4.52-1 Severity: important Dear Maintainer, Graphics hangs intermittently in Debian testing, this was in dmesg after several seconds of non responsive graphics: [ 430.954914] [drm] stuck on render ring [ 430.954918] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 430.954919] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 430.954920] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI - DRM/Intel [ 430.954920] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 430.954921] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 430.957326] [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x316e000 ctx 1) at 0x316e004 There are also various graphics issues, e g the mouse cursor often becomes a square block of lines. Tried reporting the bug at bugs.freedesktop.org but their bugzilla is broken(!). Tried attaching GPU crash dump to this report, wasn't allowed. Debian package info: Package: xorg Version: 1:7.7+7 Architecture: amd64 Package: xserver-xorg-video-intel Source: xserver-xorg-video-intel (2:2.21.15-2) Version: 2:2.21.15-2+b1 Architecture: amd64 Package: libdrm2 Source: libdrm Version: 2.4.52-1 Architecture: amd64 Package: libdrm-intel1 Source: libdrm Version: 2.4.52-1 Architecture: amd64 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libdrm2 depends on: ii libc6 2.18-4 ii multiarch-support 2.18-4 libdrm2 recommends no packages. libdrm2 suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696653: debian-installer-7.0-netboot-amd64: Initrd from PXE boot added to GRUB_CMDLINE_LINUX
Package: debian-installer-7.0-netboot-amd64 Version: D-I 7 beta 4 Severity: normal Tags: d-i Dear Maintainer, After installing Debian Wheezy using D-I 7 beta 4 netboot, I noticed that /proc/cmdline looked strange: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=fe8bcdc8-5f22-4539-9f50-1d2a358614b2 ro initrd=debian/7x64_beta/initrd.gz quiet The last part (initrd=...) is pointing to the path used when netbooting Debian Installer. /etc/default/grub contains this line: GRUB_CMDLINE_LINUX=initrd=debian/7x64_beta/initrd.gz Everything seems to work, but I manually cleared GRUB_CMDLINE_LINUX and updated grub. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696653: debian-installer-7.0-netboot-amd64: Initrd from PXE boot added to GRUB_CMDLINE_LINUX
2012/12/25 Julien Cristau jcris...@debian.org On Tue, Dec 25, 2012 at 08:51:19 +0100, Daniel Lindgren wrote: Package: debian-installer-7.0-netboot-amd64 Version: D-I 7 beta 4 Severity: normal Tags: d-i Dear Maintainer, After installing Debian Wheezy using D-I 7 beta 4 netboot, I noticed that /proc/cmdline looked strange: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=fe8bcdc8-5f22-4539-9f50-1d2a358614b2 ro initrd=debian/7x64_beta/initrd.gz quiet The last part (initrd=...) is pointing to the path used when netbooting Debian Installer. /etc/default/grub contains this line: GRUB_CMDLINE_LINUX=initrd=debian/7x64_beta/initrd.gz Everything seems to work, but I manually cleared GRUB_CMDLINE_LINUX and updated grub. Care to share the pxe config? Cheers, Julien Sure, it looks like this: LABEL Debian7x64_beta MENU LABEL - Debian Installer 7 beta 4 64-bitars (Wheezy) KERNEL debian/7x64_beta/linux APPEND vga=788 -- INITRD debian/7x64_beta/initrd.gz I copied the interesting bits from D-I's txt.cfg: default install label install menu label ^Install menu default kernel debian-installer/amd64/linux append vga=788 initrd=debian-installer/amd64/initrd.gz -- quiet Kernel, initrd.gz and txt.cfg from http://d-i.debian.org/daily-images/amd64/daily/netboot/debian-installer/amd64/ . Cheers, Daniel
Bug#685895: firmware-linux-nonfree: Intermittent black screen on ATI Radeon with nonfree firmware
Package: firmware-linux-nonfree Version: 0.28+squeeze1 Severity: important I have an old computer with a Radeon 9200 (RV280) AGP card. After installing Squeeze everything works fine. If I install firmware-linux- nonfree to get the firmware for my Radeon card, the screen (in X/Gnome) goes black for a second or two and then returns to normal. This happens mostly when the screen is updated, e g if I scroll a window, several times per minute if I actively use the computer. If I remove firmware-linux-nonfree the problem goes away, but GPU acceleration is disabled. I tried using a newer kernel (linux-image-3.2.0-0.bpo.3-686-pae) and firmware- linux-nonfree (0.35~bpo60+1) from backports, no improvement. Since I do not need any other firmware from the nonfree package I can remove it as a workaround. Others might not have that option. lspci: 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) 00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev 02) 00:06.0 System peripheral: Intel Corporation 82865G/PE/P Processor to I/O Memory Interface (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01) 02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) dmesg | grep radeon: [6.826320] [drm] radeon kernel modesetting enabled. [6.826406] radeon :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [6.829897] [drm] radeon: Initializing kernel modesetting. [6.835387] radeon :01:00.0: putting AGP V3 device into 8x mode [6.835405] [drm] radeon: VRAM 128M [6.835408] [drm] radeon: VRAM from 0x to 0x07FF [6.835411] [drm] radeon: GTT 64M [6.835413] [drm] radeon: GTT from 0xF800 to 0xFBFF [6.835458] [drm] radeon: irq initialized. [6.835992] [drm] radeon: 128M of VRAM memory ready [6.835996] [drm] radeon: 64M of GTT memory ready. [6.836308] [drm] radeon: cp idle (0x02000603) [6.837096] platform radeon_cp.0: firmware: requesting radeon/R200_cp.bin [6.983934] [drm] radeon: ring at 0xF800 [6.991159] [drm] radeon: ib pool ready. [7.361279] fb0: radeondrmfb frame buffer device [7.380411] [drm] Initialized radeon 2.0.0 20080528 for :01:00.0 on minor 0 -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash firmware-linux-nonfree depends on no packages. firmware-linux-nonfree recommends no packages. Versions of packages firmware-linux-nonfree suggests: ii initramfs-tools 0.99~bpo60+1 tools for generating an initramfs ii linux-image-2.6.32-5-68 2.6.32-45Linux 2.6.32 for modern PCs ii linux-image-3.2.0-0.bpo 3.2.23-1~bpo60+2 Linux 3.2 for modern PCs -- 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#602642: Works after exactly 15 minutes!
Today there was a kernel update released for Squeeze. After reboot, the bind mounted subdirectory was inaccessible via NFS again, even with Lenny versions of nfs-common and nfs-kernel-server installed. I updated them to Squeeze versions, no improvement. DId some troubleshooting, couldn't get it to work and then took a break to eat. After eating i returned to find that accessing the bind mounted directory now worked! I've done some testing and it takes exactly 15 minutes (900 seconds) after nfs-kernel-server has been started until I can access the bind mounted subdirectory via the NFS share. I can access the root of the NFS share immediately, but the bind mounted subdirectory won't be accessible for another 15 minutes. /Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602642: More info needed?
The bug report is still tagged moreinfo, please indicate what (if any) additional information that is needed. /Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602642: nfs-kernel-server: Crossmnt stopped working after upgrade from Lenny to Squeeze
Were these clients restarted after the file server was upgraded? Yes. I rebooted them too, didn't help. I have a couple of Debian clients and a Mac OS X machine, neither could access the raid directory after upgrade (and reboots). Downgrade solved all problems. I may have filed the bug for the wrong package, nfs-common has to be downgraded to make it work. Not sure if the problem is with nfs-kernel-server or nfs-common or both, but I know that only downgrading nfs-kernel-server wasn't enough. Perhaps downgrading nfs-common would have sufficed. /Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602642: nfs-kernel-server: Crossmnt stopped working after upgrade from Lenny to Squeeze
Package: nfs-kernel-server Version: 1:1.1.2-6lenny2 Severity: important Upgraded file server from Lenny to Squeeze. After upgrade NFS clients failed to access bind mounted subdirectories on NFS server, error message about stale NFS handle. Basic setup on fileserver: /dev/md0 is mounted at /mnt/md0 in fstab /mnt/md0/raid is bind mounted at /data/raid in fstab /etc/exports looks like this: /data 192.168.0.0/255.255.255.0(ro,no_subtree_check,crossmnt) NFS clients mount fileserver:/data. This setup has been used for about a year. After fileserver was upgraded to Squeeze the clients could mount fileserver:/data but not access the raid subfolder, got an error message about stale NFS handle. Downgrading nfs-kernel-server and nfs-common to Lenny versions (1:1.1.2-6lenny2) restored functionality. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-kernel-server depends on: ii libblkid12.17.2-3.3 block device id library ii libc62.11.2-7Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-2 common error description library ii libgssglue1 0.1-4 mechanism-switch gssapi library ii libkrb53 1.8.3+dfsg-2transitional package for MIT Kerbe ii libnfsidmap2 0.23-2 An nfs idmapping library ii librpcsecgss30.19-2 allows secure rpc communication us ii libwrap0 7.6.q-19Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip ii nfs-common 1:1.1.2-6lenny2 NFS support files common to client ii ucf 3.0025+nmu1 Update Configuration File: preserv nfs-kernel-server recommends no packages. nfs-kernel-server 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#598137: brasero ignores error from libisofs
Package: brasero Version: 2.30.3-1 Severity: important I've been trying to burn data CD:s. During burning this message is written to the command prompt where brasero was started: brasero (libisofs)MISHAP : Image write cancelled However, brasero continues to burn the CD and creates an unusable disc (or a 2 MB ISO file), no error message in brasero window: BraseroBurn: (at burn-libisofs.c:672) BraseroLibisofs Found parent brasero (libisofs)DEBUG : Creating low level ECMA-119 tree... brasero (libisofs)DEBUG : Matching hardlinks... brasero (libisofs)DEBUG : Sorting the low level tree... brasero (libisofs)DEBUG : Mangling names... brasero (libisofs)DEBUG : Creating low level Joliet tree... brasero (libisofs)DEBUG : Sorting the Joliet tree... brasero (libisofs)DEBUG : Mangling Joliet names... brasero (libisofs)DEBUG : Computing position of dir structure brasero (libisofs)DEBUG : Computing length of pathlist brasero (libisofs)DEBUG : Computing position of Joliet dir structure brasero (libisofs)DEBUG : Computing length of Joliet pathlist BraseroBurn: (at burn-job.c:1925) BraseroLibisofs called brasero_job_set_output_size_for_current_track brasero (libisofs)DEBUG : Starting image writing... BraseroBurn: (at burn-task-ctx.c:607) Task output modified 345911 blocks 708425728 bytes brasero (libisofs)DEBUG : Write volume descriptors BraseroBurn: (at burn-job.c:1433) BraseroLibisofs called brasero_job_get_action brasero (libisofs)DEBUG : Write Primary Volume Descriptor BraseroBurn: (at burn-job.c:1071) BraseroLibisofs Finished track successfully brasero (libisofs)DEBUG : Reader thread being cancelled brasero (libisofs)DEBUG : Write SVD for Joliet brasero (libisofs)DEBUG : Writing ISO Path tables brasero (libisofs)DEBUG : Writing Joliet Path tables brasero (libisofs)DEBUG : Writing Files... brasero (libisofs)MISHAP : Image write cancelled brasero (libisofs)DEBUG : Writer thread joined BraseroBurn: (at burn-task-ctx.c:357) No next track to process BraseroBurn: (at burn-task.c:182) stopping BraseroLibisofs BraseroBurn: (at burn-job.c:906) BraseroLibisofs stopping BraseroBurn: (at burn-task.c:190) stopped BraseroLibisofs BraseroBurn: (at burn-task.c:448) got out of loop BraseroBurn: (at brasero-burn.c:2202) Burning from 0 to 345911 BraseroBurn: (at burn-task.c:600) Starting normal task (0) BraseroBurn: (at burn-task-ctx.c:159) Setting current track (1 tracks) BraseroBurn: (at burn-task.c:336) ::activate method BraseroLibisofs BraseroBurn: (at burn-job.c:352) no ::activate method BraseroLibisofs BraseroBurn: (at burn-task.c:293) ::start method BraseroLibisofs BraseroBurn: (at burn-job.c:1433) BraseroLibisofs called brasero_job_get_action BraseroBurn: (at burn-job.c:1790) BraseroLibisofs called brasero_job_get_session_output_size BraseroBurn: (at brasero-caps-session.c:835) Checking support for output Image BIN BraseroBurn: (at brasero-caps-session.c:836) and input Data ISO JOLIET BraseroBurn: (at brasero-caps-session.c:837) with flags no grace, check size, BraseroBurn: (at brasero-caps-session.c:568) Found link (with 4 links): Image BIN BraseroBurn: (at brasero-caps-session.c:568) Found link (with 0 links): Data ISO SYMLINK Level 3 DEEP BraseroBurn: (at brasero-caps-session.c:835) Checking support for output Image BIN BraseroBurn: (at brasero-caps-session.c:836) and input Data ISO JOLIET BraseroBurn: (at brasero-caps-session.c:837) with flags no grace, check size, BraseroBurn: (at brasero-caps-session.c:568) Found link (with 4 links): Image BIN BraseroBurn: (at brasero-caps-session.c:568) Found link (with 0 links): Data ISO SYMLINK Level 3 DEEP BraseroBurn: (at burn-job.c:659) BraseroLibisofs output set (IMAGE) image = /home/dali/brasero-11.iso toc = none BraseroBurn: (at burn-job.c:511) ext3/ext4 filesystem detected BraseroBurn: (at burn-job.c:1790) BraseroLibisofs called brasero_job_get_session_output_size BraseroBurn: (at burn-job.c:530) Volume size 191592697856, output size 708425728 BraseroBurn: (at burn-job.c:1433) BraseroLibisofs called brasero_job_get_action BraseroBurn: (at burn-task.c:442) entering loop BraseroBurn: (at burn-libisofs.c:291) BraseroLibisofs Entering thread BraseroBurn: (at burn-job.c:1312) BraseroLibisofs called brasero_job_get_fd_out BraseroBurn: (at burn-job.c:1337) BraseroLibisofs called brasero_job_get_image_output BraseroBurn: (at burn-libisofs.c:247) BraseroLibisofs writing to file /home/dali/brasero-11.iso BraseroBurn: (at burn-job.c:1861) BraseroLibisofs called brasero_job_set_current_action BraseroBurn: (at burn-libisofs.c:300) BraseroLibisofs Getting out thread BraseroBurn: (at burn-job.c:1312) BraseroLibisofs called brasero_job_get_fd_out BraseroBurn: (at burn-job.c:1337) BraseroLibisofs called brasero_job_get_image_output BraseroBurn: (at burn-job.c:1790) BraseroLibisofs called brasero_job_get_session_output_size BraseroBurn: (at burn-job.c:989) BraseroLibisofs called brasero_job_add_track BraseroBurn: (at burn-job.c:1433) BraseroLibisofs called brasero_job_get_action BraseroBurn:
Bug#585865: scite: Lua startup script functions do not work
Package: scite
Version: 1.76-1
Severity: normal
I use SciTE on Windows, Debian (Lenny Squeeze), CentOS and Ubuntu. I have a
startup script which adds a sort function to SciTE, that function works in all
SciTE installs I have except Debian.
This is the startup script I use (~/scite_commands.lua):
-- From http://lua-users.org/wiki/SciteSortSelection.
-- Sort a selected text
function lines(str)
local t = {}
local i, lstr = 1, #str
while i = lstr do
local x, y = string.find(str, \r?\n, i)
if x then t[#t + 1] = string.sub(str, i, x - 1)
else break
end
i = y + 1
end
if i = lstr then t[#t + 1] = string.sub(str, i) end
return t
end
function sort_text()
local sel = editor:GetSelText()
if #sel == 0 then return end
local eol = string.match(sel, \n$)
local buf = lines(sel)
--table.foreach(buf, print) --used for debugging
table.sort(buf)
local out = table.concat(buf, \n)
if eol then out = out..\n end
editor:ReplaceSel(out)
end
function sort_text_reverse()
local sel = editor:GetSelText()
if #sel == 0 then return end
local eol = string.match(sel, \n$)
local buf = lines(sel)
--table.foreach(buf, print) --used for debugging
table.sort(buf, function(a, b) return a b end)
local out = table.concat(buf, \n)
if eol then out = out..\n end
editor:ReplaceSel(out)
end
This is added to .SciTEUser.properties:
ext.lua.startup.script=$(SciteUserHome)/scite_commands.lua
command.name.1.*=Sort text
command.1.*=sort_text
After restart of SciTE, you should be able to mark some lines and have them
sorted alpabetically, either by pressing Ctrl+1 or selecting Tools - Sort
text from the menu.
As stated before, the sort function works in SciTE running on Windows, Ubuntu
and CentOS, but not in Debian (Lenny or Squeeze).
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages scite depends on:
ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii libc6 2.7-18lenny4 GNU C Library: Shared libraries
ii libcairo2 1.6.4-7 The Cairo 2D vector graphics libra
ii libgcc1 1:4.3.2-1.1 GCC support library
ii libglib2.0-02.16.6-3 The GLib library of C routines
ii libgtk2.0-0 2.12.12-1~lenny1 The GTK+ graphical user interface
ii libpango1.0-0 1.20.5-5+lenny1 Layout and rendering of internatio
ii libstdc++6 4.3.2-1.1The GNU Standard C++ Library v3
scite recommends no packages.
scite 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#585865: Correction
The last line added to .SciTEUser.properties is missing, it should look like this: ext.lua.startup.script=$(SciteUserHome)/scite_commands.lua command.name.1.*=Sortera text command.1.*=sort_text command.mode.1.*=subsystem:lua,savebefore:no -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
