Bug#1004166: strongswan-nm: Creates VPN configs that disable using system CA certificate directories
On 1/24/22 02:00, Tobias Brunner wrote: Hi Daniel, Removing the blank "certificate=" line from the VPN connection config in /etc/NetworkManager/system-connections/ restores the original behavior. However, modifying the connection config in NetworkManager will again add the blank "certficiate=" line, once again breaking the connection config. I can't reproduce this. What does the "Certificate" file chooser display when you open the editor? "(None)"? Regards, Tobias Perhaps I wasn't clear. Applying any change to any field in the NetworkManager strongswan VPN plugin config will write a text config file with the 'certificate=' line. For example, the following resulting connection config snippet would be broken because no certificate was specified in the GUI: ... [vpn] address=vpn.example.com certificate= encap=yes ... Changing that snippet to the following makes the connection work using system certificates: ... [vpn] address=vpn.example.com encap=yes ... Notice the missing 'certificate=' line. However, any change made in the GUI would restore the certificate= line as show below: ... [vpn] address=different-vpn.example.com certificate= encap=yes ... Thus, manually modifying the GUI-created VPN config is a temporary workaround, but it will break eventually when the the user applies something in the GUI, and a new config is written out. The GUI config should not include a 'certificate=' line when the GUI's "Certificate:" field is left blank. Alternatively, strongswan should assume 'certificate=' indicates the system certificates should be used. Does that answer your question? -- Daniel Fussell CAEDM Linux Administrator BYU College of Engineering 240 EB, Provo UT 84602 801-422-5351 dfuss...@byu.edu
Bug#1004166: strongswan-nm: Creates VPN configs that disable using system CA certificate directories
Package: strongswan-nm Version: 5.9.1-1+deb11u1 Severity: important Dear Maintainer, After upgrading from Buster to Bullseye, found that NetworkManager is no longer able to start Strongswan VPN connections that use the system's CA certificate store. The daemon.log shows the following error during phase1: charon-nm: 05[LIB] opening '' failed: No such file or directory Specifying the appropriate CA cert for the provided server cert fixes the issue, at least until the server starts using a cert signed by a different CA root cert (e.g. changing CA vendor, vendor changes root cert for whatever reason, new server cert is a different cert service class, etc). Removing the blank "certificate=" line from the VPN connection config in /etc/NetworkManager/system-connections/ restores the original behavior. However, modifying the connection config in NetworkManager will again add the blank "certficiate=" line, once again breaking the connection config. Setting "certificate=" to a large cert file like /etc/ssl/certs/ca-certificates.crt does not allow one to restore the original behavior. As I recall, it seems to try a few certs, then fails as not being able to verify the server cert chain. I have not tested if a smaller combined CA cert file would work. I would expect the user to decide if they wished to use system certificates, or even a small set of trusted CA certificates. This could be done as in the past, by specifying a blank certificate field, or by a plugin option (either in the connection editor, or in /etc/strongswan/charon configs for charon-nm) that allows the user to select if they want to use system CA certs, a smaller set of trusted certs (e.g. /etc/ipsec.d/cacerts), or the current behavior of only trusting a single CA cert. -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages strongswan-nm depends on: ii libc6 2.31-13+deb11u2 ii libglib2.0-0 2.66.8-1 ii libnm01.30.0-2 ii libstrongswan 5.9.1-1+deb11u1 ii strongswan-libcharon 5.9.1-1+deb11u1 Versions of packages strongswan-nm recommends: ii network-manager-strongswan 1.5.2-1 strongswan-nm suggests no packages. -- no debconf information
Bug#945172: firmware: failed to load rtw88/rtw8822b_fw.bin (workaround - correction)
The last line of "modprobe rtw8822b_fw.bin" was supposed to say "modprobe rtwpci". Sorry about that.
Bug#932856: mariadb-client-10.3: mysqldump uses 10.3 options with pre-10.3 servers and breaks
Package: mariadb-client-10.3 Version: 1:10.3.15-1 Severity: critical Tags: upstream Justification: causes serious data loss Dear Maintainer, mysqldump is unable to backup triggers and routines from any pre-10.3 version server From the upstream bug-report ( https://jira.mariadb.org/browse/MDEV-17429): When issuing a 10.3 mysqldump command to dump triggers and routines from a 10.2 server, the tool breaks because it tries to issue a SHOW PACKAGES command which is not supported in 10.2 and earlier releases. mysqldump --quick --routines --triggers --no-create-info --skip-lock-tables --no-data --compress -h 10.10.16.138 -u mariadb_mock_import -p myschema mysqldump: Couldn't execute 'SHOW PACKAGE STATUS WHERE Db = 'myschema'': You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'PACKAGE STATUS WHERE Db = 'myschema'' at line 1 (1064) Running mysqldump without the --triggers and --routines flags will backup the database structure and data, but will lose the associated triggers and routines. For admins and developers, loading the dump back into a server would require manually creating the triggers from some previous backup or repository (assuming a viable backup exists). Running mysqldump with --triggers and --routines flags enabled will fail entirely, potentially breaking backup scripts and cron jobs that depend on it. While this will not lose data directly, it does preclude the option of restoring databases when a server upgrade fails, or tables are corrupted, or when a mistaken drop/update/replace/insert statement is issued. A successful database dump (including triggers and routines) is expected. The mysqldump 10.3 server version incompatibility is reported to be fixed in 10.3.17. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-client-10.3 depends on: ii debianutils 4.8.6.1 ii libc6 2.28-10 ii libconfig-inifiles-perl 3.01-1 ii libgnutls30 3.6.7-4 ii libstdc++6 8.3.0-6 ii mariadb-client-core-10.3 1:10.3.15-1 ii perl 5.28.1-6 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages mariadb-client-10.3 recommends: ii libdbd-mysql-perl 4.050-2 ii libdbi-perl 1.642-1+b1 ii libterm-readkey-perl 2.38-1 mariadb-client-10.3 suggests no packages. -- no debconf information
Bug#792057: kwin-x11: Moving and resizing windows breaks for all applications when using clusterssh
Package: kwin-x11 Version: 4:5.3.2-1 Severity: important Dear Maintainer, kwin_x11 stops handling window move and resize requests for all windows when using clusterssh. This seems to happen when clicking inside the main CSSH control window, but only after clusterssh has opened and placed xterm windows. Before any xterms have been created by clusterssh, it's interface can be used without breaking kwin_x11. Running kwin_x11 --replace fixes the issue, but breaks again once you try to use the main clusterssh window again. The problems are not experience when using the xfwm4 or metacity window managers (via xfwm4 --replace and metacity --replace respectively). I'm not aware of any other applications that use the X11 protocol to control window geometry and placement. If there are others, they may be affected as well. The following are the message displayed from kwin_x11 just after creating a terminal and clicking in the CSSH control window: kwin_core: screens: 2 desktops: 4 kwin_core: Done. kwin_core: Rule found: [ Window settings for xterm : xterm ] : 'ID: 67108878 ;WMCLASS: xterm : xterm ;Caption: CSSH: root@smb01 ' kwin_core: User timestamp, ASN: 4294967295 kwin_core: User timestamp, final: 'ID: 67108878 ;WMCLASS: xterm : xterm ;Caption: CSSH: root@smb01 ' : 8197253 kwin_core: Activation, compared: 'ID: 67108878 ;WMCLASS: xterm : xterm ;Caption: CSSH: root@smb01 ' : 8197253 : 8182851 : true kwin_core: screens: 2 desktops: 4 kwin_core: Done. kwin_core: screens: 2 desktops: 4 kwin_core: Done. kwin_core: Rule found: [ Window settings for xterm : xterm ] : 'ID: 67108878 ;WMCLASS: xterm : xterm ;Caption: CSSH: root@smb01 ' kwin_core: User timestamp, ASN: 4294967295 kwin_core: User timestamp, final: 'ID: 67108878 ;WMCLASS: xterm : xterm ;Caption: CSSH: root@smb01 ' : 4294967295 kwin_core: Activation: No timestamp at all kwin_core: screens: 2 desktops: 4 kwin_core: Done. kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size. kwin_core: screens: 2 desktops: 4 kwin_core: Done. kwin_core: User timestamp, ASN: 4294967295 kwin_core: User timestamp, final: 'ID: 65011756 ;WMCLASS: cssh : cssh ;Caption: CSSH [1] ' : 4294967295 kwin_core: Activation: No timestamp at all kwin_core: screens: 2 desktops: 4 kwin_core: Done. kwin_core: Raising: Belongs to active application kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size. QXcbConnection: XCB error: 6 (BadCursor), sequence: 22177, resource id: 23068796, major code: 2 (ChangeWindowAttributes), minor code: 0 QXcbConnection: XCB error: 6 (BadCursor), sequence: 22188, resource id: 23068796, major code: 2 (ChangeWindowAttributes), minor code: 0 areKeySymXsDepressed: any of 2 0 : keySymX=0x ffe9 i= 8 mask=0x 1 keymap[i]=0x 1 kwin_core: 0x20071: Buffer detailed info: Buffer object 3 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations. kwin_core: 0x20071: Buffer detailed info: Buffer object 4 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations. kwin_core: 0x20071: Buffer detailed info: Buffer object 5 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations. kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size. kwin_core: 0x20092: Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches. kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size. kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size. kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size. kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size. areKeySymXsDepressed: any of 2 0 : keySymX=0x ffe9 i= 8 mask=0x 1 keymap[i]=0x 1 It should be noted that I have been using window rules to force KDE4's kwin to use the application's requested geometry and placement. The windows management breakage happened with an empty set of rules immediately after installing kwin_x11, and after creating windows rules. Steps reproduce: 1) start clusterssh and add ssh connections with it 2) click in the CSSH
Bug#780320: nslcd: Fails to return group names
Package: nslcd Version: 0.9.4-3 Severity: important Dear Maintainer, Running nslcd on sid generally works, but is not able to get group names from ldap, reporting the following errors when requesting information on a user with the id command: nslcd: [9478fe] DEBUG: connection from pid=2735 uid=2345 gid=4274 nslcd: [9478fe] group=1217 DEBUG: myldap_search(base=ou=groups,ou=removed, dc=removed,dc=removed,dc=removed, filter=((objectClass=posixGroup)(gidNumber=1217))) nslcd: [9478fe] group=1217 ldap_result() failed: Protocol error: paged results control could not be decoded Any service depending on group names does not work properly, for example: * id shows only gid numbers instead of gid and group name for ldap groups; local users and groups display correctly * ls -l shows the user name and gid, instead of the group name for groups defined in ldap. * chgrp cannot use group names. Installing nslcd from wheezy and running nslcd -d shows all queries working with the same nslcd.conf, and all names resolve properly. Unfortunately, systemd does not start wheezy's nslcd properly, so this isn't a decent short-term workaround. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-1-amd64 (SMP w/2 CPU cores) 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 nslcd depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.51 ii libc6 2.17-93 ii libgssapi-krb5-2 1.12.1+dfsg-16 ii libldap-2.4-2 2.4.31-1+nmu2+b1 Versions of packages nslcd recommends: ii bind9-host [host] 1:9.9.3.dfsg.P2-4 ii ldap-utils 2.4.31-1+nmu2+b1 ii libnss-ldapd [libnss-ldap] 0.9.4-3 ii libpam-ldapd [libpam-ldap] 0.9.4-3 ii nscd2.17-93 ii nslcd-utils 0.9.4-3 Versions of packages nslcd suggests: pn kstart none -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743832: linux-image-3.2.0-4-amd64: e1000e driver fails probe with error -2 when, resuming from suspend
Package: src:linux Version: 3.2.54-2 Severity: important Tags: upstream Dear Maintainer, e1000e module with Intel 82579LM network card does not suspend properly, and generally either prevents the system from suspending, or results in a probe failure with error -2 when the the system comes out of suspend. After which the network interface is completely unusable until you restart into the system BIOS, disable the network card, reboot, and re-enable the network card; a simple reboot is not enough to get the card to reinitialize. Updating the system BIOS to F.46 does not resolve the issue Tried downloading updated driver from Intel site, but it shows the same behavior Tried kernels 3.2 and 3.12, with no change in behavior. Looked around for possible update network card firmware, with no success ethtool -w eth0 says a firmware dump is not supported by the card Disabling Deep Sleep in BIOS did not help Looked at modinfo and /sys filesystem for some option that might force the card to be reinitialized, but no joy. If the network card is preventing the system from suspending, modprobe -r e1000e will allow the system to suspend, but modprobing it back in after resume still ends up with the same probe problem. Removing and re-probing the module is not enough to re-initialize the card. This appears to be an on-going problem with Intel NICs of the past few years across a number of different system vendors, so appears that the problem is a general problem with either the firmware or driver. -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/system-root ro quiet vga=791 ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [8.690512] parport0: PC-style at 0x378 (0x778), irq 5 [PCSPP,TRISTATE] [8.697046] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07 [8.697108] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) [8.697158] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [8.697513] cfg80211: Calling CRDA to update world regulatory domain [8.697528] hp_accel: laptop model unknown, using default axes configuration [8.698116] lis3lv02d: 8 bits 3DC sensor found [8.735546] input: ST LIS3LV02DL Accelerometer as /devices/platform/lis3lv02d/input/input5 [8.735749] Registered led device: hp::hddprotect [8.735759] hp_accel: driver loaded [8.952955] ACPI: AC Adapter [AC] (on-line) [8.981628] acpi device:01: registered as cooling_device8 [8.982078] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/LNXVIDEO:00/input/input6 [8.982119] ACPI: Video Device [DGFX] (multi-head: yes rom: no post: no) [9.010064] tpm_tis 00:04: 1.2 TPM (device-id 0xB, rev-id 16) [9.130260] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) [9.132661] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree: [9.132662] Copyright(c) 2003-2011 Intel Corporation [9.132702] iwlwifi :25:00.0: setting latency timer to 64 [9.132716] iwlwifi :25:00.0: pci_resource_len = 0x2000 [9.132717] iwlwifi :25:00.0: pci_resource_base = c9001199 [9.132718] iwlwifi :25:00.0: HW Revision ID = 0x34 [9.132805] iwlwifi :25:00.0: irq 49 for MSI/MSI-X [9.132837] iwlwifi :25:00.0: Detected Intel(R) Centrino(R) Advanced-N 6205 AGN, REV=0xB0 [9.132884] iwlwifi :25:00.0: L1 Disabled; Enabling L0S [9.150715] iwlwifi :25:00.0: device EEPROM VER=0x715, CALIB=0x6 [9.150717] iwlwifi :25:00.0: Device SKU: 0X1f0 [9.150718] iwlwifi :25:00.0: Valid Tx ant: 0X3, Valid Rx ant: 0X3 [9.150734] iwlwifi :25:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels [9.150792] iwlwifi :25:00.0: RF_KILL bit toggled to disable radio. [9.214690] iwlwifi :25:00.0: firmware: agent loaded iwlwifi-6000g2a-5.ucode into memory [9.214707] iwlwifi :25:00.0: loaded firmware version 17.168.5.3 build 42301 [9.214873] Registered led device: phy0-led [9.23] input: HP WMI hotkeys as /devices/virtual/input/input7 [9.423701] Linux media interface: v0.10 [9.479659] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input8 [9.554138] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [9.554143] Disabling lock debugging due to kernel taint [9.661361] [fglrx] Maximum main memory to use for locked dma buffers: 7709 MBytes. [9.661874] [fglrx] vendor: 1002 device: 6841 count: 1 [9.662089] [fglrx] ioport: bar 4, base 0x4000, size: 0x100 [9.662099] pci :01:00.0: setting latency timer to 64 [9.662151] [fglrx] Kernel PAT support is enabled [9.662163] [fglrx] module loaded - fglrx
Bug#682162: mysql-workbench: Massive Memory Leak
On 07/20/2012 07:01 PM, Dmitry Smirnov wrote: Hi Daniel, Thanks for your report. It is a bit puzzling since just a week ago I was using M-W for several hours a day and I didn't even bother to restart it for a week - I was just suspending my workstation instead. Also I've noticed that upstream have no open tickets regarding memory leaks which I interpret as evidence that there is no such problem for all other distributions. Today I tried to reproduce the issue without success: after ~50 trivial SELECT queries mysql-workbench-bin uses VIRT : 683M RES : 75200 SHR : 41300 with ~10 threads. It is a heavy application indeed but I see no problem you describe. Would you be able to provide more information how to reproduce please? Thanks. Regards, Dmitry. When I start the workbench, it has 90m resident allocated. I run a select now(); query two times, and resident grows to 102m. On the third run of the same query, resident jumps to 170m. On the fourth run, it runs to 1g in about 10 seconds, and starts into swap death. I periodically update packages as they come available, and I recently updated from 5.2.38-something to 5.2.40 hoping to resolve occasional segfaults and missing schema trees. I thought maybe it was a problem with the previous ~/.mysql/workbench settings, so I renamed the .mysql directory and let it recreate it. That didn't help. I've done a remove and reinstall, but no difference. I've compiled it from source as well, and I have the same problem. I've done straces and attached with gdb to try and track down where it starts leaking. So far it looks like it happens well after DbSqlEditorView::on_exec_sql_done(), during a bunch of Glib calls, though I haven't narrowed it down much more. I had a couple coworkers try it. One is using aptosid, and he has no problem, the other is running Debian sid as well, and has no problem. I'm running native rendering as OpenGL doesn't work with my nouveau drivers. The other two are on intel graphics and an ATI card with proprietary drivers. One is on KDE4, the other is on Gnome3. It might be it's a problem in the native rendering and not discovered if everyone else is using OpenGL rendering, but that's just another stab in the dark at this point. Grazie, Daniel Fussell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682162: mysql-workbench: Massive Memory Leak
Package: mysql-workbench Version: 5.2.40+dfsg-1+b1 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, * What led up to the situation? Entering and running 3 queries in the workbench SQL editor, with a maximum of 3 records in any of those queries (so not a result of a boundless cartesian product). Total time in the session is only about 3 minutes when the memory leak starts. * What was the outcome of this action? Process when from 92m resident to 1.5g resident memory usage over the course of about 10 - 15 seconds, at which point my machine starts into swap-death, and the process must be manually killed. Just to be clear, this is resident memory, thought virtual memory is always high as well. * What outcome did you expect instead? To be able to continue using, editing, and running several queries for the duration of my session. At least a couple of hours would be nice, and without using an enormous amount of memory. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) 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 mysql-workbench depends on: ii libatk1.0-0 2.4.0-2 ii libatkmm-1.6-1 2.22.6-1 ii libc62.13-33 ii libcairo21.12.2-2 ii libcairomm-1.0-1 1.10.0-1 ii libctemplate22.2-3 ii libfontconfig1 2.9.0-6 ii libfreetype6 2.4.9-1 ii libgcc1 1:4.7.1-2 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libgl1-mesa-glx [libgl1] 8.0.3-1 ii libglib2.0-0 2.32.3-1 ii libglibmm-2.4-1c2a 2.32.0-1 ii libgnome-keyring03.4.1-1 ii libgtk2.0-0 2.24.10-1 ii libgtkmm-2.4-1c2a1:2.24.2-1 ii liblua5.1-0 5.1.5-2 ii libmysqlclient18 5.5.24+dfsg-4 ii libpango1.0-01.30.0-1 ii libpangomm-1.4-1 2.28.4-1 ii libpcre3 1:8.30-5 ii libpython2.7 2.7.3-1 ii libsigc++-2.0-0c2a 2.2.10-0.2 ii libsqlite3-0 3.7.13-1 ii libstdc++6 4.7.1-2 ii libtinyxml2.6.2 2.6.2-1 ii libuuid1 2.20.1-5.1 ii libx11-6 2:1.5.0-1 ii libxml2 2.8.0+dfsg1-4 ii libzip2 0.10.1-1 ii mysql-client 5.5.24+dfsg-4 ii mysql-client-5.5 [mysql-client] 5.5.24+dfsg-4 ii mysql-workbench-data 5.2.40+dfsg-1 ii python 2.7.3~rc2-1 ii python-mysql.connector 0.3.2-1 ii python-paramiko 1.7.7.1-2 ii python-pexpect 2.4-1 ii python-pysqlite2 2.6.3-3 ii python2.72.7.3-1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages mysql-workbench recommends: ii mysql-utilities 1.0.5-1 ii ttf-bitstream-vera 1.10-8 Versions of packages mysql-workbench suggests: ii gnome-keyring 3.4.1-4 -- 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#599358: grub-common: dsfjklsdfjkl
Package: grub-common Version: 1.96+20080724-10 Severity: important Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Daniel Fussell dfuss...@byu.edu To: Debian Bug Tracking System 593...@bugs.debian.org Subject: grub-common: segfaulting while scanning a specific lvm LV Message-ID: 20101006202824.6254.53001.report...@xen2.et.byu.edu X-Mailer: reportbug 3.45 Date: Wed, 06 Oct 2010 14:28:24 -0600 Package: grub-common Followup-For: Bug #593652 When doing kernel security updates, aptitude says update-grub failed with error 139. Checking other bug reports lead me to try grub-probe -vv -d /dev/system/root -t abstraction which works fine on my many logical volumes until it get to my root volume (/dev/system/root), where it segfaults. Thought there might be some data needing to be flushed, so ran sync. No dice. Tried updating grub, but couldn't finish because the other kernels haven't finished configuring. The root filesystem (ext3) hadn't been checked in many years, but I'm not in a position to reboot. So I created an lvm snapshot and ran fsck on the snapshot; it came up clean. Then I ran grub-probe, and it finished WITHOUT segfaulting (go fig). Ran update-grub, it finished without error. Ran aptitude install, finished configuring the kernels and updated grub without issue. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/8 CPU cores) 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 grub-common depends on: ii base-files4.0.5 Debian base system miscellaneous f ii libc6 2.7-14 GNU C Library: Shared libraries grub-common recommends no packages. Versions of packages grub-common suggests: pn multiboot-doc none (no description available) -- no debconf information -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/8 CPU cores) 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 grub-common depends on: ii base-files4.0.5 Debian base system miscellaneous f ii libc6 2.7-14 GNU C Library: Shared libraries grub-common recommends no packages. Versions of packages grub-common suggests: pn multiboot-doc none (no description available) -- 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#519586: linux-image-2.6.26-1-xen-amd64: Huge Slab Unreclaimable and continually growing
Package: linux-image-2.6.26-1-xen-amd64 Severity: critical Justification: breaks unrelated software After ~4 days running a high-load Samba server in a domU with 1G memory, SUnreclaim grows to over 700MB, dropping samba performance from ~60MB/s transfers to 2MB/s transfers. Appears to also be a problem with stock linux-image-2.6.26-1-amd kernel as well, as tested from a physical machine w/ 4G memory and 4 Opterons, though it takes longer to fill the memory and degrade performance. 'xm mem-set'-ing the domU to 2G memory recovers some performance (not all), and slab unreclaimable continues to grow. I've tested with Lenny and Samba versions 3.2.5 (lenny), 3.3.0 (experimental), and 3.0.23c (compiled from upstream) in a domU, and 3.3.0 (experimental) on the physical machine. I have one other pre-production Lenny domU running apache that is not showing the cancerous slab growth; but it is pre-production and not taking nearly the same load as the samba servers. slabtop shows most of the slabs consumed by size-128 (~1.4M objects using ~160MB) and size-256 (~1.4M objects using ~360M) /boot/config-2.6.26-1-xen-amd64 show SLAB as the allocator in the xen and non-xen kernels. I'm currently compiling with SLUB on a xen kernel to see if it resolves the issue. Both machine's meminfo and procinfo are attached. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash *** /proc/meminfo MemTotal: 1048576 kB MemFree:234620 kB Buffers: 34248 kB Cached: 121492 kB SwapCached: 0 kB Active: 74620 kB Inactive: 100064 kB SwapTotal: 1048568 kB SwapFree: 1048552 kB Dirty: 32 kB Writeback: 0 kB AnonPages: 18948 kB Mapped: 8452 kB Slab: 582628 kB SReclaimable: 8484 kB SUnreclaim: 574144 kB PageTables: 0 kB NFS_Unstable:0 kB Bounce: 0 kB WritebackTmp:0 kB CommitLimit: 1572856 kB Committed_AS:49676 kB VmallocTotal: 34359738367 kB VmallocUsed: 656 kB VmallocChunk: 34359737711 kB *** /proc/slabinfo slabinfo - version: 2.1 # nameactive_objs num_objs objsize objperslab pagesperslab : tunables limit batchcount sharedfactor : slabdata active_slabs num_slabs sharedavail nfs_direct_cache 0 0128 301 : tunables 120 60 8 : slabdata 0 0 0 nfs_write_data36 44704 112 : tunables 54 27 8 : slabdata 4 4 0 nfs_read_data 32 33704 112 : tunables 54 27 8 : slabdata 3 3 0 nfs_inode_cache0 098441 : tunables 54 27 8 : slabdata 0 0 0 nfs_page 0 0128 301 : tunables 120 60 8 : slabdata 0 0 0 rpc_buffers8 8 204821 : tunables 24 12 8 : slabdata 4 4 0 rpc_tasks 8 12320 121 : tunables 54 27 8 : slabdata 1 1 0 rpc_inode_cache0 083241 : tunables 54 27 8 : slabdata 0 0 0 fib6_nodes 5 59 64 591 : tunables 120 60 8 : slabdata 1 1 0 ip6_dst_cache 4 12320 121 : tunables 54 27 8 : slabdata 1 1 0 ndisc_cache1 15256 151 : tunables 120 60 8 : slabdata 1 1 0 ip6_mrt_cache 0 0128 301 : tunables 120 60 8 : slabdata 0 0 0 RAWv6 5 896041 : tunables 54 27 8 : slabdata 2 2 0 UDPLITEv6 0 096041 : tunables 54 27 8 : slabdata 0 0 0 UDPv6 3 496041 : tunables 54 27 8 : slabdata 1 1 0 tw_sock_TCPv6 0 0256 151 : tunables 120 60 8 : slabdata 0 0 0 request_sock_TCPv6 0 0192 201 : tunables 120 608 : slabdata 0 0 0 TCPv6 3 6 179221 : tunables 24 12 8 : slabdata 3 3 0 ext3_inode_cache3649 366076051 : tunables 54 27 8 : slabdata732732 0 ext3_xattr 0 0 88 441 : tunables 120 60 8 : slabdata 0 0 0 journal_handle 4144 24 1441 : tunables 120 60 8 : slabdata 1 1 0 journal_head 16 40 96 401 : tunables 120 60 8 : slabdata 1 1 0 revoke_table 2202 16 2021 : tunables 120 60 8 : slabdata 1 1 0 revoke_record
