Bug#971812: gimp cannot be started because of dependency on wrong version of libgegl-0.4-0 package
Package: gimp Version: 2.10.8-2 Severity: grave Justification: renders package unusable In the curent state of available packages from stable (buster) the program GIMP cannot be used. After start it shows following message: "GEGL operation missing! GIMP requires the GEGL operation "gegl:seamless-clone". This operation cannot be found. Check your GEGL install and ensure it has been compiled with any dependencies required for GIMP." and ends. If started from command line, then following additional error message is produced to the console: "$ gimp GEGL-Message: 20:38:16.980: Fehler beim Laden von Modul »/usr/lib/x86_64-linux- gnu/gegl-0.4/seamless-clone.so«: /usr/lib/x86_64-linux-gnu/libgegl-sc-0.4.so: undefined symbol: __exp_finite " This bug has been already reported as a bug https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=968342 and was closed with the statement the dependency has to be used on libgegl-0.4-0 where the problem has been fixed, but the problem is, such version is not available on stable - buster, or even buster- backports. It breaks the basic rule, the stable packages have to depend only on stable packages. The todays stable (buster) version of libgegl-0.4-0 which is 0.4.12-2, does not contain the functionality, needed by the current stable version of gimp (2.10.8-2), what means the dependency in this gimp package version is defined ina wrong way, it should be defined like (>= 0.4.18-1) and not, like defined (>= 0.4.12). neither gimp, not libgegl-0.4-0 cannot be in the current stable version downgraded, which seems to be the reason, why the software after update of the stable system renders to be unbusable for everybody who keeps strictly on stable releases. Proposed solution: move the library libgegl-0.4-0 of version >= 0.4.18-1 from testing to stable or buster-backports... I cannot imagine, we cannot use GIMP software for the next 2 years until bullseye becomes stable. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE, TAINT_AUX Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs:en_US:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp depends on: ii gimp-data2.10.8-2 ii libaa1 1.4p5-46 ii libbabl-0.1-00.1.62-1 ii libbz2-1.0 1.0.6-9.2~deb10u1 ii libc62.31-3 ii libcairo21.16.0-4 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgcc-s1 [libgcc1] 10.2.0-9 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgegl-0.4-00.4.12-2 ii libgexiv2-2 0.10.9-1 ii libgimp2.0 2.10.8-2 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgs9 9.27~dfsg-2+deb10u4 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b2.3.1-1 ii libheif1 1.3.2-2~deb10u1 ii libilmbase23 2.2.1-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii liblzma5 5.2.4-1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1.3.0-2.1 ii libopenexr23 2.2.1-4.1+deb10u1 ii libopenjp2-7 2.3.0-2+deb10u1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpangoft2-1.0-01.42.4-8~deb10u1 ii libpng16-16 1.6.36-6 ii libpoppler-glib8 0.71.0-5 ii librsvg2-2 2.44.10-2.1 ii libstdc++6 10.2.0-9 ii libtiff5 4.1.0+git191117-2~deb10u1 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2+b1 ii libwmf0.2-7 0.2.8.4-14 ii libx11-6 2:1.6.7-1+deb10u1 ii libxcursor1 1:1.1.15-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1+deb10u1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gimp recommends: ii ghostscript 9.27~dfsg-2+deb10u4 Versions of packages gimp suggests: pn gimp-data-extras pn gimp-help-en | gimp-help pn gimp-python ii gvfs-backends 1.38.1-5 ii libasound21.1.8-1 -- no debconf information
Bug#955139: calendar-google-provider: Missing build of package for thunderbird/lightning versions 1:65.* and 1:68.*
Package: calendar-google-provider Version: 1:60.9.0-1~deb10u1 Severity: grave Justification: renders package unusable There is missing build of the package for thunderbird/lightning of current versions 1:65.* and 1:68.* what makes the package unusable with any version of the given tools higher than 1:60.*. It also prevents the thunderbird/lightning from upgrade from this older version. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs:en_US:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages calendar-google-provider depends on: ii lightning 1:60.9.0-1~deb10u1 calendar-google-provider recommends no packages. calendar-google-provider suggests no packages. -- no debconf information
Bug#904074: libkscreenlocker5: After dehibernation no login dialogue is shown, user cannot unlock dehibernated session
Package: libkscreenlocker5 Version: 5.8.6-2 Severity: important The problem is, after the resume from suspend to disk, the login screen does not appear. Workaround how to log-in again is to press Ctrl-Alt-F1, log in to the text console and kill the process kscreenlocker_greet. Then this process is restarted and the login screen is visible again, after the return to the KDE screen by pressing Alt-F7. The same or very similar bug is reported also in kde 4.11. and has been solved there, can it be this fix has not been included into the KDE 5 branch or the bug has become active again...? See the bug and solution in https://bugs.kde.org/show_bug.cgi?id=327947 This happens not every time, only under some circumstances which I have not been able to track/test exactly, but in the old bug description there is described how this could be probably reproduced. -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/2 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs:en_US:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libkscreenlocker5 depends on: ii kpackagetool5 5.28.1-1 ii libc6 2.24-11+deb9u3 ii libkf5configcore5 5.28.0-2 ii libkf5configgui5 5.28.0-2 ii libkf5coreaddons5 5.28.0-2 ii libkf5crash5 5.28.0-1 ii libkf5declarative55.28.0-1 ii libkf5globalaccel55.28.0-1 ii libkf5i18n5 5.28.0-2 ii libkf5idletime5 5.28.0-1 ii libkf5notifications5 5.28.0-1 ii libkf5package55.28.1-1 ii libkf5quickaddons55.28.0-1 ii libkf5waylandclient5 4:5.28.0-1 ii libkf5waylandserver5 4:5.28.0-1 ii libkf5windowsystem5 5.28.0-2 ii libpam0g 1.1.8-3.6 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5dbus5 5.7.1+dfsg-3+b1 ii libqt5gui55.7.1+dfsg-3+b1 ii libqt5network55.7.1+dfsg-3+b1 ii libqt5qml55.7.1-2+b2 ii libqt5quick5 5.7.1-2+b2 ii libqt5widgets55.7.1+dfsg-3+b1 ii libqt5x11extras5 5.7.1~20161021-2 ii libstdc++66.3.0-18+deb9u1 ii libwayland-client01.12.0-1 ii libwayland-server01.12.0-1 ii libx11-6 2:1.6.4-3 ii libxcb-keysyms1 0.4.0-1+b2 ii libxcb1 1.12-1 ii libxi62:1.7.9-1 Versions of packages libkscreenlocker5 recommends: ii kde-config-screenlocker 5.8.6-2 libkscreenlocker5 suggests no packages. -- no debconf information
Bug#848024: Fails to connect after upgrade to openvpn 2.4
Package: network-manager-openvpn Version: 1.2.8-2 Followup-For: Bug #848024 The bug is still there in the version 1.2.8-2, because the g|UI for the editing of connection properties still generates the invalid option "tls-remote" always if you want to specify the X509 properties. The problem is concretely in the openvpn configuration, tab VPN (openvpn), then click on "Advanced", then switch to the tab TLS settings. As a first control on this tab is the edit field, where you can put the identification for X509 validation (somethng like "C=cz, L=Praha, O=Some Org, CN=someserver.somedomain.cz, emailAddress=somaeddr...@somedomain.cz") But now, instead of the generating openvpn configuration with the option "verify-X509-name" - on the ovpn configuration should be the line with something like verify-x509-name "C=cz, L=Praha, O=Some Org, CN=someserver.somedomain.cz, emailAddress=someaddr...@somedomain.cz" it still generates the old obsolete form tls-remote "C=cz, L=Praha, O=Some Org, CN=someserver.somedomain.cz, emailAddress=someaddr...@somedomain.cz" The only workaround for this I have found is to let the validation field empty, but then you lose the validation possibility. This should be fixed, there should be generated the correct settings verify-x509-name to the generated ovpn configuration instead of todays tls-remote Possibly there should be also extended the edit dialogue, where should be specified the type parameter behind the name parameter of the tag verify-x509-name - according to the openvpn manual, there can be also specified the type of the X509 name, if omitted, then default is used. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/2 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs:en_US:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager-openvpn depends on: ii adduser 3.115 ii libc62.24-11+deb9u1 ii libglib2.0-0 2.50.3-2 ii libnm0 1.6.2-3 ii network-manager 1.6.2-3 ii openvpn 2.4.0-6+deb9u1 network-manager-openvpn recommends no packages. network-manager-openvpn suggests no packages. -- no debconf information
Bug#834834: linux-image-4.6.0-0.bpo.1-amd64: screen flickering on older notebook display (in x-windows)
Package: src:linux Version: 4.6.4-1~bpo8+1 Severity: important Problem occurs on the notebook display only, the attached screen display does no flickering at all with any kernel tried. After the last version of package the flickering is very massive after the boot of the system and start of X-Windows, and does not stop even after chaniging the parameters of the display (resolution). Also if using the kernel 4.5.0 (package linux- image-4.5.0-0.bpo.2-amd64 in version 4.5.4-1~bpo8+1) the flickering occurs, with the older kernel 3.13 (package linux-image-3.13-1-amd64 in version 3.13.10-1) the display works well and no flickering at all can be seen. -- Package-specific info: ** Version: Linux version 4.6.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.6.4-1~bpo8+1 (2016-08-11) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.6.0-0.bpo.1-amd64 root=UUID=db6ab517-0ceb-47fb-9e8d-8ce27468ca23 ro ** Tainted: E (8192) * Unsigned module has been loaded (currently expected). ** Kernel log: [2.658507] ACPI Warning: SystemIO range 0x1028-0x102F conflicts with OpRegion 0x1000-0x1042 (\_SB.C003.C004.C0BC) (20160108/utaddress-255) [2.658689] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [2.658759] ACPI Warning: SystemIO range 0x1130-0x113F conflicts with OpRegion 0x1100-0x113B (\_SB.C003.C004.C0CE) (20160108/utaddress-255) [2.658935] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [2.659002] ACPI Warning: SystemIO range 0x1100-0x112F conflicts with OpRegion 0x1100-0x113B (\_SB.C003.C004.C0CE) (20160108/utaddress-255) [2.659178] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [2.659245] lpc_ich: Resource conflict(s) found affecting gpio_ich [2.660167] leds_ss4200: no LED devices found [2.665170] usb 4-7.4.2: New USB device found, idVendor=09da, idProduct=c10a [2.665233] usb 4-7.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [2.665300] usb 4-7.4.2: Product: USB Mouse [2.665357] usb 4-7.4.2: Manufacturer: A4Tech [2.688728] yenta_cardbus :02:06.0: ISA IRQ mask 0x0c78, PCI irq 18 [2.688792] yenta_cardbus :02:06.0: Socket status: 3006 [2.688852] pci_bus :02: Raising subordinate bus# of parent bus (#02) from #03 to #06 [2.688925] yenta_cardbus :02:06.0: pcmcia: parent PCI bridge window: [io 0x8000-0x8fff] [2.688992] yenta_cardbus :02:06.0: pcmcia: parent PCI bridge window: [mem 0xf420-0xf45f] [2.689060] pcmcia_socket pcmcia_socket0: cs: memory probe 0xf420-0xf45f: [2.689129] excluding 0xf420-0xf423 [2.712049] tifm_core: MMC/SD card detected in socket 0:1 [2.749373] input: PC Speaker as /devices/platform/pcspkr/input/input18 [2.846499] [drm] fb mappable at 0xE00C [2.846561] [drm] vram apper at 0xE000 [2.846618] [drm] size 7258112 [2.846674] [drm] fb depth is 24 [2.846730] [drm]pitch is 6912 [2.848221] fbcon: radeondrmfb (fb0) is primary device [2.874110] Adding 5859324k swap on /dev/sda2. Priority:-1 extents:1 across:5859324k SSFS [2.923056] Console: switching to colour frame buffer device 128x48 [2.925686] radeon :01:00.0: fb0: radeondrmfb frame buffer device [2.936071] [drm] Initialized radeon 2.43.0 20080528 for :01:00.0 on minor 0 [3.027244] input: HP WMI hotkeys as /devices/virtual/input/input19 [3.045816] iTCO_vendor_support: vendor-support=0 [3.046337] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [3.046432] iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0x1060) [3.048918] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [3.056251] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: discard,commit=600 [3.079379] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f: [3.079394] excluding 0xc-0xc 0xe-0xf [3.079410] pcmcia_socket pcmcia_socket0: cs: memory probe 0xa000-0xa0ff: [3.079419] excluding 0xa000-0xa0ff [3.079434] pcmcia_socket pcmcia_socket0: cs: memory probe 0x6000-0x60ff: [3.079443] excluding 0x6000-0x60ff [3.167732] systemd-journald[194]: Received request to flush runtime journal from PID 1 [3.268273] tpm_tis 00:03: TPM is disabled/deactivated (0x7) [3.302959] hidraw: raw HID events driver (C) Jiri Kosina [3.311217] usbcore: registered new interface driver usbhid [3.311219] usbhid: USB HID core driver [3.322558] input: A4Tech USB Mouse as /devices/pci:00/:00:1d.7/usb4/4-7/4-7.4/4-7.4.2/4-7.4.2:1.0/0003:09DA:C10A.0001/input/input20 [3.323918] hid-
Bug#736879: Jessie/stable still contains this bug, no backport... Kwallet password storage completely unusable for me...
Hello, the jessie stable is still on version 1.8.10, so the kwallet does not work at all. So, it seems in kde there is no alternative for storing encrypted passwords with subversion, what is a relly bad situation. Is there planned some backport of the 1.9.2 or 1.9.3 version, which is currently in the testing phase? Artur Linhart smime.p7s Description: Elektronicky podpis S/MIME
Bug#783083: Info received (Bug#783083: bacula-director-common: Bacula director has problems with kernel linux-image-3.16.0-0.bpo.4-amd64 (v3.16.7-ckt7-1~bpo70+1))
I have one new message to this bug, I think this is the bug either in the given new kernel - so it would the mean the package linux-image-3.16.0-0.bpo.4-amd64 (version 3.16.7-ckt9-2~bpo70+1), which I have used, or in the firewall (Sophos UTM 9.x) which acts between both hosts or even somwhere else. I have encountered similar problems also in other services like zabbix or just simple ssh. The same problems seem to be if I have used the package with kernel 3.2.0. The firewall receives somehow packets, which are not correctly recognized by the IP filtering rules what leads to the DROP of them even if the filter is explicitely specified on the source/destination address. By the usage of the older kernel the traffic runs through firewall without problems. The firewall lets the packet through only in the case neither source nor destination address is specified in the filter. I have seen never in my life such behavior. But I have tracked it only on one hosts - the wrong thing is, there are other 17 where I did not encounter any problems, even by usage of the same kernel... In every case this problem seems to be no problem of bacula at all and I think also no problem of postgresql client. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783083: bacula-director-common: Bacula director has problems with kernel linux-image-3.16.0-0.bpo.4-amd64 (v3.16.7-ckt7-1~bpo70+1)
Hello Carsten, in the attachments you can find the results. But it seems to be restarted correctly. I have tested it also with the brand new kernel and the problem still persist. I cannot recognize any ps output differences between the 3.x kernels (wrong functionality) and 2.x kernels (works well). But I have found another clue - there is a significant difference in the director start log after the restart, I did not checked the debug messages during the correct behavior with kernel 2.x. It seems the director is not able to connect to pg database, so that's the reason why the port 9101 is not opened. If you look on the two attachedn director start logs, then in the case of the working 2.x kernel configuration the DB is connected properly and some information is read from DB, in the case of the problematic kernel 3.x the log of the debug messages ends with the message about the first init: 2.x debug messages: 24-Apr-2015 19:45:01 bacula-dir: dir_plugins.c:162-0 No dir plugin dir! 24-Apr-2015 19:45:01 bacula-dir: bpipe.c:367-0 Run program returning 0 24-Apr-2015 19:45:01 bacula-dir: bpipe.c:367-0 Run program returning 0 24-Apr-2015 19:45:01 bacula-dir: postgresql.c:1120-0 db_init_database first time [ ok 24-Apr-2015 19:45:02 bacula-dir: postgresql.c:241-0 pg_real_connect done 24-Apr-2015 19:45:02 bacula-dir: postgresql.c:243-0 db_user=bacula_dir db_name=bacula_db db_password=bacula_password . root@alg-vun-netmng:~# 24-Apr-2015 19:45:02 alg-vun-netmng-dir: pythonlib.c:102-0 No script dir. prog=DirStartUp 24-Apr-2015 19:45:02 alg-vun-netmng-dir: bnet_server.c:95-0 Addresses host[ipv4:0.0.0.0:9101] 24-Apr-2015 19:45:02 alg-vun-netmng-dir: job.c:1331-0 wstorage=bacula-sd 24-Apr-2015 19:45:02 alg-vun-netmng-dir: job.c:1340-0 wstore=bacula-sd where=Job 3.x debug messages: 24-Apr-2015 19:51:31 bacula-dir: dir_plugins.c:162-0 No dir plugin dir! 24-Apr-2015 19:51:31 bacula-dir: bpipe.c:367-0 Run program returning 0 24-Apr-2015 19:51:31 bacula-dir: bpipe.c:367-0 Run program returning 0 24-Apr-2015 19:51:31 bacula-dir: postgresql.c:1120-0 db_init_database first time . ok root@alg-vun-netmng:/home/alglogin# Generally I think, the postgres client has no problems with the connections in the new kernel environment, so I gues, the problem must be somwhere in bacula-director-pg package... Dne 23.4.2015 v 13:12 Carsten Leonhardt napsal(a): > Hi Artur, > > could you please send the output of > > ps xuaw | grep bacula-dir > > - after reboot > - after the connect with bat > - after /etc/init.d/bacula-dir stop > - after /etc/init.d/bacula-dir start > > Sounds like the director might be hanging, it could be interesting to > see if the PID changes and what state the process might be in. root@alg-vun-netmng:~# ps xuaw | grep bacula-dir bacula2324 0.0 0.9 120132 4976 ?Ssl 19:37 0:00 /usr/sbin/bacula-dir -c /etc/bacula/bacula-dir.conf -u bacula -g bacula -d 150 -dt root 2344 0.0 0.1 4048 528 ?Ss 19:37 0:00 startpar -f -- bacula-director root 2907 0.0 0.1 10020 924 pts/1S+ 19:42 0:00 grep bacula-dir root@alg-vun-netmng:~# ps xuaw | grep bacula-dir bacula2324 0.0 0.9 128348 5152 ?Ssl 19:37 0:00 /usr/sbin/bacula-dir -c /etc/bacula/bacula-dir.conf -u bacula -g bacula -d 150 -dt root 2344 0.0 0.1 4048 528 ?Ss 19:37 0:00 startpar -f -- bacula-director root 2913 0.0 0.1 10020 928 pts/1S+ 19:43 0:00 grep bacula-dir root@alg-vun-netmng:~# ps xuaw | grep bacula-dir root 2945 0.0 0.1 10016 920 pts/1S+ 19:44 0:00 grep bacula-dir root@alg-vun-netmng:~# ps xuaw | grep bacula-dir bacula2959 0.0 0.9 123872 5000 ?Ssl 19:45 0:00 /usr/sbin/bacula-dir -c /etc/bacula/bacula-dir.conf -u bacula -g bacula -d 150 -dt root 2990 0.0 0.1 10016 920 pts/1S+ 19:46 0:00 grep bacula-dir root@alg-vun-netmng:~# /etc/init.d/bacula-director start [] Starting Bacula Director...: bacula-dirbacula-dir: dird.c:185-0 Debug level = 150 24-Apr-2015 19:45:01 bacula-dir: dird.c:185-0 Debug level = 150 24-Apr-2015 19:45:01 bacula-dir: inc_conf.c:556-0 set wildbase 1bd99e8 size=1 *~ 24-Apr-2015 19:45:01 bacula-dir: inc_conf.c:556-0 set wildbase 1bda068 size=1 *~ 24-Apr-2015 19:45:01 bacula-dir: inc_conf.c:556-0 set wildbase 1bda6b8 size=1 *~ 24-Apr-2015 19:45:01 bacula-dir: jcr.c:140-0 read_last_jobs seek to 192 24-Apr-2015 19:45:01 bacula-dir: jcr.c:147-0 Read num_items=10 24-Apr-2015 19:45:01 bacula-dir: dir_plugins.c:160-0 Load dir plugins 24-Apr-2015 19:45:01 bacula-dir: dir_plugins.c:162-0 No dir plugin dir! 24-Apr-2015 19:45:01 bacula-dir: bpipe.c:367-0 Run program returning 0 24-Apr-2015 19:45:01 bacula-dir: bpipe.c:367-0 Run program returning 0 24-Apr-2015 19:45:01 bacula-dir: postgresql.c:1120-0 db_init_database first time [ ok 24-Apr-2015 19:45:02 bacula-dir: postgresql.c:241-0 pg_real_connect done 24-Apr-2015 19:45:02 bacula-dir: postgresql.c:243-0 db_user=bacula_dir db_name=bac
Bug#783083: [pkg-bacula-devel] Bug#783083: bacula-director-common: Bacula director has problems with kernel linux-image-3.16.0-0.bpo.4-amd64 (v3.16.7-ckt7-1~bpo70+1)
Hello, more detailed description of my situation and conclustions to which I came: The director runs on virtual server. I have connected to bacula director on this server with the BAT (Administration Console) from another host. The initial connection was OK, there came the message from the director to BAT about the successfull establishment of the connection. But in the next second, when there are sent internally other commands to director for populating the masks of BAT, the BAT has frozen, waiting endlesly on the remote director. I have restarted the director service on the server and from this time point the director did not start the listening port - so netstat -a -n -p shows no "bacula-director" process even if /etc/init.d/bacula-director status reports the process is running and is also wisible with the htop/top/ps statements - the process does not open the desired port 9101 for listening, in the list of ports can be seen only the 9102 for bacula-fd, which also runs on the server with the director. Even after the next restart /etc/init.d/bacula-director restart everything looks well and there are no error messages in the logs or on the screen (I guess, I had the debug level 150 turned on), but netstat still reports the TCP Port 9101 is not open. After the restart of the whole virtual machine (still with the newer kernel) I have seen the bacula-director on TCP 9101 in netstat, but after the connection from BAT this was the same story again and then after the restart only of the director service the director never starts to listen on 9101 again, even if restarted repeatedly or just shut down and started. Only the restart of the whole virtual machine made it possible to see the bacula-director process in netstat on TCP 9101 If I have simply shut down the virtual machine and specified other older kernel for the virtual machine, then the director with this old kernel behaves correctly according to the BAT, and also the restarts lead to correct behavior, port 9101 is always open like it should be if the service is running. with best regards, Artur Linhart Dne 21.4.2015 v 22:30 Geert Stappers napsal(a): > On Tue, Apr 21, 2015 at 09:38:11PM +0200, Artur Linhart wrote: >> Package: bacula-director-common >> Version: 5.2.6+dfsg-9 >> Severity: normal >> >> The director is not able under some circumstances communicate with Bacula >> communication console, after (service) restart it is not able to listen on >> the >> specified configured port even if the service seems to be running. > What to do to reproduce the "not able to listen"? > > > Please elaborate. > > > > Groeten > Geert Stappers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783083: bacula-director-common: Bacula director has problems with kernel linux-image-3.16.0-0.bpo.4-amd64 (v3.16.7-ckt7-1~bpo70+1)
Package: bacula-director-common Version: 5.2.6+dfsg-9 Severity: normal The director is not able under some circumstances communicate with Bacula communication console, after (service) restart it is not able to listen on the specified configured port even if the service seems to be running. The problem can be related also to the package bacula-director-pgsql (version 5.2.6+dfsg-9), there is not clear if it has something to dowith this package or bacula-director-common, I was not able to test it on more backend databases. The problem occurs on virtual DomU instances of Debian within xen environment. If just the old kernel is used (from package linux-image-2.6.32-5-xen- amd64,version 2.6.32-48squeeze6) then the director runs without problems - after rebooting with other kernel the bacula-director works without problems. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/4 CPU cores) Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (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#710855: gdk-pixbuf: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache'
Just the same error like Justin wrote during the regular update of the new updates on jessie/sid version -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596419: [xen] BUG at drivers/scsi/aacraid/aachba.c:2825
> Thanks for reporting this and sorry for the long quiet. Can you > reproduce this using a sid kernel for the dom0? I think the only > packages that should be needed for this test from outside squeeze are > the kernel image itself, linux-base, and initramfs-tools. > > Jonathan Hello, Jonathan, unfortunatelly, I have changed the SW RAID to HW RAID and the server is already used in production with Debian Squeeze, so I cannot try to reproduce the problems at this time... But I will try to do it by the next server... Thanx for information, Artur -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631476: zabbix-agent: Deinstallation of package does not work correctly if "purge" is selected-prevents reinstallation
Package: zabbix-agent Version: 1:1.8.2-1squeeze2 Severity: important The problem is, after the package is purged in aptitude,it removes correctly the /etc/zabbix folder or the content of this folder, but it seems still there are some files left. If after purge the package should be reinstalled again, then there come some messages "not copying deleted file /etc/zabbix/zabbix-agent.conf" and "not copying deleted file /etc/zabbix/zabbix-agentd.conf" and really such files are not copied there, what causes the zabbix-agent daemon is not started, causes an error and the package stays in uncofigured state. The only fix Ihave found is to: 1. Deinstall the package (not purge it) 2. restore both missing files above in /etc/zabbix from backup 3. install the package again 4. Then it works So, there will be an error in purge-deinstallation process and possibly also in new-install process for this package. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages zabbix-agent depends on: ii adduser 3.112+nmu2 add and remove users and groups ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libldap-2.4-2 2.4.23-7 OpenLDAP libraries ii libopenipmi02.0.16-1.2 Intelligent Platform Management In ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii ucf 3.0025+nmu1 Update Configuration File: preserv zabbix-agent recommends no packages. Versions of packages zabbix-agent suggests: ii logrotate 3.7.8-6Log rotation utility -- 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#622096: xen-utils-common: error in script "block" by checking loop device sharing prevents DomU from start
Package: xen-utils-common
Version: 4.0.0-1
Severity: important
The script /etc/xen/scripts/block contains an error in the part which
is checking the sharing of the already created loop devices. This error
leads in the case of somespecific file inode values
to the wrong report of the loop device as being already used
and causes then the domain could not be started with such device at all,
there is only displayed the message
File {filename} is loopback-mounted through {loop1devname}, which is mounted in
a guest domain {domainname}, and so cannot be mounted now.
This error occurs in the case the inode of the given file
is the substring of the another inode of the another file used also
as loop device (for example as a block device in different DomU)
Concretely, in my case I have one file with inode value 13 and the second
with inode value 1356984
In this case the part of the script "block":
shared_list=$(losetup -a | grep ' \[0*'${dev}'\]:'${inode} |
does not work correctly, it resolves the file with inode 1356984 which is
already
used like the file with inode 13 and prevents the usage of the file with inode
13,
thinking it is already used.
Also, the check of the sharing could generally cause following error:
It would also not work anymore in the case there are multiple inodes,
starting with "13" - then the given statement resolves multiple loop devices, so
even if the device "13" would be already used, the checking of the sharing
reports multiple
loop devices (loop device corresponding with all such inodes like 1356984, 13,
1369336)
what leads in the next processing in function check_sharing to the wrong
evaluation and
report the device 13 can be used again.
The solution of this problem is (at least in my case it helped, but I think this
could be a general solution of the output of "losetup -a" is always the same)
to modify the statement above like follows:
shared_list=$(losetup -a | grep ' \[0*'${dev}'\]:'"${inode} " |
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages xen-utils-common depends on:
ii gawk1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr
ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii udev164-3/dev/ and hotplug management daemo
ii xenstore-utils 4.0.1-2 Xenstore utilities for Xen
xen-utils-common recommends no packages.
xen-utils-common suggests no packages.
-- Configuration Files:
/etc/default/xendomains changed [not included]
/etc/init.d/xend changed [not included]
/etc/xen/scripts/block changed [not included]
/etc/xen/scripts/network-bridge changed [not included]
/etc/xen/scripts/qemu-ifup changed [not included]
/etc/xen/scripts/vif-bridge changed [not included]
/etc/xen/scripts/vif-common.sh changed [not included]
/etc/xen/xend-config.sxp changed [not included]
-- 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#603802: linux-image-2.6.32-5-xen-amd64: DomU not really resumed (hangs) after restore from disk after Dom0 restart
One more correctlion to my last message - I have figured out, some instances have had still the kernel from version 2.6.32-21 what was the reason why they started correctly... So it seems the effect can be seen on all DomUs with the kernel from package version 2.6.32-27 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603802: linux-image-2.6.32-5-xen-amd64: DomU not really resumed (hangs) after restore from disk after Dom0 restart
Yes, it seems to be the same bug. I have figured out, I made a mistake, the statement "xm unpause" does not help. But I have a little bit other behavior - I have more DomUs and some from them were restored and started correctly, some not. I cannot recognize any general difference between them... Unfortunately, I will not have the chance to test the patch directly, I use vanilla kernel from the package only... -Original Message- From: Timo Juhani Lindfors [mailto:timo.lindf...@iki.fi] Sent: Wednesday, November 17, 2010 2:11 PM To: Artur Linhart Cc: 603...@bugs.debian.org Subject: Re: Bug#603802: linux-image-2.6.32-5-xen-amd64: DomU not really resumed (hangs) after restore from disk after Dom0 restart Artur Linhart writes: > If the kernel is used for paravirtual DomU, then the DomU is > normally started orshutdown. Ifthe xm save and xm restore is invoked > explicitely,then the DomU also restores normally. Only in the case > the DomU is restored automatically via xendomains script facility on > Dom0 start it is restored, so visible in the list This is most likely a duplicate of my bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602273 Can you please test the patch that is included in that bug report? __ Informace od NOD32 5626 (20101117) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603802: Acknowledgement (linux-image-2.6.32-5-xen-amd64: DomU not really resumed (hangs) after restore from disk after Dom0 restart)
Additional info - I figured out, the domain is paused only, so after calling of xm unpause the domain continues to respond and to run. So, maybe it is not a bug, but a feature? If it is so, then there should be a possibility to start the domain immediatelly. One more remark: It does not affect the fully virtualized domains, only the paravirtualized domains. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603802: linux-image-2.6.32-5-xen-amd64: DomU not really resumed (hangs) after restore from disk after Dom0 restart
Package: linux-2.6 Version: 2.6.32-27 Severity: important If the kernel is used for paravirtual DomU, then the DomU is normally started orshutdown. Ifthe xm save and xm restore is invoked explicitely,then the DomU also restores normally. Only in the case the DomU is restored automatically via xendomains script facility on Dom0 start it is restored, so visible in the list (xm list), but also after a lot of time it does not consume any processor time (shows always 0.0 as consumed processor time) and after switch to the instance (xm console) the console is not responding to any key. The same problem was (at least) also in the package version 2.6.32-25 and 2.6.32-23. If starting the same DomU with kernel from package version 2.6.32-21, then it works correctly -- Package-specific info: ** Version: Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-27) (m...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 17:04:10 UTC 2010 ** Command line: root=/dev/sda1 ro console=tty0 vga=773 swiotlb=65536 ** Not tainted ** Kernel log: [ 78.883733] vif8.1: no IPv6 routers present [ 79.151732] vif8.2: no IPv6 routers present [ 80.575300] device vif10.0 entered promiscuous mode [ 80.579516] perbr: port 5(vif10.0) entering learning state [ 83.099729] locbr: port 1(vif8.1) entering forwarding state [ 83.435229] tap8.1: no IPv6 routers present [ 83.487745] perbr: port 1(vif8.2) entering forwarding state [ 83.655218] tap8.2: no IPv6 routers present [ 83.791158] alloc irq_desc for 1210 on node 0 [ 83.791162] alloc kstat_irqs on node 0 [ 84.043221] tap8.0: no IPv6 routers present [ 84.131388] device tap10.0 entered promiscuous mode [ 84.132646] perbr: port 6(tap10.0) entering learning state [ 84.181362] alloc irq_desc for 1209 on node 0 [ 84.181365] alloc kstat_irqs on node 0 [ 84.607717] vif9.0: no IPv6 routers present [ 84.699718] vif9.2: no IPv6 routers present [ 84.905506] vif9.1: no IPv6 routers present [ 85.075718] vif9.3: no IPv6 routers present [ 86.209157] vif9.6: no IPv6 routers present [ 86.212755] vif9.4: no IPv6 routers present [ 86.239161] vif9.5: no IPv6 routers present [ 88.245200] locbr: port 2(tap8.1) entering forwarding state [ 88.259224] perbr: port 2(tap8.2) entering forwarding state [ 88.647215] tap9.2: no IPv6 routers present [ 88.983212] tap9.1: no IPv6 routers present [ 89.264206] tap9.6: no IPv6 routers present [ 89.275208] tap9.3: no IPv6 routers present [ 89.339202] tap9.0: no IPv6 routers present [ 89.451215] perbr: port 3(vif9.0) entering forwarding state [ 89.519208] devhazbr: port 1(vif9.1) entering forwarding state [ 89.555234] tap9.5: no IPv6 routers present [ 89.560204] tap9.4: no IPv6 routers present [ 89.599212] devsafebr: port 3(vif9.2) entering forwarding state [ 89.967706] tsthazbr: port 1(vif9.3) entering forwarding state [ 90.147225] tstsafebr: port 1(vif9.4) entering forwarding state [ 90.303212] prodhazbr: port 1(vif9.5) entering forwarding state [ 90.513625] prodsafebr: port 6(vif9.6) entering forwarding state [ 91.207274] vif10.0: no IPv6 routers present [ 93.451213] perbr: port 4(tap9.0) entering forwarding state [ 93.463200] devhazbr: port 2(tap9.1) entering forwarding state [ 93.475204] devsafebr: port 4(tap9.2) entering forwarding state [ 93.488702] tsthazbr: port 2(tap9.3) entering forwarding state [ 93.665415] tstsafebr: port 2(tap9.4) entering forwarding state [ 93.675194] prodhazbr: port 2(tap9.5) entering forwarding state [ 93.675199] prodsafebr: port 7(tap9.6) entering forwarding state [ 94.351238] tap10.0: no IPv6 routers present [ 95.580705] perbr: port 5(vif10.0) entering forwarding state [ 99.127185] perbr: port 6(tap10.0) entering forwarding state [ 188.551522] prodsafebr: port 2(vif4.0) entering disabled state [ 188.567361] prodsafebr: port 2(vif4.0) entering disabled state [ 191.152151] device vif11.0 entered promiscuous mode [ 191.156126] prodsafebr: port 2(vif11.0) entering learning state [ 192.262854] blkback: ring-ref 8, event-channel 8, protocol 1 (x86_64-abi) [ 192.329113] blkback: ring-ref 9, event-channel 9, protocol 1 (x86_64-abi) [ 201.855967] vif11.0: no IPv6 routers present [ 206.154960] prodsafebr: port 2(vif11.0) entering forwarding state [ 758.603354] psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away. [ 760.095479] psmouse.c: resync failed, issuing reconnect request [ 1038.325725] prodsafebr: port 2(vif11.0) entering disabled state [ 1038.337513] prodsafebr: port 2(vif11.0) entering disabled state [ 1040.199589] device vif12.0 entered promiscuous mode [ 1040.203589] prodsafebr: port 2(vif12.0) entering learning state [ 1041.523037] blkback: ring-ref 770, event-channel 9, protocol 1 (x86_64-abi) [ 1041.594397] blkback: ring-ref 771, event-channel 10, protocol 1 (x86_64-abi) [ 1050.517183] vif12.0: no IPv6 routers present [ 1055.201170] prodsafebr: port 2(vif12.0) enterin
Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup)
>-Original Message- >From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] >Sent: Monday, September 20, 2010 6:08 PM >To: Artur Linhart - Linux communication >Cc: 'Ian Campbell'; 596...@bugs.debian.org >Subject: Re: Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: >causes a system >hangup by the shutdown of the system, aacraid (sw raid) involved in hangup) > >> So, it worked if I have specified in Dom0 in the "baloon" mode by omitting >> the specification of dom0_mem or, if dom0_mem is specified then also the >> swiotlb=65536 must be specified. > >Wow. That implies that AACRAID uses quite a lot of buffers, and looking at the >driver >there are a bunch of quirks where it can only do DMA up to 2GB, so that would >explain >why it relies on SWIOTLB that much. Unfortunatelly I did not tried to raise dom0_mem higher than 2 GB :-(. > >Based on what Ian analyzed it really looks that we just ran out of DMA buffers >and >the driver didn't try to retry but just bails out. > >We can narrow down who is using so many buffers by using the attached debug >module >that when loaded will print out who is using what buffers if >CONFIG_DMA_API_DEBUG=y is set. > >But the proper workaround is the one you discovered - either raise the SWIOTLB >buffer >or raise the memory allocated for Dom0. > >> >> I have noticed one interesting behavior - during the successfull suspension >> of the domains during the shutdown the first one which is beeing suspended >> writes very fast three "dots", then it stops to write the dots for some time >> and then agfter some time very fast a lot of (possibly also all remaining) >> "dots" are written on the screen. By the next suspensions the suspension >> works continuously dot-by-dot smoothly without any delays. It looks like it >> waits for something during the first suspension (memory allocation?). > >That usually means that is stuck waiting for the disks to write out all the >data. OK, I thought it too, but in the case if I omitted dom0_mem or specified the higher swiotlb this behaved differently and I think, it should behave in the same way, isn't it? At least I would guess it so... >> >> Generally, it is for me very surpsrising, how the aacraid module works, I am >> no C or kernel developer but I would expect something like this cannot >> happen - the module should allocate its necessary memory in the start or, I >> would understand there can fail some specific read or write operation if the >> sw raid has not enough memory to execute them, but I would never expect this >> will lead to the hangup and freeze of the whole system. The probability of > > Well, to be honest, we engineers aren't known for testing all of the failure > paths > as well as we should. That is why folks like you are quite helpful in finding > bugs :-) I am always very pleased to have the possibility to help You all who are doing such a great job at least with some small piece of work - even if it did cost me unexpectedly much time :-) I actually began with the usage of the HW RAID on that server instead of SW raid - from other reasons. But at this time I still have the HDD with the SW raid configuration and I would be able to test something, if You have some ideas or want to let me test something concrete on my configuration. If not, I want to remove the software raid sometimes in the next week completely because I need this HDD, so let me know till that time, if there is something You would need to test - I do not know, how difficult would it be for You to reproduce the error on other machine(s). I think it should not be so difficult but who knows -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup)
Hello, Ian, your theory with the out-of-memory seems to be the step into the right direction. It looks like the problems did not really start with the instalaltion of the new packages, but with the set of the xen kernel parameter dom0_mem=1024M which I made approximatelly at the same time like the upgrades. If I have removed this option now, so Dom0 has complete 12GB for its run and the problem does not occur anymore. Also the domains are suspended correctly after the call of /etc/init.d/xendomains stop Possibly this is also the reason, why I could not reproduce this problem with the non-xen kernel - because in that case the memory also was not reduced to this 1GB, but the complete 12GB memory pool was used withtout any specifications, so possibly the error could not occur as well. Also usage of dom0_mem=2048 is not enough to fix the problem for me. I have tried dom0_mem=2048 but it leads also to the hangup by the shutdown during the domain suspension. Only if I omit the dom0_mem parameter completely at all it works correctly. Free memory after increase of the dom0_mem to 2048M: total used free sharedbuffers cached Mem: 2090832 4480921642740 0 111600 90908 -/+ buffers/cache: 2455841845248 Swap: 999416 0 999416 - so there is basically no problem with the base memory amount, there is enough memory for everything. According to the swiotlb parameter - I have found following lines in kern.log from the previous reboots: Sep 13 17:15:13 alg-puv-xen-1 kernel: [3.105461] xen_swiotlb_fixup: buf=880005711000 size=67108864 Sep 13 17:15:13 alg-puv-xen-1 kernel: [3.126345] xen_swiotlb_fixup: buf=880009771000 size=32768 - (so the 64MB should be there) but the given lines are repeatet there always with the same values, independently on the fact if dom0_mem has been set to 1024M, 2048M or unset completely. After I have specified swiotlb=65536 on the line with the xen kernel then I got in the log the same thing like If I would done nothing (and also the hangups during domain suspension). If I put this parameter to the linux kernel module parameters, then it also did not changed the value in the log: Sep 13 18:15:32 alg-puv-xen-1 kernel: [3.856096] Kernel command line: root=/dev/md0 ro console=tty0 vga=773 swiotlb=65536 Sep 13 18:15:32 alg-puv-xen-1 kernel: [3.856129] PID hash table entries: 4096 (order: 3, 32768 bytes) Sep 13 18:15:32 alg-puv-xen-1 kernel: [3.856512] Initializing CPU#0 Sep 13 18:15:32 alg-puv-xen-1 kernel: [3.873864] DMA: Placing 128MB software IO TLB between 880005711000 - 88000d711000 Sep 13 18:15:32 alg-puv-xen-1 kernel: [3.873868] DMA: software IO TLB at phys 0x5711000 - 0xd711000 Sep 13 18:15:32 alg-puv-xen-1 kernel: [3.873871] xen_swiotlb_fixup: buf=880005711000 size=134217728 Sep 13 18:15:32 alg-puv-xen-1 kernel: [3.915338] xen_swiotlb_fixup: buf=88000d7d1000 size=32768 Sep 13 18:15:32 alg-puv-xen-1 kernel: [3.924636] Memory: 1891528k/2097152k available (3141k kernel code, 432k absent, 205192k reserved, 1905k data, 592k init) But the reboot came through without the crash! :-) Where has to be applied the swiotlb parameter to see some effect of the swiotlb memory change in the logs? So, it worked if I have specified in Dom0 in the "baloon" mode by omitting the specification of dom0_mem or, if dom0_mem is specified then also the swiotlb=65536 must be specified. I have noticed one interesting behavior - during the successfull suspension of the domains during the shutdown the first one which is beeing suspended writes very fast three "dots", then it stops to write the dots for some time and then agfter some time very fast a lot of (possibly also all remaining) "dots" are written on the screen. By the next suspensions the suspension works continuously dot-by-dot smoothly without any delays. It looks like it waits for something during the first suspension (memory allocation?). Generally, it is for me very surpsrising, how the aacraid module works, I am no C or kernel developer but I would expect something like this cannot happen - the module should allocate its necessary memory in the start or, I would understand there can fail some specific read or write operation if the sw raid has not enough memory to execute them, but I would never expect this will lead to the hangup and freeze of the whole system. The probability of data corruption is so increased drastically. And especially by raid1, which is arranged in the most of cases to archieve more data safety :-). With regards, Artur -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup)
Hello, If booting on non-xen kernel, then no problems can be seen. But it is true, exactly the same asction cannot be tested, the xendomains script can be started only if running under xen and also there had to be some virtual instances to be suspended... If I boot with xen and then shut down the virtual instances, and then reboot the computer, the hangup does not occur. Only in the case the suspend during /etc/init.d/xendomains stop Happens, the crash comes after some time. Under the non-xen I have also tested the cration of the larger amount of the data by the usage of dd or cp (of cca 5 GiB of data, which is 2 times more than all virtual instances together have memory which has to be written to the raid), but nothing strange happens, everything works. I even tried to write the files to the same location like xendomains writes the memory snapshots (it is on md1 raid, the system itself is installed on md0) but everything seems to be working fine without xen kernel. Finally I booted the xen kernel again and just tried to perform a heavy operations on the raid1 - I have generated the hangup induring some seconds and ater reboot again. In the fiorst case I have started just the dd of the 5 GB data bs=1M count=5000 on the first screen and then switched to the second screen and here simply started aptitude. In the second case (in this case the resync of the array from the previous crash was running) I have tried to start paralely two dd's on two screns. It was no problem for some time, then I tried to start aptitude in the third screen, it caused also nothing. I returnd back to screen 2 and pressed twice ctrl-C what lead to hangup of the system again. So, it seems to be very probable this problem has nothing special to do with xendomains script or any xen utility, but is just the question of running under xen kernel and performing more complex or heavy operations on the raid array... My configuration of the array is: 2 TB SATA disks, both split in the similar way to 1x50GB and 3x650GB raid-partitions, on the first one (md0 - the smallest) is the system, on md1 (size 650 GB) is the raid md1 (here I perform the write operation in the tests and here writes xendomains too) and third array md2 not involved in tests or problems. The fourth 650GB partitions are unused. Regards, Archie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup)
One more remark - the last tests from the previous post were done on the synced array, so there was not other heavy load on it at the time of this last crash. The crash happened also during the xendomains stop before the system shutdown. It happened not immediatelly, but first after sime time (there have been displayed more dots from the suspend process of the given virtual domain before the crash happened) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup)
Even after the downgrade of kernel and of the corresponding files to the version 2.6.32-18 and downgrade of mdadm the problem still persists, so it is not bound specificallz to this package and to this version. I have identified now (after the downgrades to 2.6.30-18) the following initial stack trace (some lines are missing from the top, I think, they were no longer on the screen): [<>] ? bio_alloc_bioset+0x45/0xb7 [<>] ? submit_bio+0xd6/0xf2 [<>] ? md_super_write+0x84/0xb2 [md_mod] [<>] ? xen_restore_fl_direct_end+0x0/0x1 [<>] ? md_update_sb+0x268/0x31e [<>] ? md_check_recovery+0x1e2/0x4b9 [md_mod] [<>] ? raid1d+0x42/0xe0b [raid1] [<>] ? finish_task_switch+0x44/0xaf [<>] ? schedule_timeout+0x2e/0xdd [<>] ? xen_restore_fl_direct_end+0x0/0x1 [<>] ? xen_force_evtchn_callback+0x9/0xa [<>] ? check_events+0x12/0x20 [<>] ? xen_restore_fl_direct_end+0x0/0x1 [<>] ? md_thread+0xf1/0x10f [md_mod] [<>] ? autoremove_wake_function+0x0/0x2e [<>] ? md_thread+0x0/0x10f [md_mod] [<>] ? kthread+0x79/0x01 [<>] ? child_rip+0xa/0x20 [<>] ? int_ret_from_szs_call+0x7/0x1b [<>] ? retinit_restore_args+0x5/0x6 [<>] ? xen-restore-fl-direct-end+0x0/0x1 [<>] ? xen-restore-fl-direct-end+0x0/0x1 [<>] ? child_rip+0x0/0x20 Code: 00 00 c7 46 0c 00 00 00 00 c7 46 10 00 00 00 00 c7 46 14 00 00 00 00 c7 46 18 00 00 00 00 e8 10 63 fa ff 83 f8 00 41 89 c6 7d 04 <0f> 0b eb fe 75 08 45 31 e4 e9 9c 00 00 00 49 8b 7f 58 48 89 eb RIP [<>] aac_build_sgraw+0x51/0x10a [aacraid] RSP --- [ end trace ] --- Now also this stack trace stays on the screen and nothing happens also after very long time (1 hour) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup)
Additional info: Downgrading of the package and kernel image to 2.6.35-18 did not helped, Running of /etc/init.d/xendomains stop Still brought an error, containing also following message: kernel bug /source_amd_xen/drivers/scsi/aacraid/aachba.c:2825! (the dots were not there, there was some other text). Also other downgrades of the hypervisor or qemu-dm did not help. The problem can be also caused by the heavy load of the sw raid - because of the previous crashes, the raid arrays have been under sync if the next crashes happened. The script xendomains suspends the instances to the disk (it is cca 2,5 GB of data), so possible cause could be the heavy load caused by the virtual domain suspension combined with the running resync of the mdadm array. After the array is fully resynced, I try it again with the downgraded mdadm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup)
After further anaysis it seems to be the fact it occurs not by "mdadm stop" but by the call of "xendomains stop" because the hangup occurs not only by the shutdown, but also by the simple call of /etc/init.d/xendomains stop - there are 4 domains running, 3 fully virtualized based on qemu and one paravirtual, also debian squeeze based. It also does not hang up the computer completely, it just freezes the keyboard (also the numlock does not react etc.) and services (for example concurrent ssh connection to the amchine is no longer usefull), but the system itself does still something. There come after some minutes of waiting again and again messages, ending by the following call trace (I hope I made no mistakes in writing it down from monitor): Call Trace: [<>]? smp_call_function_many+0x191/0x1af [<>]? drain_local_pages+0x0/0xd [<>]? smp_call_function+0x20/0x24 [<>]? on_each_cpu+0x10/0x2e [<>]? __alloc_pages_nodemask+0x3f4/0x5ce [<>]? check_events+0x12/0x20 [<>]? new_slab+0x42/0x1ca [<>]? __slab_alloc+0x1f0/0x39b [<>]? sock_alloc_send_pskb+0xbd/0x2d8 [<>]? cap_socket_getpeersec_dgram+0x0/0x6 [<>]? __kmalloc_node_track_caller+0xbb/0x11b [<>]? sock_alloc_send_pskb+0xbd/0x2d8 [<>]? __alloc_skb+0x69/0x15a [<>]? sock_alloc_send_pskb+0xbd/0x2d8 [<>]? pollwake+0x0/0x5b [<>]? unix_stream_sendmsg+0x133/0x2a1 [<>]? sock_aio_write+0xb1/0xbc [<>]? sock_aio_write+0x0/0xbc [<>]? do_sync_readv_writev+0xc0/0x107 [<>]? autoremove_wake_function+0x0/0x2e [<>]? rw_copy_check_nvector+0x6d/0xe4 [<>]? do_readv_writev+0xb2/0x115 [<>]? pvclock_clocksource_read+0x3a/0x70 [<>]? sys_writev+0x45/0x93 [<>]? system_call_fastpath+0x16/0x1b This stack trace comes multiple times (for hour or more before I pushed the power button) and unfortunatelly I cannot see anything more usefull in the error. In the start, there was also some message with aacraid, but It vanished too quickly to see what was written there. -----Original Message- From: Debian BTS [mailto:debb...@busoni.debian.org] On Behalf Of Debian Bug Tracking System Sent: Saturday, September 11, 2010 10:15 AM To: Artur Linhart Subject: Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup) Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to al.li...@bcpraha.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 596...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 596419: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596419 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems __ Informace od NOD32 5441 (20100910) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596422: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: System hangup during shutdown high probable during stopping of mdadm)
This bug is a duplicate of the bug 596419, so it can be closed. -Original Message- From: Debian BTS [mailto:debb...@busoni.debian.org] On Behalf Of Debian Bug Tracking System Sent: Saturday, September 11, 2010 11:06 AM To: Artur Linhart Subject: Bug#596422: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: System hangup during shutdown high probable during stopping of mdadm) Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to al.li...@bcpraha.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 596...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 596422: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596422 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems __ Informace od NOD32 5441 (20100910) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596422: xen-linux-system-2.6.32-5-xen-amd64: System hangup during shutdown high probable during stopping of mdadm
Package: xen-linux-system-2.6.32-5-xen-amd64 Version: 2.6.32-21 Severity: critical Justification: causes serious data loss During the shutdown there comes a system hangup somehow related to aacraid. It first came now after the upgrade of the package to the version specified below. It makes it impossible to shutdown the computer cleanly in 50% of causes, causes damages in the sw raid arrays and hosted file systems and also has a heavy impact on crashed fully virtualized xen domains, because the data are not written to the disk After reboot the resync of the array is necessary. The raid is constructed as 3 partition-mirrors over 2 disks (every disk contains 3 partitions which are mirrored between the disks). On the first mirrored partition resides the system, the other 2 are used for LVM, which seems to ahve nothing to do with the problem. During the hangup there is something written with aacraid and standard hangup mesages are printed out to the screen. I try to write them out by the next occasion. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xen-linux-system-2.6.32-5-xen-amd64 depends on: ii linux-image-2.6.32-5-xen-amd 2.6.32-21 Linux 2.6.32 for 64-bit PCs, Xen d ii xen-hypervisor-4.0-amd64 [xe 4.0.1~rc6-1 The Xen Hypervisor on AMD64 xen-linux-system-2.6.32-5-xen-amd64 recommends no packages. xen-linux-system-2.6.32-5-xen-amd64 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#596419: xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup
Package: xen-linux-system-2.6.32-5-xen-amd64
Version: 2.6.32-21
Severity: critical
Justification: breaks the whole system
On the system is installed sw raid, raid1 is used.
There are 3 RAID1 volumes made as partition mirroring of 3 partitions,
1. for the system (is installed there), 2. and 3. for LVM.
LVM is not involved in this problem.
There is also installed a minimum gnome with the command
aptitude install -R xorg gnome-core gdm
The error came till now twice during the reboot of the system,
last message before the hangup was "Stopping gdm" and then came the error
and complete system hangup, the only way how to proceed was
to perform a cold restart.
I looked into the /etc/rc.? ?={0|1|6} what is the order of the shutdown scripts
used by the shutdown and it seems
it could not to be related to gnome,
because immediatelly after the gdm stop
is performed the "mdadm stop", what causes with very high probability
the system hangup.
It is a very serious problem, I cannot safely reboot the system
After the restart for sure always the raid must be resynchronized, etc.
I will try to get more description of the hangup and attach it to this
bugreport.
The error occurs on HP ProLiant DL320 G6 with E5506 Intel Xeon CPU
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages xen-linux-system-2.6.32-5-xen-amd64 depends on:
ii linux-image-2.6.32-5-xen-amd 2.6.32-21 Linux 2.6.32 for 64-bit PCs, Xen d
ii xen-hypervisor-4.0-amd64 [xe 4.0.1~rc6-1 The Xen Hypervisor on AMD64
xen-linux-system-2.6.32-5-xen-amd64 recommends no packages.
xen-linux-system-2.6.32-5-xen-amd64 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
