Bug#998629: pipewire: No sound devices in Pulseaudio after recent pipewire update in bookworm
Package: pipewire Version: 0.3.39-3 Followup-For: Bug #998629 X-Debbugs-Cc: celeo...@gmail.com Same problem for me. After upgrading from pipewire 0.3.38-2 to 0.3.39-3, audio is not working anymore. Thomas Hager wrote: > Anyway, after downgrading pipewire et al to 0.3.38-2 and rebooting, > sound worked perfectly again on both devices, so I very much assume the > recent update of pipewire caused the issues. I've found that "pipewire-media-session" was reintroduced in sid and installing this instead of "wireplumber", resolves the problem for me. While waiting that it enters testing, the ones that is trying to get its audio working again, could find the following steps simpler than downgrading pulseaudio and its dependencies. - Leave pipewire at the current testing version (0.3.39-3). - Uninstall "wireplumber". - Download pipewire-media-session 0.4.1-1 from sid: https://packages.debian.org/sid/pipewire-media-session - For amd64: dpkg -i pipewire-media-session_0.4.1-1_amd64.deb - Reboot. Cesare. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pipewire depends on: ii init-system-helpers 1.60 ii libpipewire-0.3-modules 0.3.39-3 ii pipewire-bin 0.3.39-3 pipewire recommends no packages. pipewire suggests no packages. -- no debconf information
Bug#978135: cockpit: should recommend sudo
Package: cockpit Version: 233-1 Severity: normal When you login with a normal user, a message on the top of page says that "Web console is running in limited access mode" and the "Turn on administrative access" button is shown. But if you press the button and "sudo" is not installed, this laconic error is shown: - Something went wrong Spawn failed - Retring after installing "sudo", you are asked for your password and then the administrator rights are correctly granted. For this reason I believe that cockpit package should at least recommend "sudo". Happy Christmas! Cesare. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cockpit depends on: ii cockpit-bridge 233-1 ii cockpit-system 233-1 ii cockpit-ws 233-1 Versions of packages cockpit recommends: ii cockpit-networkmanager 233-1 ii cockpit-packagekit 233-1 ii cockpit-storaged233-1 Versions of packages cockpit suggests: pn cockpit-doc pn cockpit-machines pn cockpit-pcp ii xdg-utils 1.1.3-2 -- no debconf information
Bug#977464: virtinst should depend or recommend libosinfo-bin
Package: virtinst Version: 1:3.2.0-3 Severity: normal Virt-install's man page and virt-install --help both say to use the following command to get the list of valid OS variant names: osinfo-query os But this command is provided by libosinfo-bin which is not a dependency of virtinst and so was not installed on my system. I had to search on internet to find the Debian package that provides it. I believe it should be at least a recommended package. Cesare. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages virtinst depends on: ii e2fsprogs 1.45.6-1 ii genisoimage 9:1.1.11-3.1 ii gir1.2-libosinfo-1.0 1.7.1-1 ii python3 3.9.0-4 ii python3-gi3.38.0-1+b2 ii python3-libvirt 6.1.0-1+b3 ii python3-libxml2 2.9.10+dfsg-6.3+b1 ii python3-requests 2.24.0+dfsg-1 Versions of packages virtinst recommends: ii libvirt-clients 6.9.0-1+b2 ii qemu-utils 1:5.1+dfsg-4+b2 pn virt-viewer Versions of packages virtinst suggests: ii python3-argcomplete 1.8.1-1.3 Versions of packages virtinst is related to: ii libvirt-clients 6.9.0-1+b2 ii libvirt-daemon 6.9.0-1+b2 ii libvirt0 6.9.0-1+b2 ii osinfo-db0.20201119-1 -- no debconf information
Bug#968400: cockpit-ws: Warning on upgrades
Package: cockpit-ws Version: 225-1 Severity: normal Hello. For several cockpit releases, on every package upgrade there are two repeated messages: -- Setting up cockpit-ws (225-1) ... Warning: The home dir /nonexisting you specified can't be accessed: No such file or directory The system user `cockpit-ws' already exists. Exiting. Warning: The home dir /nonexisting you specified can't be accessed: No such file or directory The system user `cockpit-wsinstance' already exists. Exiting. -- Leaving behind the cockpit-ws user already exists message (I guess it could be silenced with a test), the /nonexisting warning is what caught my attention. Not because it doesn't exists but because Debian seems to use a similar but different path for the same purpose. For example on my system I see that: -- # cat /etc/passwd | grep nonexist nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin _apt:x:118:65534::/nonexistent:/bin/false debian-h2o:x:119:135::/nonexistent:/usr/sbin/nologin tcpdump:x:121:140::/nonexistent:/usr/sbin/nologin libvirtdbus:x:999:999::/nonexistent:/usr/sbin/nologin cockpit-ws:x:117:131::/nonexisting:/usr/sbin/nologin cockpit-wsinstance:x:125:142::/nonexisting:/usr/sbin/nologin -- Look, here cockpit is the only one using /nonexisting as home path. I don't know if there are any Debian policies talking about this path and its usage but from what I see, cockpit seems to deviate from the rest of the system. Cesare. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cockpit-ws depends on: ii adduser 3.118 ii glib-networking 2.64.3-2 ii libc6 2.31-3 ii libcrypt1 1:4.4.16-1 ii libglib2.0-02.64.4-1 ii libgnutls30 3.6.14-2+b1 ii libgssapi-krb5-21.17-10 ii libjson-glib-1.0-0 1.4.4-2 ii libkrb5-3 1.17-10 ii libpam0g1.3.1-5 ii libsystemd0 246-2 ii openssl 1.1.1g-1 ii systemd 246-2 cockpit-ws recommends no packages. Versions of packages cockpit-ws suggests: pn sssd-dbus -- no debconf information
Bug#966811: network-manager: unknown keys in /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf
Package: network-manager Version: 1.26.0-1 Severity: normal Running "NetworkManager --print-config" the following messages are printed: --- # WARNING: unknown key 'wifi.cloned-mac-address' in section [device-mac-addr-change-wifi] of file '/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf' # WARNING: unknown key 'ethernet.cloned-mac-address' in section [device-mac-addr-change-wifi] of file '/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf' --- >From NetworkManager.conf(5) seems those keys are valid in a connection section, not in a device section. Cesare. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager depends on: ii adduser 3.118 ii dbus 1.12.20-1 ii libaudit11:2.8.5-3+b1 ii libbluetooth35.50-1.2 ii libc62.31-2 ii libcurl3-gnutls 7.68.0-1+b1 ii libglib2.0-0 2.64.4-1 ii libgnutls30 3.6.14-2+b1 ii libjansson4 2.13.1-1 ii libmm-glib0 1.14.0-0.1 ii libndp0 1.6-1+b1 ii libnewt0.52 0.52.21-4+b1 ii libnm0 1.26.0-1 ii libpam-systemd 245.7-1 ii libpsl5 0.21.0-1.1 ii libreadline8 8.0-4 ii libselinux1 3.1-2 ii libsystemd0 245.7-1 ii libteamdctl0 1.30-1 ii libudev1 245.7-1 ii libuuid1 2.36-1 ii policykit-1 0.105-28 ii udev 245.7-1 ii wpasupplicant2:2.9.0-13 Versions of packages network-manager recommends: ii crda 4.14+git20191112.9856751-1 ii dnsmasq-base [dnsmasq-base] 2.82-1 ii iptables 1.8.5-2 ii modemmanager 1.14.0-0.1 ii ppp 2.4.7-2+4.1+deb10u1 Versions of packages network-manager suggests: pn isc-dhcp-client pn libteam-utils -- Configuration Files: /etc/NetworkManager/NetworkManager.conf changed: [main] plugins=keyfile [ifupdown] managed=false [keyfile] unmanaged-devices=mac:64:70:02:2a:a9:c0;mac:9c:d6:43:00:b0:ea -- no debconf information
Bug#954266: qemu-system-x86: graphical-mode monitor doesn't work
Me too confirm this bug and also what Bernhard has discovered (thank you!): monitor works again if you downgrade libvte-2.91-0 and libvte-2.91-common to version 0.58.3-1. Could be difficult, since that library can have many reverse dependencies. Cesare.
Bug#951436: mate-panel: Clock crashes when adding a location
Package: mate-panel Version: 1.24.0-1 Severity: normal The following steps almost always makes clock applet crash: - Right click on panel's clock - Preferences -> Locations - Add a location and click OK The crash happens as soon I click OK. But the "almost always" in the first sentence is because sometimes it doesn't crash but it does when I add a second location. In other words, here is very easy to trigger this. It doesn't happen if I delete entries. The crash manifests itself with the clock that disappear and a windows that shows up saying: - "Clock" has quit unexpectedly If you reload a panel object, it will automatically be added back to the panel. - If I click on "Reload", the clock reappears and the location that caused the crash is there, saved. In fact sometimes I can see the entry added on the list, in the instant immediately before the crash. Cesare. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mate-panel depends on: ii dconf-gsettings-backend [gsettings-backend] 0.34.0-2 ii libatk1.0-0 2.34.1-1 ii libc62.29-10 ii libcairo21.16.0-4 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-2 ii libglib2.0-0 2.62.4-2 ii libgtk-3-0 3.24.13-1 ii libgtk-layer-shell0 0.1.0-3 ii libice6 2:1.0.9-2 ii libmate-desktop-2-17 1.24.0-1 ii libmate-menu21.24.0-1 ii libmate-panel-applet-4-1 1.24.0-1 ii libmateweather1 1.24.0-1 ii libpango-1.0-0 1.42.4-8 ii librda0 0.0.5-1 ii librsvg2-2 2.46.4-1 ii libsm6 2:1.2.3-1 ii libwnck-3-0 3.32.0-1 ii libx11-6 2:1.6.8-1 ii libxrandr2 2:1.5.1-1 ii mate-desktop 1.24.0-1 ii mate-menus 1.24.0-1 ii mate-panel-common1.24.0-1 ii mate-polkit 1.24.0-1 ii menu-xdg 0.6 mate-panel recommends no packages. mate-panel suggests no packages. -- no debconf information
Bug#950330: libvncclient1: Serious artifacts after upgrading to 0.9.12
On 01/02/20 17:21, Mike Gabriel wrote: can you please test your issue using http://packages.sunweavers.net/debian/pool/main/libv/libvncserver/libvncclient1_0.9.12+dfsg-8~test1_amd64.deb Hello Mike, your package seems to fix the issue. I've tried two connection: (1) TightVNC 2.8.5 (Win7 64 bit) (2) TightVNC 2.8.? (Win7 32 bit) With both I've set Remmina connection to 16 bpp. Also with (1) I've also tried all quality values (poor, medium, good, best) and also 8 bpp and 32 bpp. In all cases, everything looks good. Unfortunately I have no VNC servers to test other than TightVNC 2.8.x under Win7/Win10. Thank you very much. Cesare.
Bug#950330: libvncclient1: Serious artifacts after upgrading to 0.9.12
On 31/01/20 23:00, Mike Gabriel wrote: @Cesare: would you be ok, if I provided you with a binary build of libvncserver outside of the debian.org namespace (via packages.sunweavers.net) for testing? If so, please let me know and I'll provide you with test packages. On the other hand, if you feel confident enough to build a patches libvncserver yourself, you can of course cherry-pick the fix for libvncserver/issues/335 and try a test build yourself. Let me know what you prefer? Hello guys, I've read your messages and these: https://github.com/LibVNC/libvncserver/issues/335 https://gitlab.com/Remmina/Remmina/issues/1824 There are a lot information there and not all are completely clear to me. I just confirm that in Remmina, as a workaround, changing "Color depth" away from "High color (16 bpp)", make corruptions go away: no problem neither with 8 bit nor 32 bit. Mike, I'll be happy to test your deb packages: please provide me the URL when you are ready. I'm just a user, I'm not able to build packages myself, sorry. Cesare.
Bug#950225: libreoffice-writer: Immediate crash lunching mail merge wizard
Package: libreoffice-writer Version: 1:6.4.0-1 Severity: normal The following steps always make LibreOffice crash: - Start Writer with a new empty document - Tools -> Mail Merge Wizard... As soon as I click to start the wizard, LibreOffice closes and the Document Recovery window open up saying: "Due to an error, LibreOffice crashed..." Then the recovery process starts. I've never used the mail merge function before, so I don't know if it worked with previous LibreOffice versions. I've tryed starting LibreOffice from the terminal with this command line: soffice --writer An this is the output: -- javaldx: Could not find a Java Runtime Environment! Please ensure that a JVM and the package libreoffice-java-common is installed. If it is already installed then try removing ~/.config/libreoffice/4/user/config/javasettings_Linux_*.xml Warning: failed to read path from javaldx terminate called without an active exception -- The message "terminate called without an active exception" is printed when the crash happens. I've never installed Java and I prefer to not have to. And searching around I've not found evidence that this function depends on Java: I've read it's written in python. Please, tell me if I'm wrong. Cesare. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libreoffice-writer depends on: ii libabw-0.1-1 0.1.3-1 ii libc62.29-9 ii libe-book-0.1-1 0.1.3-1+b2 ii libepubgen-0.1-1 0.1.1-1 ii libetonyek-0.1-1 0.1.9-2 ii libgcc1 1:9.2.1-25 ii libicu63 63.2-2 ii libmwaw-0.3-30.3.15-2 ii libodfgen-0.1-1 0.1.7-1 ii libreoffice-base-core1:6.4.0-1 ii libreoffice-core 1:6.4.0-1 ii librevenge-0.0-0 0.0.4-6+b1 ii libstaroffice-0.0-0 0.0.6-1 ii libstdc++6 9.2.1-25 ii libuno-cppu3 1:6.4.0-1 ii libuno-cppuhelpergcc3-3 1:6.4.0-1 ii libuno-sal3 1:6.4.0-1 ii libuno-salhelpergcc3-3 1:6.4.0-1 ii libwpd-0.10-10 0.10.3-1 ii libwpg-0.3-3 0.3.3-1 ii libwps-0.4-4 0.4.10-1 ii libxml2 2.9.4+dfsg1-8 ii uno-libs-private 1:6.4.0-1 ii ure 1:6.4.0-1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages libreoffice-writer recommends: ii libreoffice-math 1:6.4.0-1 Versions of packages libreoffice-writer suggests: pn default-jre | java8-runtime | jre pn fonts-crosextra-caladea pn fonts-crosextra-carlito pn libreoffice-base pn libreoffice-java-common Versions of packages libreoffice-core depends on: ii fontconfig 2.13.1-2+b1 ii fonts-opensymbol2:102.11+LibO6.4.0-1 ii libboost-locale1.67.0 1.67.0-17 ii libc6 2.29-9 ii libcairo2 1.16.0-4 ii libclucene-contribs1v5 2.3.3.4+dfsg-1+b1 ii libclucene-core1v5 2.3.3.4+dfsg-1+b1 ii libcmis-0.5-5v5 0.5.2-1 ii libcups22.3.1-2 ii libcurl3-gnutls 7.67.0-2 ii libdbus-1-3 1.12.16-2 ii libdconf1 0.34.0-2 ii libeot0 0.01-5+b1 ii libepoxy0 1.5.4-1 ii libexpat1 2.2.9-1 ii libexttextcat-2.0-0 3.4.5-1 ii libfontconfig1 2.13.1-2+b1 ii libfreetype62.10.1-2 ii libgcc1 1:9.2.1-25 ii libglib2.0-02.62.4-1+b1 ii libgpgmepp6 1.13.1-5 ii libgraphite2-3 1.3.13-11 ii libgstreamer-plugins-base1.0-0 1.16.2-2 ii libgstreamer1.0-0 1.16.2-2 ii libharfbuzz-icu02.6.4-1 ii libharfbuzz0b 2.6.4-1 ii libhunspell-1.7-0 1.7.0-2+b1 ii libhyphen0 2.8.8-7 ii libice6 2:1.0.9-2 ii libicu6363.2-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-4 ii libldap-2.4-2 2.4.48+dfsg-1+b2 ii libmythes-1.2-0 2:1.2.4-3+b1 ii libneon27-gnutls0.30.2-3 ii libnspr42:4.24-1 ii libnss3 2:3.49.1-1 ii libnumbertext-1.0-0 1.0.5-3 ii liborcus-0.15-0 0.15.3-3 ii libpng16-16 1.6.37-1 ii libpoppler820.71.0-6 ii libqrcodegencpp11.5.0-2 ii
Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade
Package: gvfs-fuse Version: 1.42.1-1 Followup-For: Bug #942126 Ok, I confirm that replacing fuse with fuse3, as reported by Bert, make gvfs-fuse works as expected, with /run/user/ID/gvfs/ populated again. So please, consider to tighten gvfs-fuse dependencies on fuse3. And, just to clarify, my other problems with login turns out to be unrelated with fuse. Cesare. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gvfs-fuse depends on: ii fuse3 [fuse] 3.7.0-1 ii gvfs 1.42.1-1 ii libc6 2.29-2 ii libfuse3-33.7.0-1 ii libglib2.0-0 2.62.1-1 gvfs-fuse recommends no packages. gvfs-fuse suggests no packages. -- no debconf information
Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade
Package: gvfs-fuse Followup-For: Bug #942126 Thank you all for the information provided. During these days I've made several tests, but unfortunally I still have login problems that I cannot identify and upgrading to the latest gvfs and fuse3 renders things worse, I don't know exactly why: pam/dbus involved, however. So I'm sorry, but currently I cannot test if upgrading fuse to fuse3 or Mad Horse workaround solves the problem reported. I hope to provide more information soon. Cesare. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gvfs-fuse depends on: ii fuse 2.9.9-2 hi gvfs 1.42.0+really1.38.1-1 ii libc6 2.29-2 ii libfuse2 2.9.9-2 ii libglib2.0-0 2.62.1-1 gvfs-fuse recommends no packages. gvfs-fuse suggests no packages. -- no debconf information
Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade
Package: gvfs-fuse Followup-For: Bug #942126 Hello Simon, sorry if my bug report was a bit scarce of information. I was a bit in hurry when I wrote it. Now I try to remedy... On Thu, 10 Oct 2019 19:44:44 +0100 Simon McVittie wrote: > On Thu, 10 Oct 2019 at 19:24:48 +0200, Cesare Leonardi wrote: > > Every time MATE desktop starts, it mounts several SMB share with a > > command like that: > > gio mount "smb://host/folder" > > By what mechanism does it mount them? This PC is integrated in an Active Directory domain and I login using a domain user. Winbind (from Samba), pam_winbind and nsswitch are involved in this. In my MATE environment I mount some shares from: System -> Preferences -> Personal -> Startup Applications Here I have a startup program for each "gio mount". Before upgrading gvfs to 1.42.1-1, each mounted share was accessible from /run/user/ID/gvfs/. Real example: $ ls -o /run/user/11278/gvfs/ drwx-- 1 BERNI\leonardic0 ago 8 2015 'smb-share:server=gam,share=ced' drwx-- 1 BERNI\leonardic0 giu 8 2017 'smb-share:server=gam,share=driver' Now the gvfs folder is not populated anymore. In my initial report I forgot to add that the journal doesn't apparentely show nothing useful to me. But I've done some more tests and now I suspect that the culprit is fuse3. Upgrading from 1.42.0+really1.38.1-1 to 1.42.1-1 I saw that gvfs-fuse dependencies switched from libfuse2 to libfuse3-3 and the latter suggests "fuse3". Do note that in this bug report I still use fuse2, but these days I've tried to install "fuse3" (that replaces "fuse" 2.9.9): the result was terrible because then logging with my Active Directory user failed, with big slowness on login and in other places. In that situation the journal showed errors from pam_winbind but I don't know how and why it's related to fuse. Since with fuse3 the system was substantially unusable for me, I had to immediately revert to fuse 2.x. Now I've also reverted gvfs to 1.42.0+really1.38.1-1, but let me know if you want me to do some tests or if you need more information: I will upgrade to the latest version for you then I'll revert afterward. Thank you. Cesare. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gvfs-fuse depends on: ii fuse 2.9.9-2 ii gvfs 1.42.0+really1.38.1-1 ii libc6 2.29-2 ii libfuse2 2.9.9-2 ii libglib2.0-0 2.62.1-1 gvfs-fuse recommends no packages. gvfs-fuse suggests no packages. -- no debconf information
Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade
Package: gvfs-fuse Version: 1.42.1-1 Severity: normal Every time MATE desktop starts, it mounts several SMB share with a command like that: gio mount "smb://host/folder" After upgrading gvfs from 1.42.0+really1.38.1-1 to 1.42.1-1 gvfs those commands still works ok, except that /run/user/ID/gvfs/ is now empty and so I cannot access the mount points with application not gvfs-aware. Downgrading the following gvfs packages back to 1.42.0+really1.38.1-1 and logging out/in, solves the problem for me: gvfs gvfs-backend gvfs-common gvfs-daemons gvfs-fuse gvfs-libs Cesare. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gvfs-fuse depends on: ii fuse 2.9.9-2 ii gvfs 1.42.1-1 ii libc6 2.29-2 ii libfuse3-33.7.0-1 ii libglib2.0-0 2.62.1-1 gvfs-fuse recommends no packages. gvfs-fuse suggests no packages. -- no debconf information
Bug#928736: initramfs-tools: With plymouth print misleading resuming from hibernation
Package: initramfs-tools Version: 0.133 Severity: normal When plymouth is installed, every time I power on my notebook the following message is printed on the screen: Resuming from hibernation But I'm not resuming from hibernation, I'm doing a regular boot from power off. Is it possible to show that message only when actually resuming? Or, if it not feaseable, perhaps it's better to remove it completely. I've verified that this message appears when RESUME=auto (my current setup) or when a swap device is specified. It goes away with "none". Cesare. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 28M Sep 1 2018 /boot/initrd.img-4.17.0-3-amd64 -rw-r--r-- 1 root root 29M Dec 16 14:29 /boot/initrd.img-4.18.0-3-amd64 -rw-r--r-- 1 root root 49M Apr 16 06:15 /boot/initrd.img-4.19.0-4-amd64 -rw-r--r-- 1 root root 50M May 9 11:17 /boot/initrd.img-4.19.0-5-amd64 -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/etna2014-root ro quiet splash i915.fastboot=1 -- /proc/filesystems btrfs ext3 ext2 ext4 vfat fuseblk -- lsmod Module Size Used by fuse 122880 1 uas28672 0 usb_storage73728 1 uas rfcomm 86016 4 cls_u3224576 10 sch_htb24576 1 ifb16384 0 cmac 16384 1 bnep 24576 2 ctr16384 6 ccm20480 9 ip6t_rpfilter 16384 1 nls_ascii 16384 1 nls_cp437 20480 1 vfat 20480 1 fat86016 1 vfat nft_chain_nat_ipv6 16384 4 nf_nat_ipv616384 1 nft_chain_nat_ipv6 nft_chain_route_ipv616384 1 ath3k 20480 0 btusb 53248 0 ip6t_REJECT16384 1 intel_rapl 24576 0 nf_reject_ipv6 16384 1 ip6t_REJECT x86_pkg_temp_thermal16384 0 intel_powerclamp 16384 0 btrtl 16384 1 btusb coretemp 16384 0 arc4 16384 2 btbcm 16384 1 btusb mei_wdt16384 0 btintel24576 1 btusb kvm_intel 245760 0 ath9k 135168 0 ath9k_common 20480 1 ath9k bluetooth 643072 32 btrtl,btintel,btbcm,bnep,ath3k,btusb,rfcomm ipt_rpfilter 16384 1 ath9k_hw 483328 2 ath9k_common,ath9k snd_hda_codec_hdmi 57344 1 snd_hda_codec_conexant24576 1 uvcvideo 118784 0 kvm 724992 1 kvm_intel videobuf2_vmalloc 16384 1 uvcvideo snd_hda_codec_generic86016 1 snd_hda_codec_conexant ath36864 3 ath9k_common,ath9k,ath9k_hw mac80211 815104 1 ath9k videobuf2_memops 16384 1 videobuf2_vmalloc videobuf2_v4l2 28672 1 uvcvideo irqbypass 16384 1 kvm crct10dif_pclmul 16384 0 videobuf2_common 53248 2 videobuf2_v4l2,uvcvideo nft_chain_nat_ipv4 16384 4 nf_nat_ipv416384 1 nft_chain_nat_ipv4 crc32_pclmul 16384 0 nf_nat 36864 2 nf_nat_ipv6,nf_nat_ipv4 videodev 212992 3 videobuf2_v4l2,uvcvideo,videobuf2_common ghash_clmulni_intel16384 0 snd_hda_intel 45056 8 media 45056 2 videodev,uvcvideo snd_hda_codec 151552 4 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel efi_pstore 16384 0 intel_cstate 16384 0 drbg 28672 1 asus_nb_wmi28672 0 snd_hda_core 94208 5 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec intel_uncore 135168 0 ansi_cprng 16384 0 cfg80211 761856 4 ath9k_common,ath9k,ath,mac80211 joydev 24576 0 asus_wmi 32768 1 asus_nb_wmi intel_rapl_perf16384 0 snd_hwdep 16384 1 snd_hda_codec sparse_keymap 16384 1 asus_wmi snd_pcm 114688 5 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core nft_chain_route_ipv416384 1 efivars20480 1 efi_pstore serio_raw 16384 0 pcspkr 16384 0 ecdh_generic 24576 2 bluetooth intel_pch_thermal 16384 0 sg 36864 0 snd_timer 36864 1 snd_pcm iTCO_wdt 16384 0 iTCO_vendor_support16384 1 iTCO_wdt mei_me 45056 1 mei 118784 3 mei_wdt,mei_me snd94208 23 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm processor_thermal_device16384 0 rfkill 28672 6 asus_wmi,bluetooth,cfg80211 soundcore 16384 1 snd intel_soc_dts_iosf 16384 1 processor_thermal_device battery
Bug#924553: linux-image-4.19.0-4-amd64: PKCS#7 signature not signed with a trusted key
Package: src:linux Version: 4.19.28-1 Severity: normal With this kernel version (but not with the last 4.19.0-3) journalctl shows many of these messages: PKCS#7 signature not signed with a trusted key A lot of such messages can also be seen on the early booting phase. Also I noticed that, below, reportbug have collected a lot information about tainted modules, that I haven't noticed before. Apart these messages, the system looks working correctly. Cesare. -- Package-specific info: ** Version: Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-1 (2019-03-12) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 root=/dev/mapper/etna2014-root ro quiet splash i915.fastboot=1 ** Tainted: E (8192) * Unsigned module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: ASUSTeK COMPUTER INC. product_name: PU301LA product_version: 1.0 chassis_vendor: ASUSTeK COMPUTER INC. chassis_version: 1.0 bios_vendor: American Megatrends Inc. bios_version: PU301LA.206 board_vendor: ASUSTeK COMPUTER INC. board_name: PU301LA board_version: 1.0 ** Loaded modules: rfcomm(E) cls_u32(E) sch_htb(E) ifb(E) ctr(E) ccm(E) ip6t_rpfilter(E) cmac(E) bnep(E) nft_chain_nat_ipv6(E) nf_nat_ipv6(E) nft_chain_route_ipv6(E) ip6t_REJECT(E) nf_reject_ipv6(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) ipt_rpfilter(E) arc4(E) nft_chain_nat_ipv4(E) intel_rapl(E) nf_nat_ipv4(E) ath9k(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) nf_nat(E) ath9k_common(E) coretemp(E) ath9k_hw(E) ath(E) kvm_intel(E) mei_wdt(E) ath3k(E) btusb(E) btrtl(E) uvcvideo(E) btbcm(E) btintel(E) kvm(E) bluetooth(E) mac80211(E) snd_hda_codec_conexant(E) snd_hda_codec_hdmi(E) videobuf2_vmalloc(E) nft_chain_route_ipv4(E) snd_hda_codec_generic(E) videobuf2_memops(E) irqbypass(E) videobuf2_v4l2(E) crct10dif_pclmul(E) videobuf2_common(E) crc32_pclmul(E) videodev(E) snd_hda_intel(E) nfnetlink_log(E) drbg(E) snd_hda_codec(E) ghash_clmulni_intel(E) media(E) ansi_cprng(E) intel_cstate(E) snd_hda_core(E) intel_uncore(E) snd_hwdep(E) intel_rapl_perf(E) efi_pstore(E) joydev(E) snd_pcm(E) cfg80211(E) pcspkr(E) nft_counter(E) asus_nb_wmi(E) asus_wmi(E) serio_raw(E) sparse_keymap(E) efivars(E) ecdh_generic(E) snd_timer(E) mei_me(E) sg(E) mei(E) iTCO_wdt(E) rfkill(E) snd(E) processor_thermal_device(E) intel_soc_dts_iosf(E) iTCO_vendor_support(E) soundcore(E) intel_pch_thermal(E) xt_tcpudp(E) xt_conntrack(E) nf_conntrack(E) int3400_thermal(E) battery(E) evdev(E) dell_smo8800(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) int3402_thermal(E) int340x_thermal_zone(E) acpi_thermal_rel(E) asus_wireless(E) ac(E) pcc_cpufreq(E) ipt_REJECT(E) nf_reject_ipv4(E) xt_NFLOG(E) nft_compat(E) nf_tables(E) nfnetlink(E) binfmt_misc(E) sch_fq_codel(E) efivarfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) ecb(E) btrfs(E) zstd_decompress(E) zstd_compress(E) xxhash(E) dm_mod(E) raid10(E) raid456(E) async_raid6_recov(E) async_memcpy(E) async_pq(E) async_xor(E) async_tx(E) xor(E) raid6_pq(E) libcrc32c(E) crc32c_generic(E) raid1(E) raid0(E) multipath(E) linear(E) md_mod(E) sd_mod(E) i915(E) crc32c_intel(E) i2c_algo_bit(E) ahci(E) drm_kms_helper(E) libahci(E) libata(E) ehci_pci(E) ehci_hcd(E) alx(E) psmouse(E) xhci_pci(E) mdio(E) xhci_hcd(E) aesni_intel(E) drm(E) aes_x86_64(E) lpc_ich(E) crypto_simd(E) cryptd(E) glue_helper(E) scsi_mod(E) i2c_i801(E) usbcore(E) thermal(E) usb_common(E) wmi(E) video(E) button(E) ** Network status: *** IP interfaces and addresses: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp2s0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether bc:ee:7b:a3:47:92 brd ff:ff:ff:ff:ff:ff 3: wlp3s0: mtu 1500 qdisc htb state UP group default qlen 1000 link/ether 6c:71:d9:a2:ec:17 brd ff:ff:ff:ff:ff:ff inet 192.168.10.22/24 brd 192.168.10.255 scope global dynamic noprefixroute wlp3s0 valid_lft 86277sec preferred_lft 86277sec inet6 fe80::6e71:d9ff:fea2:ec17/64 scope link valid_lft forever preferred_lft forever *** Device statistics: Inter-| Receive| Transmit face |bytespackets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 61031 210000 0 0 061031 210000 0 0 0 wlp3s0: 52126 121000 0 0 017622 117000 0 0 0 enp2s0: 0 0000 0 0 00 0000 0 0 0 *** Prot
Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
On 28/02/19 16:44, Thorsten Glaser wrote: please do consider uploading 4.19.24 to buster/sid with some haste. We have headless virtualisation hosts being unreachable/frozen now, and while these are “only” development systems, this is untenable. Like you I'm looking forward for that kernel. But, in the meantime, doesn't the workaround of disabling blk_mq work for you? See comment #15 and #20. I used it for months without any problem. Cesare.
Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
On 13/02/19 18:21, Dragan Milenkovic wrote: This patch is already on its way to stable branches. I have tested it and confirmed that it resolves the problem. Hello Dragan, do you know if the patch was eventually included upstream and possibly in which version? Cesare.
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
On Tue, 5 Feb 2019 01:36:08 +0100 Dragan Milenkovic wrote: I have tracked the issue to this change: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/block/blk-flush.c?id=344e9ffcbd1898e1dc04085564a6e05c30ea8199 Thank you very much for your deep analisys and thank you also for reporting it upstream on linux-kernel mailing list: https://marc.info/?l=linux-kernel&m=154945762114390&w=2 It still has no reply but I really hope someone will backport your fix soon. Cesare.
Bug#917164: "lvm2-activation-generator: lvmconfig failed" message at boot time
On 24/12/18 11:13, Jean-Michel Pouré wrote: It is impossible to boot using latest kernel. It was possible to boot using Grub menu either selecting an older kernel (4.18.0-3) or using « Recovery mode » and kernel 4.19.0-1. I tried to modify /etc/lvm/lvm.conf as explained but it did not work for me. Hello Jean-Michel, have a look at the last note from the initial Xavier's message: your boot problems are likely caused by an udev bug, not by lvm. As several other lvm's users, while waiting for a better solution, you should probably downgrade udev to previous version 239. You can find more informations here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917124 Cesare.
Bug#917166: Errors on and after upgrade to 2.03.01-2, swap on lvm not mounted
On Sun, 23 Dec 2018 15:58:50 +0100 Piotr Jurkiewicz wrote: On two machines running sid I observed errors during the upgrade to 2.03.01-2. One of these machines became practically unusable immediately after the update (disk IO operations became so slow that even closing aptitude took 2 minutes instead usual 3 seconds, I had to reboot it). On second machine I observed the same errors in log, but without the slowdown (maybe because it was RAID-based). I suggest you to read this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917124 Probably your boot problems are due to an udev 240 bug and while waiting for a solution you'd better to downgrade udev to 239. I've done it using snapshot.debian.org. After the update, both machines generate errors on boot: Dec 23 15:41:16 sonata lvm2-activation-generator: lvmconfig failed Dec 23 15:41:16 sonata lvm2-activation-generator: Activation generator failed. These messages are another problem and I've resolved reading this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917164 Cesare.
Bug#917164: "lvm2-activation-generator: lvmconfig failed" message at boot time
On Sun, 23 Dec 2018 15:36:25 +0100 Xavier Guerrin wrote: I investigated why and what follows are my strace-based conclusions. As you probably know already, lvm2-activation-generator runs: /sbin/lvmconfig global/event_activation global/use_lvmpolld After the latest lvm2 upgrade, it turns out /etc/lvm/lvm.conf does *not* contain event_activation in its global section. Therefore, lvmconfig: - outputs "Configuration node global/event_activation not found" on stderr; - outputs "use_lvmpolld=1" on stdout; - exits with return code 1, hence the reported error. Excellent bug report Xavier! It was really helpful for me. I can confirm that setting "event_activation=1" solves all these "lvm2-activation-generator: lvmconfig failed" messages. That option is missing from the Debian setup but is present and enabled upstream, as showed by this command: lvmconfig --typeconfig default --withcomments Cesare.
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
Hi Hans! On Sat, 24 Nov 2018 01:08:56 +0100 Hans van Kranenburg wrote: You didn't share any part of your logging. Can you share a part of dmesg logging that shows Oops in it? Here it is, attached to this message. Previously I didn't attached it because to me it looks substantially the same as the one I attached in the opening message of this bug (#913119). If a task hangs while doing disk IO, it might cause messages like these in dmesg: INFO: task kthxbye:1157 blocked for more than 120 seconds. Not tainted blah #1 Debian someversion [...] These are 'just' informational messages. The process will still wait until it can continue. A kernel Oops is something really different. It usually means that some data structures or code to be executed are corrupt and there's a real problem going on, it's not just stalled and waiting. Thank you very much for this explanation: I didn't know this difference and indeed I realized that I didn't know what a oops really is. Cesare. [16192.174787] INFO: task mdX_raid1:221 blocked for more than 120 seconds. [16192.174792] Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-1 [16192.174793] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16192.174795] mdX_raid1 D0 221 2 0x8000 [16192.174798] Call Trace: [16192.174808] ? __schedule+0x2b7/0x880 [16192.174811] schedule+0x28/0x80 [16192.174819] md_super_wait+0x6e/0xa0 [md_mod] [16192.174824] ? finish_wait+0x80/0x80 [16192.174828] md_update_sb.part.65+0x408/0x840 [md_mod] [16192.174833] md_check_recovery+0x4ab/0x570 [md_mod] [16192.174837] raid1d+0x5c/0x890 [raid1] [16192.174840] ? lock_timer_base+0x67/0x80 [16192.174842] ? try_to_del_timer_sync+0x4d/0x80 [16192.174844] ? del_timer_sync+0x35/0x40 [16192.174847] ? schedule_timeout+0x181/0x380 [16192.174851] ? md_rdev_init+0xb0/0xb0 [md_mod] [16192.174855] ? md_thread+0x122/0x160 [md_mod] [16192.174857] ? handle_read_error+0x4f0/0x4f0 [raid1] [16192.174860] md_thread+0x122/0x160 [md_mod] [16192.174863] ? finish_wait+0x80/0x80 [16192.174865] kthread+0x113/0x130 [16192.174867] ? kthread_create_worker_on_cpu+0x70/0x70 [16192.174869] ret_from_fork+0x35/0x40 [16192.174872] INFO: task jbd2/dm-4-8:294 blocked for more than 120 seconds. [16192.174874] Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-1 [16192.174875] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16192.174876] jbd2/dm-4-8 D0 294 2 0x8000 [16192.174878] Call Trace: [16192.174881] ? __schedule+0x2b7/0x880 [16192.174882] ? __switch_to_asm+0x40/0x70 [16192.174883] ? __switch_to_asm+0x34/0x70 [16192.174886] ? bit_wait+0x50/0x50 [16192.174888] schedule+0x28/0x80 [16192.174890] io_schedule+0x12/0x40 [16192.174892] bit_wait_io+0xd/0x50 [16192.174894] __wait_on_bit+0x44/0x80 [16192.174896] out_of_line_wait_on_bit+0x91/0xb0 [16192.174899] ? init_wait_var_entry+0x40/0x40 [16192.174905] jbd2_journal_commit_transaction+0x1036/0x1810 [jbd2] [16192.174907] ? __switch_to_asm+0x40/0x70 [16192.174908] ? __switch_to_asm+0x34/0x70 [16192.174909] ? __switch_to_asm+0x40/0x70 [16192.174911] ? __switch_to_asm+0x34/0x70 [16192.174913] ? __switch_to_asm+0x40/0x70 [16192.174917] ? kjournald2+0xbd/0x270 [jbd2] [16192.174921] kjournald2+0xbd/0x270 [jbd2] [16192.174923] ? finish_wait+0x80/0x80 [16192.174927] ? commit_timeout+0x10/0x10 [jbd2] [16192.174928] kthread+0x113/0x130 [16192.174930] ? kthread_create_worker_on_cpu+0x70/0x70 [16192.174931] ret_from_fork+0x35/0x40 [16192.174938] INFO: task mdX_raid1:603 blocked for more than 120 seconds. [16192.174939] Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-1 [16192.174941] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16192.174942] mdX_raid1 D0 603 2 0x8000 [16192.174944] Call Trace: [16192.174946] ? __schedule+0x2b7/0x880 [16192.174948] schedule+0x28/0x80 [16192.174952] md_super_wait+0x6e/0xa0 [md_mod] [16192.174955] ? finish_wait+0x80/0x80 [16192.174959] md_update_sb.part.65+0x408/0x840 [md_mod] [16192.174963] md_check_recovery+0x4ab/0x570 [md_mod] [16192.174966] raid1d+0x5c/0x890 [raid1] [16192.174967] ? lock_timer_base+0x67/0x80 [16192.174969] ? try_to_del_timer_sync+0x4d/0x80 [16192.174971] ? del_timer_sync+0x35/0x40 [16192.174973] ? schedule_timeout+0x181/0x380 [16192.174977] ? md_rdev_init+0xb0/0xb0 [md_mod] [16192.174981] ? md_thread+0x122/0x160 [md_mod] [16192.174983] ? handle_read_error+0x4f0/0x4f0 [raid1] [16192.174986] md_thread+0x122/0x160 [md_mod] [16192.174989] ? finish_wait+0x80/0x80 [16192.174990] kthread+0x113/0x130 [16192.174992] ? kthread_create_worker_on_cpu+0x70/0x70 [16192.174994] ret_from_fork+0x35/0x40 [16192.174997] INFO: task jbd2/dm-9-8:667 blocked for more than 120 seconds. [16192.174998] Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-1 [16192.175000] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [16192.175001] jbd2/d
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
Bug still present with the new 4.18.0-3-amd64 (4.18.20-1). This morning I've tryed to boot this new kernel version, removing the workaround given by the following kernel parameters: scsi_mod.use_blk_mq=0 dm_mod.use_blk_mq=0 The system showed disk hangs in less than 5 hours, and, as in previous 4.17 and 4.18, normal disk activities was restored after some minutes, without apparent data loss. I experienced two hangs before rebooting, but one of them didn't produce an oops in dmesg. It was not the first time I saw an hang without oops: maybe those that can recover in less than 120 seconds, doesn't produce oopses in dmesg? And just to be clear, it doesn't seem a bug related to LVM but more precisely to various types (all?) of LVM RAID. In fact my notebook disk uses LVM linear volumes and never showed those hangs and oopses. Cesare.
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
I've added some details in #913138, which I believe is the same bug as this one. There a commenter suggested two kernel parameters that, so far, have resolved the problem for me. Cesare.
Bug#913138: linux: I/O on md RAID 6 hangs completely
On Thu, 08 Nov 2018 23:28:16 +0100 =?UTF-8?Q?Stanis=C5=82aw?= wrote: I suffer the same problem while running RAID1 with kernel 4.18.10-2. Me too. For me this happens since the switch from 4.16 to 4.17.x, with two different PCs, both with LVM based RAID1. I've already opened bug #913119, then I've found this bug report and the reply from Stanislav was really helpful for me. To me this bug, mine and the already closed bug #904822 have the same root: the stack traces reported by dmesg are very similar. And the common denominators are some sort of LVM RAID and the range of kernel used. "...Someone else suggested this might be related to using "blk-mq", so could you try with these parameter: dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0 This seems to have solved the problem for me. I've tested these boot parameters on one of the affected PC and now it's running for more than three days. Before, with kernel from 4.17.x to the current Debian's 4.18.10-2+b1, the system showed an oops within 0.5/1 day. Disabling these parameters is plausible, since Debian's kernel enabled SCSI_MQ_DEFAULT and DM_MQ_DEFAULT with 4.17~rc7-1~exp1. Also, do you have laptop-mode-tools installed? No, not installed here. I've checked with two other distributions I have here, to see what they have done with SCSI_MQ_DEFAULT and DM_MQ_DEFAULT parameters: - Arch Linux (kernel 4.18.16-arch1-1-ARCH): both disabled. - Arch Linux (kernel 4.19.2-arch1-1-ARCH): both enabled. - Fedora server 29 (kernel 4.18.17-300.fc29.x86_64): both disabled. - Fedora server 29 (kernel 4.19.2-301.fc29.x86_64): both disabled. But I was unable to find if upstream is aware of this problem and if it's already resolved in 4.19. Cesare.
Bug#912943: fireqos fails to install: /usr/lib/firehol/services.fireqos missing
Package: fireqos Version: 3.1.6+ds-3 Severity: normal Same as #912758, but with another file. The reason is reported in the last sentence of that bug report: > I believe the problem is the for loop at line 43 in /usr/sbin/fireqos: it > needs to source some files in /usr/lib/firehol/ but services.common is not > there, so it "exit 1". But notice that after that file, the loop would have > searched for services.fireqos, which isn't there too. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fireqos depends on: ii firehol-common 3.1.6+ds-3 ii lsb-base9.20170808 Versions of packages fireqos recommends: pn firehol Versions of packages fireqos suggests: pn firehol-tools pn fireqos-doc -- Configuration Files: /etc/firehol/fireqos.conf changed: interface wlan0 adsl-in output rate 54Mbit minrate 10kbit # Per la rete locale, nessuna limitazione. class lan rate 40Mbit match dst 192.168.10.0/24 # Gestione del traffico verso l'ADSL. #class group adsl rate 512kbit ceil 512kbit class group adsl rate 6144kbit ceil 6144kbit match all class veryhighprio rate 10% match udp port 53 # DNS match tcp port 22 # SSH match tcp port 123 # NTP class web rate 50% match tcp port 80,443 # HTTP e HHTPs class mail rate 20% match tcp port 25,587,465 # SMTP e SMTPs match tcp port 110,995 # POP3 e POP3s match tcp port 143,993 # IMAP e IMAPs class default ceil 20% class group end interface wlan0 adsl-out output rate 54Mbit minrate 10kbit # Per la rete locale, nessuna limitazione. class lan rate 50Mbit match dst 192.168.10.0/24 # Gestione del traffico verso l'ADSL. #class group adsl rate 512kbit ceil 512kbit class group adsl rate 384kbit ceil 384kbit match all class veryhighprio rate 10% match udp port 53 # DNS match tcp port 22 # SSH match tcp port 123 # NTP class web rate 30% match tcp port 80,443 # HTTP e HHTPs class mail rate 20% match tcp port 25,587,465 # SMTP e SMTPs match tcp port 110,995 # POP3 e POP3s match tcp port 143,993 # IMAP e IMAPs class default ceil 30% class group end -- no debconf information
Bug#912758: fireqos fails to install: /usr/lib/firehol/service.common missing
Package: fireqos Version: 3.1.6+ds-1 Severity: normal The upgrade from fireqos:amd64 3.1.5+ds1-2 to 3.1.6+ds-1 failed during the "setting up" phase of dpkg: - # dpkg --configure -a Setting up fireqos (3.1.6+ds-1) ... Job for fireqos.service failed because the control process exited with error code. See "systemctl status fireqos.service" and "journalctl -xe" for details. invoke-rc.d: initscript fireqos, action "restart" failed. ● fireqos.service - FireQOS traffic shaping for humans Loaded: loaded (/lib/systemd/system/fireqos.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/fireqos.service.d └─override.conf Active: failed (Result: exit-code) since Sat 2018-11-03 15:59:24 CET; 5ms ago Docs: man:fireqos(1) man:fireqos.conf(5) Process: 1670 ExecStart=/usr/sbin/fireqos start (code=exited, status=1/FAILURE) Main PID: 1670 (code=exited, status=1/FAILURE) nov 03 15:59:24 etna systemd[1]: Starting FireQOS traffic shaping for humans... nov 03 15:59:24 etna fireqos[1670]: Cannot access /usr/lib/firehol/services.common nov 03 15:59:24 etna systemd[1]: fireqos.service: Main process exited, code=exited, status=1/FAILURE nov 03 15:59:24 etna systemd[1]: fireqos.service: Failed with result 'exit-code'. nov 03 15:59:24 etna systemd[1]: Failed to start FireQOS traffic shaping for humans. dpkg: error processing package fireqos (--configure): installed fireqos package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: fireqos I believe the problem is the for loop at line 43 in /usr/sbin/fireqos: it needs to source some files in /usr/lib/firehol/ but services.common is not there, so it "exit 1". But notice that after that file, the loop would have searched for services.fireqos, which isn't there too. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fireqos depends on: ii firehol-common 3.1.6+ds-1 ii lsb-base9.20170808 Versions of packages fireqos recommends: pn firehol Versions of packages fireqos suggests: pn firehol-tools pn fireqos-doc -- Configuration Files: /etc/firehol/fireqos.conf changed: interface wlan0 adsl-in output rate 54Mbit minrate 10kbit # Per la rete locale, nessuna limitazione. class lan rate 40Mbit match dst 192.168.10.0/24 # Gestione del traffico verso l'ADSL. #class group adsl rate 512kbit ceil 512kbit class group adsl rate 6144kbit ceil 6144kbit match all class veryhighprio rate 10% match udp port 53 # DNS match tcp port 22 # SSH match tcp port 123 # NTP class web rate 50% match tcp port 80,443 # HTTP e HHTPs class mail rate 20% match tcp port 25,587,465 # SMTP e SMTPs match tcp port 110,995 # POP3 e POP3s match tcp port 143,993 # IMAP e IMAPs class default ceil 20% class group end interface wlan0 adsl-out output rate 54Mbit minrate 10kbit # Per la rete locale, nessuna limitazione. class lan rate 50Mbit match dst 192.168.10.0/24 # Gestione del traffico verso l'ADSL. #class group adsl rate 512kbit ceil 512kbit class group adsl rate 384kbit ceil 384kbit match all class veryhighprio rate 10% match udp port 53 # DNS match tcp port 22 # SSH match tcp port 123 # NTP class web rate 30% match tcp port 80,443 # HTTP e HHTPs class mail rate 20% match tcp port 25,587,465 # SMTP e SMTPs match tcp port 110,995 # POP3 e POP3s match tcp port 143,993 # IMAP e IMAPs class default ceil 30% class group end -- no debconf information
Bug#911777: iptables: ferm broken by changed path of iptables-restore
Dear iptables maintainers, reading the initial bug report you can think I haven't read README.Debian before filing this bug, but I did. It's clear that now iptables is handled by update-alternatives, so that the user can choose between the new nftables compatible programs (the dafault) or the legacy programs. That's great! And you have also documented the changed path of the binaries, from /sbin to /usr/sbin/. The point is: existing packages, like ferm, that search for the previous full paths, are now broken. Since iptables-nft-save/iptables-nft-restore should be compatible with the legacy iptables-save/iptables-restore, why not render the old paths a symlink to /etc/alternatives/? For example: /sbin/iptables -> /etc/alternatives/iptables /sbin/iptables-restore -> /etc/alternatives/iptables-restore /sbin/iptables-save -> /etc/alternatives/iptables-save In the ferm case, it suffice to create the following two symlinks, to make it start again: ln -s /etc/alternatives/iptables-restore /sbin/iptables-restore ln -s /etc/alternatives/ip6tables-restore /sbin/ip6tables-restore With alternatives left with the current default: /etc/alternatives/iptables-restore -> /usr/sbin/iptables-nft-restore /etc/alternatives/ip6tables-restore -> /usr/sbin/ip6tables-nft-restore Cesare.
Bug#911777: iptables: ferm broken by changed path of iptables-restore
Package: iptables Version: 1.8.1-1 Severity: normal After the upgrade from 1.6.2-1.1 to 1.8.1-1, ferm firewall cannot start anymore, because it doesn't find /sbin/iptables-restore. Now iptables programs are all under /usr/sbin (with the exception of iptables-xml under /usr/bin), while in 1.6.2 many executables where under /sbin. Perhaps some compatibility symlinks should be placed there. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages iptables depends on: ii libc62.27-6 ii libip4tc01.8.1-1 ii libip6tc01.8.1-1 ii libiptc0 1.8.1-1 ii libmnl0 1.0.4-2 ii libnetfilter-conntrack3 1.0.7-1 ii libnfnetlink01.0.1-3+b1 ii libnftnl71.1.1-1 ii libxtables12 1.8.1-1 iptables recommends no packages. Versions of packages iptables suggests: ii kmod 25-1 -- no debconf information
Bug#911591: Info received (network-manager: Segfault at service startup on i386)
Looks similar to #911621. And he is i386 too.
Bug#911591: network-manager: Segfault at service startup on i386
Mmh, log lines are wrapped... I attach them as files, to make them more readable. ott 22 10:09:51 muletto systemd[1]: Starting Network Manager... ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.5867] NetworkManager (version 1.14.2) is starting... (after a restart) ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.5876] Read config: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.5893] wifi-nl80211: (wlan0): using nl80211 for WiFi device control ott 22 10:09:51 muletto systemd[1]: Started Network Manager. ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6015] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager" ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6020] manager[0x181f048]: monitoring kernel firmware directory '/lib/firmware'. ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6020] monitoring ifupdown state file '/run/network/ifstate'. ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6068] hostname: hostname: using hostnamed ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6069] hostname: hostname changed from (none) to "muletto" ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6072] dns-mgr[0x1807be0]: init: dns=default, rc-manager=resolvconf ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6086] rfkill0: found WiFi radio killswitch (at /sys/devices/pci:00/:00:1c.3/:05:00 ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6089] rfkill1: found WiFi radio killswitch (at /sys/devices/platform/acer-wmi/rfkill/rfkill1) ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6164] manager[0x181f048]: rfkill: WiFi hardware radio set enabled ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6168] manager[0x181f048]: rfkill: WWAN hardware radio set enabled ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6215] ifupdown: interface-parser: parsing file /etc/network/interfaces ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6221] ifupdown: interface-parser: finished parsing file /etc/network/interfaces ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Main process exited, code=killed, status=11/SEGV ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Failed with result 'signal'. ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Service RestartSec=100ms expired, scheduling restart. ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Scheduled restart job, restart counter is at 5. ott 22 10:09:51 muletto systemd[1]: Stopped Network Manager. ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Start request repeated too quickly. ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Failed with result 'signal'. ott 22 10:09:51 muletto systemd[1]: Failed to start Network Manager. [ 38.615488] NetworkManager[539]: segfault at 1 ip b7687328 sp bf8d95e0 error 4 in libc-2.27.so[b761a000+14c000] [ 38.615500] Code: 83 c2 04 0f b6 42 ff 83 c1 04 0f b6 59 ff 84 c0 74 47 38 d8 75 43 39 f2 75 b8 83 e7 03 eb 07 8d 76 00 31 db 31 c0 85 ff 74 2f <0f> b6 02 0f b6 19 38 d8 75 25 84 c0 74 21 be 01 00 00 00 eb 16 8d
Bug#911591: network-manager: Segfault at service startup on i386
Package: network-manager Version: 1.14.2-2 Severity: normal This bug report was saved with reportbug but sent with the gmail web interface: I hope it looks good. After upgrading from 1.12.4-1 to 1.14.2-2 the service segfaults and doesn't start anymore. Rebooting doesn't help. But i've successfully upgraded NetworkManager to the same version on another Debian Sid machine: apart the different hardware, I think the real difference is the architecture: - i386 (here): fail - amd64: ok Journalctl report this: ott 22 10:09:51 muletto systemd[1]: Starting Network Manager... ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.5867] NetworkManager (version 1.14.2) is starting... (after a restart) ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.5876] Read config: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.5893] wifi-nl80211: (wlan0): using nl80211 for WiFi device control ott 22 10:09:51 muletto systemd[1]: Started Network Manager. ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6015] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager" ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6020] manager[0x181f048]: monitoring kernel firmware directory '/lib/firmware'. ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6020] monitoring ifupdown state file '/run/network/ifstate'. ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6068] hostname: hostname: using hostnamed ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6069] hostname: hostname changed from (none) to "muletto" ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6072] dns-mgr[0x1807be0]: init: dns=default, rc-manager=resolvconf ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6086] rfkill0: found WiFi radio killswitch (at /sys/devices/pci:00/:00:1c.3/:05:00 ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6089] rfkill1: found WiFi radio killswitch (at /sys/devices/platform/acer-wmi/rfkill/rfkill1) ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6164] manager[0x181f048]: rfkill: WiFi hardware radio set enabled ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6168] manager[0x181f048]: rfkill: WWAN hardware radio set enabled ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6215] ifupdown: interface-parser: parsing file /etc/network/interfaces ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.6221] ifupdown: interface-parser: finished parsing file /etc/network/interfaces ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Main process exited, code=killed, status=11/SEGV ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Failed with result 'signal'. ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Service RestartSec=100ms expired, scheduling restart. ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Scheduled restart job, restart counter is at 5. ott 22 10:09:51 muletto systemd[1]: Stopped Network Manager. ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Start request repeated too quickly. ott 22 10:09:51 muletto systemd[1]: NetworkManager.service: Failed with result 'signal'. ott 22 10:09:51 muletto systemd[1]: Failed to start Network Manager. Dmesg reports this: [ 38.615488] NetworkManager[539]: segfault at 1 ip b7687328 sp bf8d95e0 error 4 in libc-2.27.so[b761a000+14c000] [ 38.615500] Code: 83 c2 04 0f b6 42 ff 83 c1 04 0f b6 59 ff 84 c0 74 47 38 d8 75 43 39 f2 75 b8 83 e7 03 eb 07 8d 76 00 31 db 31 c0 85 ff 74 2f <0f> b6 02 0f b6 19 38 d8 75 25 84 c0 74 21 be 01 00 00 00 eb 16 8d After downgrading network-manager, libnm0 and gir1.2-nm-1.0 to 1.12.4-1 using snapshot.debian.org, now it starts again. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.18.0-2-686-pae (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.10-1 ii libaudit1 1:2.8.4-2 ii libbluetooth3 5.50-1 ii libc6 2.27-6 ii libcurl3-gnutls7.61.0-1 ii libglib2.0-0 2.58.1-2 ii libgnutls303.5.19-1+b1 ii libjansson42.11-1 ii libmm-glib01.8.2-1 ii libndp01.6-1+b1 ii libnewt0.520.52.20-8 ii libnm0 1.14.2-2 ii libpam-systemd 239-10 ii libpolkit-agent-1-00.105-21 ii libpolkit-gobject-1-0 0.105-21 ii libpsl50.20.2-2 ii libreadline7 7.0-5 ii libselinux12.8-1+b1 ii libsystemd0239-10 ii libteamdctl0 1.27-1
Bug#903165: On boot squid.service starts but doesn't work
I've CCed NetworkManager maintainers: since here /etc/resolv.conf is a symlink created by NetworkManager, perhaps they can provide some advice. Regarding the opening message, I've workarounded the problem overriding the squid service like this: # systemctl edit squid.service --- [Unit] After=network-online.target --- But that didn't work with my PC at work (see message #30), for which the override had no effect. Perhaps there the problem has different origin: I have to investigate better on this. Cesare.
Bug#903303: Acknowledgement (fireqos: Fireqos fails to start on boot)
First, to the bug report context I add that my network is managed by NetworkManager and I use a wifi network (so slower to come up than a cable network). Since on one occasion the service started ok on boot, with my basic systemd knowledge I analyzed the fireqos.service and I think the problem is the lack of something that tells the service to start only after some conditions are met. I don't know exactly what are those conditions but at least the networks to which fireqos rules are referred should be up. I've experimented that overriding the fireqos service (systemctl edit fireqos.service) with the following lines, worked for me: --- [Unit] After=network-online.target --- I'm sure it's suboptimal, but I tried "After=network.target" and it didn't suffice. Cesare.
Bug#903165: squid: When squid.service starts no /etc/resolv.conf is present yet
control: retitle -1 On boot squid.service starts but doesn't work Here at work I have a similar setup in respect to the opening message: Debian Sid, NetworkManager, Squid 4.1. But very different Squid configuration. While the final effect is the same (squid does not start on boot and I have to manually restart later), the reason looks different. Analyzing the logs (attached the last one), here is the recurring message: commBind Cannot bind socket FD 12 to 192.168.1.29:8080: (99) Cannot assign requested address Here nss-lookup.target looks active: # systemctl list-units --type target -all | grep nss nss-lookup.target loaded active active Host and Network Name Lookups nss-user-lookup.target loaded active active User and Group Name Lookups Both at work and in the opening message, the surprising thing is that Squid looks in a "started" status: I cannot see FAIL message on boot. In other word Squid starts but doesn't report to systemd that something is failed. Cesare. lug 11 12:53:56 barone systemd[1]: Starting Squid Web Proxy Server... lug 11 12:53:56 barone squid[833]: setsid failed: (1) Operation not permitted lug 11 12:53:56 barone squid[833]: 2018/07/11 12:53:56| Created PID file (/var/run/squid.pid) lug 11 12:53:56 barone squid[833]: Squid Parent: will start 1 kids lug 11 12:53:56 barone squid[833]: Squid Parent: (squid-1) process 906 started lug 11 12:53:56 barone squid[833]: 2018/07/11 12:53:56 kid1| Set Current Directory to /var/spool/squid lug 11 12:53:56 barone squid[833]: 2018/07/11 12:53:56 kid1| Creating missing swap directories lug 11 12:53:56 barone squid[833]: 2018/07/11 12:53:56 kid1| No cache_dir stores are configured. lug 11 12:53:56 barone squid[833]: Squid Parent: squid-1 process 906 exited with status 0 lug 11 12:53:56 barone squid[833]: 2018/07/11 12:53:56| Removing PID file (/var/run/squid.pid) lug 11 12:53:56 barone systemd[1]: squid.service: Can't open PID file /var/run/squid.pid (yet?) after start: No such file or directory lug 11 12:53:56 barone squid[1007]: Created PID file (/var/run/squid.pid) lug 11 12:53:56 barone squid[1007]: Squid Parent: will start 1 kids lug 11 12:53:56 barone squid[1007]: Squid Parent: (squid-1) process 1011 started lug 11 12:53:56 barone systemd[1]: Started Squid Web Proxy Server. lug 11 12:53:56 barone squid[1011]: Set Current Directory to /var/spool/squid lug 11 12:53:56 barone squid[1011]: Starting Squid Cache version 4.1 for x86_64-pc-linux-gnu... lug 11 12:53:56 barone squid[1011]: Service Name: squid lug 11 12:53:56 barone squid[1011]: Process ID 1011 lug 11 12:53:56 barone squid[1011]: Process Roles: worker lug 11 12:53:56 barone squid[1011]: With 1024 file descriptors available lug 11 12:53:56 barone squid[1011]: Initializing IP Cache... lug 11 12:53:56 barone squid[1011]: DNS Socket created at [::], FD 5 lug 11 12:53:56 barone squid[1011]: DNS Socket created at 0.0.0.0, FD 9 lug 11 12:53:56 barone squid[1011]: Adding domain internal.bernispa.com from /etc/resolv.conf lug 11 12:53:56 barone squid[1011]: Adding nameserver 192.168.1.66 from /etc/resolv.conf lug 11 12:53:56 barone squid[1011]: Adding nameserver 192.168.1.77 from /etc/resolv.conf lug 11 12:53:56 barone squid[1011]: helperOpenServers: Starting 0/5 'digest_file_auth' processes lug 11 12:53:56 barone squid[1011]: helperOpenServers: No 'digest_file_auth' processes needed. lug 11 12:53:56 barone squid[1011]: Logfile: opening log stdio:/var/log/squid/access.log lug 11 12:53:56 barone squid[1011]: Local cache digest enabled; rebuild/rewrite every 3600/3600 sec lug 11 12:53:56 barone squid[1011]: Store logging disabled lug 11 12:53:56 barone squid[1011]: Swap maxSize 0 + 262144 KB, estimated 20164 objects lug 11 12:53:56 barone squid[1011]: Target number of buckets: 1008 lug 11 12:53:56 barone squid[1011]: Using 8192 Store buckets lug 11 12:53:56 barone squid[1011]: Max Mem size: 262144 KB lug 11 12:53:56 barone squid[1011]: Max Swap size: 0 KB lug 11 12:53:56 barone squid[1011]: Using Least Load store dir selection lug 11 12:53:56 barone squid[1011]: Set Current Directory to /var/spool/squid lug 11 12:53:56 barone squid[1011]: Finished loading MIME types and icons. lug 11 12:53:56 barone squid[1011]: commBind Cannot bind socket FD 12 to 192.168.1.29:8080: (99) Cannot assign requested address lug 11 12:53:56 barone squid[1011]: HTCP Disabled. lug 11 12:53:56 barone squid[1011]: Pinger socket opened on FD 14 lug 11 12:53:56 barone squid[1011]: Configuring Parent 81.174.18.233/3128/0 lug 11 12:53:56 barone squid[1011]: Squid plugin modules loaded: 0 lug 11 12:53:56 barone squid[1011]: Adaptation support is off. lug 11 12:53:56 barone squid[1011]: Accepting HTTP Socket connections at local=[::1]:8080 remote=[::] FD 11 flags=9 lug 11 12:53:57 barone squid[1011]: storeLateRelease: released 0 objects
Bug#903303: Acknowledgement (fireqos: Fireqos fails to start on boot)
Since on my system I have kept some old kernel installed, I've just tried to boot with the following kernels but the the service still doesn't starts: linux-image-4.7.0-1-amd64 (4.7.8-1) linux-image-4.15.0-3-amd64 (4.15.17-1) Cesare.
Bug#903165: squid: When squid.service starts no /etc/resolv.conf is present yet
On 08/07/2018 14:05, Amos Jeffries wrote: What init system are you using; sysV? systemd? something else? Systemd (which I still know at a basic level). If it is systemd, please check that your NetworkManager is part of the nss-lookup.target groups. Squid depends on that target providing resolv.conf. Mmh, surely on my system I didn't mess up with systemd target groups... The following command reports "nss-lookup.target" as inactive: -- # systemctl list-units --type target -all | grep -i nss nss-lookup.target loaded inactive dead Host and Network Name Lookups nss-user-lookup.target loaded active active User and Group Name Lookups-- NetworkManager doesn't seem to have dependency on nss-lookup.target: -- # grep -i nss /lib/systemd/system/NetworkManager* # -- Not sure what to do now. Do I have to file a bug to NetworkManager? Should I investigate why nss-lookup.target is inactive here? Thank you. Cesare.
Bug#903303: fireqos: Fireqos fails to start on boot
Package: fireqos Version: 3.1.5+ds1-2 Severity: normal Fireqos.service fails to start on boot, but if I manually starts it afterwards, it starts correctly. The attached fireqos.conf is operational since about 2 year. I believe that I see this problem after the .service was introduced because before I used to launch fireqos manually. From that moment I kept starting it on boot but I usually (always?) see it failing to start. Here is the log (journalct -u fireqos.service) after the boot, when fireqos fails to start: - lug 08 16:26:11 etna systemd[1]: Starting FireQOS traffic shaping for humans... lug 08 16:26:11 etna fireqos[650]: FireQOS 3.1.5 lug 08 16:26:11 etna fireqos[650]: (C) 2013-2014 Costa Tsaousis, GPL lug 08 16:26:11 etna fireqos[650]: : interface wlan0 adsl-in output rate 54Mbit minrate 10kbit (wlan0, 54000kbit, mtu 1500, quantum 1500, minrate 12kbit) lug 08 16:26:11 etna fireqos[650]: : class lan rate 40Mbit (1:11, 4/54000kbit, prio 0) lug 08 16:26:11 etna fireqos[650]: : class adsl rate 6144kbit ceil 6144kbit (1:12, 6144/6144kbit, prio 1) lug 08 16:26:11 etna fireqos[650]: : class veryhighprio rate 10% (1:13, 614/6144kbit, prio 0) lug 08 16:26:11 etna fireqos[650]: : class web rate 50% (1:14, 3072/6144kbit, prio 1) lug 08 16:26:11 etna fireqos[650]: : class mail rate 20% (1:15, 1228/6144kbit, prio 2) lug 08 16:26:12 etna fireqos[650]: Error: Parent Qdisc doesn't exists. lug 08 16:26:12 etna fireqos[650]: We have an error talking to the kernel, -1 lug 08 16:26:12 etna fireqos[650]: ERROR: lug 08 16:26:12 etna fireqos[650]: tc failed with error 2, while executing the command: lug 08 16:26:12 etna fireqos[650]: /sbin/tc filter add dev wlan0 parent 1:12 protocol ip prio 90 u32 match ip protocol 6 0xff match ip sport 993 0x flowid 1:15 lug 08 16:26:12 etna fireqos[650]: FAILED TO ACTIVATE TRAFFIC CONTROL. lug 08 16:26:12 etna fireqos[650]: Clearing failed interface: adsl-in (wlan0 output => wlan0)... lug 08 16:26:12 etna fireqos[650]: wlan0: cleared traffic control output lug 08 16:26:12 etna fireqos[650]: No traffic control is operational by FireQOS. lug 08 16:26:12 etna FireQOS[919]: FireQOS FAILED. Cleared all FireQOS changes on interface 'wlan0'. No traffic control is operational by FireQOS. lug 08 16:26:12 etna fireqos[650]: bye... lug 08 16:26:12 etna systemd[1]: fireqos.service: Main process exited, code=exited, status=1/FAILURE lug 08 16:26:12 etna systemd[1]: fireqos.service: Failed with result 'exit-code'. lug 08 16:26:12 etna systemd[1]: Failed to start FireQOS traffic shaping for humans. - Here is the log after starting fireqos manually, without errors: - lug 08 16:29:33 etna systemd[1]: Starting FireQOS traffic shaping for humans... lug 08 16:29:33 etna fireqos[1638]: FireQOS 3.1.5 lug 08 16:29:33 etna fireqos[1638]: (C) 2013-2014 Costa Tsaousis, GPL lug 08 16:29:33 etna fireqos[1638]: : interface wlan0 adsl-in output rate 54Mbit minrate 10kbit (wlan0, 54000kbit, mtu 1500, quantum 1500, minrate 12kbit) lug 08 16:29:33 etna fireqos[1638]: : class lan rate 40Mbit (1:11, 4/54000kbit, prio 0) lug 08 16:29:33 etna fireqos[1638]: : class adsl rate 6144kbit ceil 6144kbit (1:12, 6144/6144kbit, prio 1) lug 08 16:29:33 etna fireqos[1638]: : class veryhighprio rate 10% (1:13, 614/6144kbit, prio 0) lug 08 16:29:33 etna fireqos[1638]: : class web rate 50% (1:14, 3072/6144kbit, prio 1) lug 08 16:29:33 etna fireqos[1638]: : class mail rate 20% (1:15, 1228/6144kbit, prio 2) lug 08 16:29:33 etna fireqos[1638]: : class default ceil 20% (1:8001, 12/1228kbit, prio 3) lug 08 16:29:33 etna fireqos[1638]: : committed rate 4926kbit (80%), the remaining 1218kbit will be spare bandwidth. lug 08 16:29:33 etna fireqos[1638]: : class default (1:8000, 12/54000kbit, prio 2) lug 08 16:29:33 etna fireqos[1638]: : committed rate 46156kbit (85%), the remaining 7844kbit will be spare bandwidth. lug 08 16:29:33 etna fireqos[1638]: : interface wlan0 adsl-out output rate 54Mbit minrate 10kbit (wlan0, 54000kbit, mtu 1500, quantum 1500, minrate 12kbit) lug 08 16:29:33 etna fireqos[1638]: : class lan rate 50Mbit (1:11, 5/54000kbit, prio 0) lug 08 16:29:33 etna fireqos[1638]: : class adsl rate 384kbit ceil 384kbit (1:12, 384/384kbit, prio 1) lug 08 16:29:33 etna fireqos[1638]: : class veryhighprio rate 10% (1:13, 38/384kbit, prio 0) lug 08 16:29:33 etna fireqos[1638]: : class web rate 30% (1:14, 115/384kbit, prio 1) lug 08 16:29:33 etna fireqos[1638]: : class mail rate 20% (1:15, 76/384kbit, prio 2) lug 08 16:29:33 etna fireqos[1638]: : class default ceil 30% (1:8001, 12/115kbit, prio 3) lug 08 16:29:33 etna fireqos[1638]: : committed rate 241kbit (62%
Bug#903165: squid: When squid.service starts no /etc/resolv.conf is present yet
Package: squid Version: 4.1-1 Severity: normal For testing purposes I use squid proxy on my laptop. Since upgrading to 4.1, when the system boots, squid service is not operating properly: it always fails to resolve DNS names. And I have to restart the service in order to make it work. Here is the output of "journalctl -u squid.service", that reveals the culprit: --- lug 07 12:53:13 etna systemd[1]: Starting Squid Web Proxy Server... lug 07 12:53:13 etna squid[698]: setsid failed: (1) Operation not permitted lug 07 12:53:13 etna squid[698]: 2018/07/07 12:53:13| Created PID file (/var/run/squid.pid) lug 07 12:53:13 etna squid[698]: Squid Parent: will start 1 kids lug 07 12:53:13 etna squid[698]: Squid Parent: (squid-1) process 751 started lug 07 12:53:13 etna squid[698]: 2018/07/07 12:53:13 kid1| Set Current Directory to /var/spool/squid lug 07 12:53:13 etna squid[698]: 2018/07/07 12:53:13 kid1| Creating missing swap directories lug 07 12:53:13 etna squid[698]: 2018/07/07 12:53:13 kid1| No cache_dir stores are configured. lug 07 12:53:13 etna squid[698]: Squid Parent: squid-1 process 751 exited with status 0 lug 07 12:53:13 etna squid[698]: 2018/07/07 12:53:13| Removing PID file (/var/run/squid.pid) lug 07 12:53:13 etna squid[796]: Created PID file (/var/run/squid.pid) lug 07 12:53:13 etna squid[796]: Squid Parent: will start 1 kids lug 07 12:53:13 etna squid[796]: Squid Parent: (squid-1) process 801 started lug 07 12:53:13 etna systemd[1]: Started Squid Web Proxy Server. lug 07 12:53:13 etna squid[801]: Set Current Directory to /var/spool/squid lug 07 12:53:13 etna squid[801]: Starting Squid Cache version 4.1 for x86_64-pc-linux-gnu... lug 07 12:53:13 etna squid[801]: Service Name: squid lug 07 12:53:13 etna squid[801]: Process ID 801 lug 07 12:53:13 etna squid[801]: Process Roles: worker lug 07 12:53:13 etna squid[801]: With 1024 file descriptors available lug 07 12:53:13 etna squid[801]: Initializing IP Cache... lug 07 12:53:13 etna squid[801]: DNS Socket created at [::], FD 5 lug 07 12:53:13 etna squid[801]: DNS Socket created at 0.0.0.0, FD 9 lug 07 12:53:13 etna squid[801]: /etc/resolv.conf: (2) No such file or directory lug 07 12:53:13 etna squid[801]: Warning: Could not find any nameservers. Trying to use localhost lug 07 12:53:13 etna squid[801]: Please check your /etc/resolv.conf file lug 07 12:53:13 etna squid[801]: or use the 'dns_nameservers' option in squid.conf. lug 07 12:53:13 etna squid[801]: Logfile: opening log daemon:/var/log/squid/access.log lug 07 12:53:13 etna squid[801]: Logfile Daemon: opening log /var/log/squid/access.log lug 07 12:53:13 etna squid[801]: Local cache digest enabled; rebuild/rewrite every 3600/3600 sec lug 07 12:53:13 etna squid[801]: Store logging disabled lug 07 12:53:13 etna squid[801]: Swap maxSize 0 + 262144 KB, estimated 20164 objects lug 07 12:53:13 etna squid[801]: Target number of buckets: 1008 lug 07 12:53:13 etna squid[801]: Using 8192 Store buckets lug 07 12:53:13 etna squid[801]: Max Mem size: 262144 KB lug 07 12:53:13 etna squid[801]: Max Swap size: 0 KB lug 07 12:53:13 etna squid[801]: Using Least Load store dir selection lug 07 12:53:13 etna squid[801]: Set Current Directory to /var/spool/squid lug 07 12:53:13 etna squid[801]: Finished loading MIME types and icons. lug 07 12:53:13 etna squid[801]: HTCP Disabled. lug 07 12:53:13 etna squid[801]: Pinger socket opened on FD 14 lug 07 12:53:13 etna squid[801]: Squid plugin modules loaded: 0 lug 07 12:53:13 etna squid[801]: Adaptation support is off. lug 07 12:53:13 etna squid[801]: Accepting HTTP Socket connections at local=[::]:3128 remote=[::] FD 12 flags=9 lug 07 12:53:14 etna squid[801]: storeLateRelease: released 0 objects --- As you can see, when squid starts it cannot find /etc/resolv.conf and so seems to fallback to use a local nameserver, that is not present here. Here networking is managed by NetworkManager and /etc/resolv.conf is currently a symbolic link to /run/NetworkManager/resolv.conf Looks like squid.service starts too early, when the link is still not set. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages squid depends on: ii adduser 3.117 ii libc62.27-3 ii libcap2 1:2.25-1.2 ii libcom-err2 1.44.3~rc2-1 ii libdb5.3 5.3.28-13.1+b1 ii libdbi-perl 1.641-1 ii libecap3 1.0.1-3.2 ii libexpat12.2.5-3 ii libgcc1 1:8.1.0-9 ii libgnutls30 3.5.18-1 ii libgssapi-krb5-2 1.16-2 ii libkrb5-31.16-2 ii libldap-2.4-2
Bug#897976: arptables bash script installed in /
Package: arptables Version: 0.0.4-1 Severity: normal Try to install this package and then do: ls -l / You'll notice an "arptables" executable bash script, that was clearly meant to be an init script. This can be seen also inspecting the package with: dpkg -L arptables -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages arptables depends on: ii libc6 2.27-3 arptables recommends no packages. arptables suggests no packages. -- no debconf information
Bug#879193: unable to exit mouse grab, segfaults
Package: qemu Version: 1:2.11+dfsg-1 Followup-For: Bug #879193 Problems reported in #879532, #879534, #879536, #879193, are still present in 2.11+dfsg-1. Downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1 is still possible and is still the only way i know to workaround all these problems. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu depends on: ii qemu-system 1:2.11+dfsg-1 ii qemu-user1:2.11+dfsg-1 ii qemu-utils 1:2.11+dfsg-1 qemu recommends no packages. Versions of packages qemu suggests: ii qemu-user-static 1:2.11+dfsg-1 -- no debconf information
Bug#879534: qemu: Cannot move in the monitor's backlog (SDL2?)
Package: qemu Version: 1:2.11+dfsg-1 Followup-For: Bug #879534 Problems reported in #879532, #879534, #879536, #879193, are still present in 2.11+dfsg-1. Downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1 is still possible and is still the only way i know to workaround all these problems. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu depends on: ii qemu-system 1:2.11+dfsg-1 ii qemu-user1:2.11+dfsg-1 ii qemu-utils 1:2.11+dfsg-1 qemu recommends no packages. Versions of packages qemu suggests: ii qemu-user-static 1:2.11+dfsg-1 -- no debconf information
Bug#879536: qemu: Antialias, graphics artifacts and screen corruptions (SDL2?)
Package: qemu Version: 1:2.11+dfsg-1 Followup-For: Bug #879536 Problems reported in #879532, #879534, #879536, #879193, are still present in 2.11+dfsg-1. Downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1 is still possible and is still the only way i know to workaround all these problems. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu depends on: ii qemu-system 1:2.11+dfsg-1 ii qemu-user1:2.11+dfsg-1 ii qemu-utils 1:2.11+dfsg-1 qemu recommends no packages. Versions of packages qemu suggests: ii qemu-user-static 1:2.11+dfsg-1 -- no debconf information
Bug#879532: qemu: Qemu multi-windows problems (SDL2?)
Package: qemu Version: 1:2.11+dfsg-1 Followup-For: Bug #879532 Problems reported in #879532, #879534, #879536, #879193, are still present in 2.11+dfsg-1. Downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1 is still possible and is still the only way i know to workaround all these problems. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu depends on: ii qemu-system 1:2.11+dfsg-1 ii qemu-user1:2.11+dfsg-1 ii qemu-utils 1:2.11+dfsg-1 qemu recommends no packages. Versions of packages qemu suggests: ii qemu-user-static 1:2.11+dfsg-1 -- no debconf information
Bug#879193: unable to exit mouse grab, segfaults
Package: qemu Version: 1:2.10.0+dfsg-2 Followup-For: Bug #879193 I've encountered similar mouse problems with dfsg-2 that were not present with dfsg-1, but i'm currently not able to reproduce it in a deterministic way. Here is my qemu's setup, using Windows 10 as guest OS. qemu-system-x86_64 \ -name windows10pro-64 \ -machine type=pc,accel=kvm,vmport=off,usb=on \ -smp sockets=1,cores=1,threads=2 \ -m 1536M \ -device usb-tablet \ -device qxl-vga \ -device e1000,netdev=net0 \ -device ich9-ahci,id=sata0 \ -device ide-hd,bus=sata0.0,drive=hd0,bootindex=1 \ -device ide-cd,bus=sata0.1,drive=hd1,bootindex=2 \ -netdev user,id=net0 \ -drive if=none,id=hd0,format=qcow2,file="$imgdir/hd30GB_win10-64.qcow2" \ -drive if=none,id=hd1,format=raw,file="$imgdir/iso/microsoft/Win10_1607_Italian_x64.iso" \ -rtc base=localtime \ & With this configuration, in dfsg-1 the mouse pointer were able to escape the guest window without pressing CTRL-ALT. Now with dfsg-2 that mostly works but on two occasions I've found that the mouse could not escape, perhaps as Stéphane reported, even pressing CTRL-ALT. But for me there was a strange exception: i was able to escape only from one side of the window. The first time from the top, the second time from the left. That happened regardless of the CTRL-ALT pressing. However if I replace "usb-tablet" with "usb-mouse", the mouse seems to work correctly, with grabbing controlled only by CTRL-ALT. I've not tested with the integrated PS/2 mouse. Stéphane, what's your qemu's commandline? Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu depends on: ii qemu-system 1:2.10.0+dfsg-2 ii qemu-user1:2.10.0+dfsg-2 ii qemu-utils 1:2.10.0+dfsg-2 qemu recommends no packages. Versions of packages qemu suggests: ii qemu-user-static 1:2.10.0+dfsg-2 -- no debconf information
Bug#879534: qemu: Cannot move in the monitor's backlog (SDL2?)
Package: qemu Version: 1:2.10.0+dfsg-2 Severity: normal I've encountered several issue with this version of qemu and I highly suspect they stem from the SDL2 switch. I will file different bugreports for the problems i've encountered, guessing it's better for the qemu's maintainer. I'm currently using this release on two Intel based PCs: an Haswell laptop (the one on which i'm writing this BR) and an Ivy Bridge desktop, both with an integrated Intel graphics card. On both PC I use an updated Debian Sid with Mate Desktop. Both PC experienced the same problems and on the desktop PC i've workarounded them downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1. I'm going to do this downgrade also on the notebook as soon as i've finished reporting these problems, because here qemu's usability is severely compromised. ### Try this setup: qemu-system-x86_64 \ -name debian-sid-32 \ -machine type=pc,accel=kvm,vmport=off,usb=on \ -smp sockets=1,cores=1,threads=2 \ -m 512 \ -device virtio-keyboard-pci \ -device virtio-tablet-pci \ -device virtio-gpu-pci \ -device virtio-net-pci,netdev=net0 \ -device virtio-scsi-pci \ -device scsi-hd,drive=hd0,bootindex=1 \ -netdev user,id=net0 \ -drive if=none,id=hd0,format=qcow2,discard=on,file="img.qcow2" -rtc base=utc \ & If I press CTRL-ALT-3 to access qemu's monitor, then press "help", i'm not able to scroll back anymore since CTRL-Up, CTRL-Down, CTRL-PgUP and CTRL-PgDown don't work. Downgrading to dfsg1 will restore the documented behaviour. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu depends on: ii qemu-system 1:2.10.0+dfsg-2 ii qemu-user1:2.10.0+dfsg-2 ii qemu-utils 1:2.10.0+dfsg-2 qemu recommends no packages. Versions of packages qemu suggests: ii qemu-user-static 1:2.10.0+dfsg-2 -- no debconf information
Bug#879532: qemu: Qemu multi-windows problems (SDL2?)
Package: qemu Version: 1:2.10.0+dfsg-2 Severity: normal I've encountered several issue with this version of qemu and I highly suspect they stem from the SDL2 switch. I will file different bugreports for the problems i've encountered, guessing it's better for the qemu's maintainer. I'm currently using this release on two Intel based PCs: an Haswell laptop (the one on which i'm writing this BR) and an Ivy Bridge desktop, both with an integrated Intel graphics card. On both PC I use an updated Debian Sid with Mate Desktop. Both PC experienced the same problems and on the desktop PC i've workarounded them downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1. I'm going to do this downgrade also on the notebook as soon as i've finished reporting these problems, because here qemu's usability is severely compromised. ### Try this setup: qemu-system-x86_64 \ -name debian-sid-32 \ -machine type=pc,accel=kvm,vmport=off,usb=on \ -smp sockets=1,cores=1,threads=2 \ -m 512 \ -device virtio-keyboard-pci \ -device virtio-tablet-pci \ -device virtio-gpu-pci \ -device virtio-net-pci,netdev=net0 \ -device virtio-scsi-pci \ -device scsi-hd,drive=hd0,bootindex=1 \ -netdev user,id=net0 \ -drive if=none,id=hd0,format=qcow2,discard=on,file="img.qcow2" -rtc base=utc \ & When I start this VM I immedialtely see what is reported in "01_qemu-starts-two-windows.png" attachement: two windows opens, one for the VM (w1) and one blank Windows (w2) saying "Guest has not initialized the display (yet)". There are different problems with this: - Annoying: the w2 window goes foreground, here covering w1, but the keyboard focus goes to w1; - Dangerous: if you try to close w2, also the VM will close. Since what is showed on w2 is what you previously saw pressing CTRL-ALT-2, you can close that window pressing that key combination. Looks like this is specific to virtio-gpu, because if you use, for example, qxl-vga o cirrus-vga, you don't have that window. Always related to this multiple windows issue is the fact that now if you press CTRL-ALT-2/3/4/5, you obtain 4 different windows, one for each key combination. This can be considered a feature but remain the dangerous fact that closing one of them will abruptly close also the VM. Downgrading to dfsg1 will restore all these windows inside the VM's window. Also, try to play pressing CTRL-ALT-2/3/4/5 and try to switch the focus between them: you will notice that sometimes the key combinations seems to have no effect and sometimes there are focus problems, with the specific window that doesn't get the focus and stay backward. Cesare. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu depends on: ii qemu-system 1:2.10.0+dfsg-2 ii qemu-user1:2.10.0+dfsg-2 ii qemu-utils 1:2.10.0+dfsg-2 qemu recommends no packages. Versions of packages qemu suggests: ii qemu-user-static 1:2.10.0+dfsg-2 -- no debconf information
Bug#852605: util-linux: fdisk l command does not without less installed
Package: util-linux Version: 2.29.2-1 Followup-For: Bug #852605 Hello! Indeed the problem is worse during debian-installer, where less is not available. And if you need to manually partition a GPT disk you will encounter this problem in a rather inconvenient moment. When happened to me i didn't know the PAGER trick, so i had to rely on another PC to discover the partition number to set. I believe that this problem should not be workarounded by Debian or at build time, but should be handled upstream, checking the program existence and providing fallbacks. In the meantime, how about enforcing a dependency on less and include the latter in debian-installer? Or patching the source code to use more rather than less? Cesare. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages util-linux depends on: ii libblkid1 2.29.2-1 ii libc6 2.24-11 ii libfdisk1 2.29.2-1 ii libmount1 2.29.2-1 ii libncursesw5 6.0+20161126-1 ii libpam0g 1.1.8-3.6 ii libselinux12.6-3+b1 ii libsmartcols1 2.29.2-1 ii libsystemd0232-24 ii libtinfo5 6.0+20161126-1 ii libudev1 232-24 ii libuuid1 2.29.2-1 ii zlib1g 1:1.2.8.dfsg-5 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-1 ii kbd 2.0.3-2+b1 pn util-linux-locales -- debconf information: util-linux/noauto-with-nonzero-passnum:
Bug#816781: [Aptitude-devel] Bug#816781: aptitude: Can not cancel pending upgrade actions
On 30/05/2017 22:42, Axel Beckert wrote: So maybe we should be a little bit more verbose with the short description in the menu or maybe even split "Cancel pending actions" into two separate menu entries: * Cancel pending actions of this session * Cancel all pending actions or similar. It will be wonderful to have two entries, because "Cancel all pending actions" is quite self explanatory, will match the previous behaviour I couldn't remember that we changed that, but this change was indeed a bugfix in 0.7.6 from February 2016: * [curses] "Cancel pending actions" now reloads the cache (roughly equivalent to restarting the program), rather than marking all packages as "keep" plus ruining all auto-installed flags and holds (Closes: #537735, #576319) Hi Axel, maybe I misunderstood the part where you talked about splitting "Cancel pending actions": when you said "Cancel all pending actions", you meant also from previous sessions, wasn't it? In this case, from a user point of view, it would almost match the previous behaviour, at least for the fact that there wasn't a concept of session for that command. That's what I wanted to say. However, if it weren't so late in the release cycle, I believe that the best solution would be the one exposed by Drew Parsons, because I fear that who will upgrade from 8 to 9 might find this change surprising. I hope I'm wrong. Post-Stretch: how about replacing "Cancel pending actions" with "Keep all" or "Keep all pending", that does exactly what "Keep" does but for all packages waiting for install/upgrade/remove/purge? And it would do the same of the corresponding command line option. Cesare.
Bug#816781: [Aptitude-devel] Bug#816781: aptitude: Can not cancel pending upgrade actions
On 29/05/2017 11:31, Axel Beckert wrote: Before you press the corresponding menu entry, but after already having selected it, aptitude will show the following long description in the status line: Cancel all pending actions from this session So this menu entry only cancels actions which weren't scheduled in previous sessions on purpose. Thank you Axel for the detailed and clear explanation. I admit i've never noted the string in the status bar... So maybe we should be a little bit more verbose with the short description in the menu or maybe even split "Cancel pending actions" into two separate menu entries: * Cancel pending actions of this session * Cancel all pending actions or similar. It will be wonderful to have two entries, because "Cancel all pending actions" is quite self explanatory, will match the previous behaviour and users should not be surprised upgrading from Debian 8 to 9. But isn't it too late for Stretch? Anyway, I think that making a note at least in NEWS.Debian could be helpful. Cesare.
Bug#816781: aptitude: Can not cancel pending upgrade actions
Package: aptitude Version: 0.8.7-1 Followup-For: Bug #816781 Since some times I'm hitting the following bug and today I've found the time to report it to Debian. Even if it's a different use case, I think it's closely related to this bug, so i'm posting here. Steps to reproduce (always reproducible for me): - Open the TUI; - Press [u] to search for updates; - Review the upgradable package list and press [U] to mark them as upgradable; - Decide to postpone the real upgrade and exit from aptitude; - Re-enter the TUI but for some reason you want aptitude forget all pending actions by pressing the corresponding menu entry; - Observe that aptitude make some work but doesn't actually forget nothing. Note that the same command works as expected if it's given during the same session, without exit. If I understand correctly, Manuel suggests to use the following steps to obtain the same practical effect as cancel pending actions: - With the cursor go on the "Upgradable Packages" tree root. - Package -> Keep Is that correct? But in that case i haven't understood now what the "Cancel pending actions" command is for. Cesare. -- Package-specific info: Terminal: xterm $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.7 Compiler: g++ 6.3.0 20170406 Compiled against: apt version 5.0.1 NCurses version 6.0 libsigc++ version: 2.10.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20161126 cwidget version: 0.5.17 Apt version: 5.0.1 aptitude linkage: linux-vdso.so.1 (0x7ffc688a4000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7f35fc6a2000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f35fc472000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f35fc248000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f35fc041000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f35fbd44000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f35fba3a000) libboost_iostreams.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7f35fb822000) libboost_filesystem.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7f35fb609000) libboost_system.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f35fb405000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7f35faff1000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f35fadd4000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f35faa5) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f35fa74c000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f35fa535000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f35fa197000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f35f9f93000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f35f9d7c000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f35f9b6) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f35f995) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f35f972a000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f35f9518000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f35f931) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f35f9109000) /lib64/ld-linux-x86-64.so.2 (0x55db3ead2000) -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common0.8.7-1 ii libapt-pkg5.0 1.4.4 ii libboost-filesystem1.62.0 1.62.0+dfsg-4 ii libboost-iostreams1.62.0 1.62.0+dfsg-4 ii libboost-system1.62.0 1.62.0+dfsg-4 ii libc6 2.24-10 ii libcwidget3v5 0.5.17-4+b1 ii libgcc11:6.3.0-18 ii libncursesw5 6.0+20161126-1 ii libsigc++-2.0-0v5 2.10.0-1 ii libsqlite3-0 3.16.2-3 ii libstdc++6 6.3.0-18 ii libtinfo5 6.0+20161126-1 ii libxapian301.4.3-2 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-12 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: pn apt-xapian-index pn aptitude-doc-en | aptitude-doc pn debtags ii tasksel 3.39 -- n
Bug#841423: LVM: raid1 kernel module not loaded
Here i've talked about raid1 because it is what i've tested myself, but since LVM can handle raid0/1/4/5/6/10, perhaps the same arguments apply also to the other raid types. For example i've noticed that the initramfs' hook from mdadm takes care of loading all the raid modules: --- for module in linear multipath raid0 raid1 raid456 raid5 raid6 raid10; do force_load $module done --- Maybe should also lvm2's hook load those modules? And in fact if both lvm2 and mdadm are installed, what i'm reporting here doesn't happen: raid modules are loaded by mdadm's hook. Moreover, if i understand correctly, the grub2 package uploaded to unstable 4 days ago (2.02-beta3) is the first that supports booting from an LVM raid1: it would be wonderful if that setup could be supported out of the box in Debian.
Bug#841423: LVM: raid1 kernel module not loaded
Package: initramfs-tools Version: 0.125 Severity: normal Initially i thought to file this bug to lvm2 package but now i suspect it's more related with kernel modules dependencies and the manual_add_modules() hook of initramfs-tools. Suppose your system has lvm2 installed but not mdadm. Now search for the raid modules installed in the initramfs image: lsinitramfs IMG | grep raid You will notice that there are various raid modules loaded but not raid1. LVM is a very flexible system that let's you convert your volume setup from linear to raidN and viceversa, with mounted filesystem. So if you, for example, try to you convert your single disk volume to a two disks raid1 volume, you will have an unbootable system, due to failure of volume activation caused by the missing raid1 module. The workaround it to add "raidi1" to /etc/initramfs-tools/modules and update the initramfs before rebooting. The issue is also described here: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1509717 Indeed it can be asked to the lvm2 maintainer to add "raid1" module to the initramfs hook. Currently /usr/share/initramfs-tools/hooks/lvm2 load these modules: dm_mod dm_snapshot dm_mirror dm_raid But since with the above modules, various raid modules get loaded as dependencies, i wonder why raid1 is not. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 19M Oct 20 13:26 /boot/initrd.img-4.6.0-1-amd64 -rw-r--r-- 1 root root 19M Oct 20 13:25 /boot/initrd.img-4.7.0-1-amd64 -- /proc/cmdline BOOT_IMAGE=/vmlinuz-4.7.0-1-amd64 root=/dev/mapper/vg0-debian--root ro systemd.show_status=1 quiet -- resume RESUME=UUID=165d521e-0cc9-4bf4-bc12-a995e826a649 -- /proc/filesystems ext3 ext2 ext4 vfat -- lsmod Module Size Used by cpuid 16384 0 nls_ascii 16384 1 nls_cp437 20480 1 snd_hda_codec_realtek86016 1 snd_hda_codec_hdmi 45056 1 snd_hda_codec_generic69632 1 snd_hda_codec_realtek vfat 20480 1 fat69632 1 vfat amdkfd126976 1 efi_pstore 16384 0 kvm_amd73728 0 kvm 573440 1 kvm_amd irqbypass 16384 1 kvm efivars20480 1 efi_pstore snd_hda_intel 36864 0 radeon 1490944 1 snd_hda_codec 135168 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel serio_raw 16384 0 pcspkr 16384 0 snd_hda_core 81920 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel evdev 24576 2 k10temp16384 0 ttm98304 1 radeon snd_hwdep 16384 1 snd_hda_codec nuvoton_cir24576 0 drm_kms_helper147456 1 radeon snd_pcm 110592 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core snd_timer 32768 1 snd_pcm drm 364544 4 ttm,drm_kms_helper,radeon sp5100_tco 16384 0 snd81920 8 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel sg 32768 0 soundcore 16384 1 snd i2c_piix4 24576 0 shpchp 36864 0 rc_core28672 1 nuvoton_cir i2c_algo_bit 16384 1 radeon button 16384 0 acpi_cpufreq 20480 0 tpm_tis20480 0 tpm45056 1 tpm_tis xt_tcpudp 16384 1 nf_conntrack_ipv4 20480 5 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 xt_conntrack 16384 5 nf_conntrack 114688 2 xt_conntrack,nf_conntrack_ipv4 iptable_filter 16384 1 sch_fq_codel 20480 3 efivarfs 16384 1 ip_tables 24576 1 iptable_filter x_tables 36864 4 ip_tables,xt_tcpudp,xt_conntrack,iptable_filter autofs440960 2 ext4 589824 2 ecb16384 0 glue_helper16384 0 lrw16384 0 gf128mul 16384 1 lrw ablk_helper16384 0 cryptd 20480 1 ablk_helper aes_x86_64 20480 0 crc16 16384 1 ext4 jbd2 106496 1 ext4 mbcache16384 3 ext4 sr_mod 24576 0 cdrom 57344 1 sr_mod hid_generic16384 0 raid1 36864 2 usbhid 49152 0 hid 118784 2 hid_generic,usbhid dm_raid28672 2 raid456 106496 1 dm_raid async_raid6_recov 20480 1 raid456 async_memcpy 16384 2 raid456,async_raid6_recov async_pq 16384 2 raid456,async_raid6_recov async_xor 16384 3 async_pq,raid456,async_raid6_recov async_tx 16384 5 as
Bug#836246: Acknowledgement (libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop)
I'd like to thank Michael Biebl, the only one who was friendly, who saw the value in this BR and who understood the reason why i opened this bug: to let Debian developer know about a problem after a recent upgrade. I'm really bewildered with those people that looks pissed off by me reporting about problems, blaming me to ignore how unstable works and telling me that i don't have to complain. I'm not complaining about the temporarly Mate breakage (i've found a workaround), and i know that unstable can broke and so on. I only wanted do inform Debian about that and being as detailed as possible to help finding a solution! Including reporting the workaround, to help those users googling around for the same problem. It's all i can do and i assure you that it took time to do all that. I don't understand: isn't it better one more bug report than a bug that propagate to testing or stable unnoticed? Adrian, you said that you cannot reproduce many problems i've reported. Please, i repeat, start a VM, install task-mate-desktop, even without any recommended or suggested packages, and login in lightdm. Now: - You will see that fonts looks ugly and also icons looks strange, with a sort of shadows under them. - Double click on "Computer", or your folder's home or on the trash: you will see that after a flash, nothing happens. - Try to move one of the desktop's icons: you will see different refreshing problems, and the icons in the initial position that doesn't get erased. But it only a graphics artifact: the icons isn't still there anymore, as you can see trying clicking on it or moving, for example, a terminal windows on it, then moving away. Have you tried that? But looks like i've only lost time to investigate and report this bug. Feel free to do what you want with it. Cesare.
Bug#836246: libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop
Package: libgtk-3-0 Version: 3.20.9-1 Severity: normal On three pc of mine i had to downgrade the following libraries to have a functioning desktop: libgail-3-0 libgtk-3-0 libgtk-3-bin Up to version 3.20.9-1 all were fine but with 3.21.5-1 and 3.21.5-2 i had so many issues that i had to find a way to come back to a previous state. These are the issue i can document, but certainly there are others: - caja (file manager) doesn't start at all. - desktop fonts look ugly, like there isn't any antialias. - desktop doesn't repaint correctly: if you move an icon, the older is still there. - mate terminal crash if you try to change color settings. Journalctl reports tons of entries like those, indeed belonging to applets that updates their visualization frequently: -- ago 31 19:52:16 barone mate-cpufreq-ap[15177]: gtk_widget_size_allocate(): attempt to underallocate CPUFreqApplet's child GtkAlignment 0x8049a148. Allocation is 55x24, but minimum required size is 83x24. ago 31 19:52:16 barone mate-cpufreq-ap[15177]: gtk_widget_size_allocate(): attempt to underallocate GtkAlignment's child GtkBox 0x80333fb8. Allocation is 55x24, but minimum required size is 83x24. ago 31 19:52:16 barone mate-cpufreq-ap[15177]: gtk_widget_size_allocate(): attempt to underallocate CPUFreqApplet's child GtkAlignment 0x8049a250. Allocation is 55x24, but minimum required size is 83x24. ago 31 19:52:16 barone mate-cpufreq-ap[15177]: gtk_widget_size_allocate(): attempt to underallocate GtkAlignment's child GtkBox 0x80333ce8. Allocation is 55x24, but minimum required size is 83x24. ago 31 19:52:16 barone clock-applet[15178]: gtk_widget_size_allocate(): attempt to underallocate toplevel GtkPlug 0x80c171d0. Allocation is 178x24, but minimum required size is 178x26. ago 31 19:52:16 barone clock-applet[15178]: gtk_widget_size_allocate(): attempt to underallocate GtkPlug's child MatePanelApplet 0x80adb138. Allocation is 178x24, but minimum required size is 178x26. ago 31 19:52:16 barone clock-applet[15178]: gtk_widget_size_allocate(): attempt to underallocate MatePanelApplet's child GtkToggleButton 0x80ae9898. Allocation is 178x24, but minimum required size is 178x26. ago 31 19:52:16 barone clock-applet[15178]: gtk_widget_size_allocate(): attempt to underallocate GtkToggleButton's child ClockBox 0x80ce14a8. Allocation is 168x14, but minimum required size is 168x16. ago 31 19:52:16 barone clock-applet[15178]: gtk_widget_size_allocate(): attempt to underallocate ClockBox's child ClockBox 0x80ce1598. Allocation is 18x14, but minimum required size is 18x16. ago 31 19:52:16 barone clock-applet[15178]: gtk_widget_size_allocate(): attempt to underallocate ClockBox's child GtkLabel 0x80cddc58. Allocation is 138x14, but minimum required size is 138x15. -- The same issues happened on four different machine, with different gtk theme, adwaita included: a 686, a 686-pae, two amd64. On one of them i've installed a fresh Mate Desktop, so i think we could say that the problem is always reproducible. You can try: i've just installed task-mate-desktop, without any recommended or suggested packages. I don't know what other infos i can provide. I've kept a 686 PC with the broken libraries available in case you need more infos or in case you want me to make some tests. Cesare. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgtk-3-0 depends on: ii adwaita-icon-theme 3.20-3 ii hicolor-icon-theme 0.15-1 ii libatk-bridge2.0-0 2.20.1-4 ii libatk1.0-0 2.20.0-1 ii libc6 2.23-5 ii libcairo-gobject2 1.14.6-1+b1 ii libcairo2 1.14.6-1+b1 ii libcolord2 1.3.2-1 ii libcups22.1.4-4 ii libepoxy0 1.3.1-1 ii libfontconfig1 2.11.0-6.7 ii libfreetype62.6.3-3+b1 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libglib2.0-02.48.1-3 ii libgtk-3-common 3.20.9-1 ii libjson-glib-1.0-0 1.2.2-1 ii libpango-1.0-0 1.40.1-1 ii libpangocairo-1.0-0 1.40.1-1 ii libpangoft2-1.0-0 1.40.1-1 ii librest-0.7-0 0.8.0-1 ii libsoup2.4-12.54.1-1 ii libwayland-client0 1.11.0-2 ii libwayland-cursor0 1.11.0-2 ii libwayland-egl1-mesa [libwayland-egl1] 11.2.2-1 ii
Bug#826680: [Pkg-utopia-maintainers] Bug#826680: network-manager: please move isc-dhcp-client from Depends: to Recommends:
On Tue, 7 Jun 2016 23:49:33 +0200 Michael Biebl wrote: The default configuration still uses isc-dhcp-client, unless it's explicitly configured otherwise. I don't understand this phrase. The default NetworkManager.conf comes with only these directives: -- [main] plugins=ifupdown,keyfile [ifupdown] managed=false -- So why it shouldn't behave like reported in the man page? That is, if the "dhcp" key is missing, "available DHCP clients are looked for in this order: dhclient, dhcpcd, internal". FTR, i also currently use the internal dhcp client without any problem. Cesare.
Bug#833888: kbd: Consider including upstream vlock
On 10/08/2016 14:37, Andreas Henriksson wrote: Please do direct your mails to the bug report rather than to me, so that the information gets properly/publicly archived. (I'll get a copy of it any way.) I'm very sorry, i didn't noticed that my reply was directed to you rather that the bug report. My (possibly incorrect) understanding is that Frank started the fork, rewrote it basically from scratch with a new design and many more features. It's possible. In the meantime i've updated #833843, because i've found that Frank has a github page with a vlock repo, so i think it's the current home of the project. Thank you very much, Andreas, for your suggestions and considerations. Cesare.
Bug#833843: Acknowledgement (vlock: Upstream source not reachable)
I think i've found the current home of the vlock package: https://github.com/toidinamai/vlock The last release is 2.2.3 (2011), while Debian is at 2.2.2. However, the reposistory last commit is 12 may 2009, so no activity from upstream. Cesare.
Bug#827228: [Pkg-running-devel] Bug#827228: pytrainer: Add firefox-esr to the browser dependency list
On 14/06/2016 08:07, Christian PERRIER wrote: Upload is on its way. However, is there indeed a reason to *keep* iceweasel in the dependency list? Hello Christian, any news on that? Currently i'm unable to remove the iceweasel package, because it's a dependency only of pytrainer. I think you could leave iceweasel in the dependency list just for backport reasons. But feel free to remove it entirely. Cesare.
Bug#833843: Acknowledgement (vlock: Upstream source not reachable)
Ouch, i didn't notice that this package was orphaned in 2014... So, given this, and given that kbd Debian package doesn't include the upstream vlock binary, i've opened a bug to kbd as they can reconsider its inclusion. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833888 Maybe it can substitute this package? Cesare.
Bug#833888: kbd: Consider including upstream vlock
Package: kbd Version: 2.0.3-2 Severity: normal Upstream kbd provides a vlock binary but it's not included in the Debian package. Looking from Debian's changelog it's like that since february 2013. I know that Debian already provides a separate vlock package (i use it), but it was last updated in 2014, it is currently orphaned and upstream source looks unreacheable (#833843). In light of this, i wonder if the kbd's vlock inclusion could be reconsidered. I don't know if it could be taken as an entire substitute for the vlock package. Looks like Opensuse, Gentoo and Ubuntu still carry a vlock package from the same source as Debian, while Fedora and Archlinux don't have it in their repository and use the one provided with kbd. Cesare. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kbd depends on: ii libc6 2.23-4 ii lsb-base 9.20160629 Versions of packages kbd recommends: ii console-setup 1.148 kbd suggests no packages. -- no debconf information
Bug#833843: vlock: Upstream source not reachable
Package: vlock Version: 2.2.2-5 Severity: normal I've noted that the copyright entry point to a server that doesn't look to exist enymore: http://cthulhu.c3d2.de/~toidinamai/vlock/archive/ Is upstream still active? Or perhaps now there's a different location and that entry should be updated. Cesare. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vlock depends on: ii adduser 3.115 ii libc6 2.23-4 ii libpam-modules 1.1.8-3.3 ii libpam0g1.1.8-3.3 vlock recommends no packages. vlock suggests no packages. -- no debconf information
Bug#827228: pytrainer: Add firefox-esr to the browser dependency list
Package: pytrainer Version: 1.10.2~git20160107-3 Severity: normal Currently firefox-esr has replaced iceweasel, that became a transitional package. But pytrainer depends on iceweasel or firefox or abrowser, preventing the iceweasel transitional package to be removed. Please, add firefox-esr to the browser dependency list. Cesare. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pytrainer depends on: ii gpsbabel 1.5.2-1 ii iceweasel 45.2.0esr-1 ii python 2.7.11-2 ii python-glade2 2.24.0-4 ii python-gtk22.24.0-4 ii python-libxml2 2.9.3+dfsg1-1.2 ii python-lxml3.6.0-1 ii python-matplotlib 1.5.2~rc2-1 ii python-migrate 0.10.0-4 ii python-numpy 1:1.11.1~rc1-1 ii python-pysqlite2 2.7.0-1 ii python-scipy 0.17.1-1 ii python-soappy 0.12.22-1 ii python-webkit 1.1.8-3.1 pn python:any ii zenity 3.20.0-1 pytrainer recommends no packages. pytrainer suggests no packages. -- no debconf information
Bug#808563: really should be serious bug: data loss
I've done the following tests that seems to prove that the bug is with the PAE kernel, also the last 4.4.0-rc5: * Boot with linux-image-4.4.0-rc5-686 (4.4~rc5-1~exp1): OK. * Boot with linux-image-4.4.0-rc5-686-pae (4.4~rc5-1~exp1): ata errors. * Boot with linux-image-4.3.0-1-686 (4.3.3-2): OK. * Boot with linux-image-4.3.0-1-686-pae (4.3.3-2): ata errors. Also, today i had error both on ata1.00 and ata3.00, while yesterday were only on ata1.00. I've fscked 2 filesystem out of 3 and are ok. In my case looks like that those read/write instructions that timeouts, at the end succeed. Until now with a PAE kernel i can usually trigger the errors with a simple "apt update" and the system is almost unusable with those kernels: too many timeouts. In the meantime i'm now running with non-pae 686 kernel. Cesare.
Bug#808563: really should be serious bug: data loss
On 21/12/2015 17:20, 積丹尼 Dan Jacobson wrote:
ata1.00: exception Emask 0x60 SAct 0x1c SErr 0x800 action 0x6 frozen
ata1.00: irq_stat 0x2000, host bus error
ata1: SError: { HostInt }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/00:10:00:a8:10/08:00:26:00:00/40 tag 2 ncq 1048576 out
res 40/00:20:00:48:11/00:00:26:00:00/40 Emask 0x60 (host bus error)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/00:18:00:b0:10/08:00:26:00:00/40 tag 3 ncq 1048576 out
res 40/00:20:00:48:11/00:00:26:00:00/40 Emask 0x60 (host bus error)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/98:20:00:48:11/03:00:26:00:00/40 tag 4 ncq 471040 out
res 40/00:20:00:48:11/00:00:26:00:00/40 Emask 0x60 (host bus error)
ata1.00: status: { DRDY }
ata1: hard resetting link
I have a RAID1 (mdadm) with two SSD Samsung 850 EVO and these days i was
affected by the same problem with linux-image-4.3.0-1-686-pae (4.3.3-2).
During these errors the system is somehow not responsive for about 30-60
seconds but at the end the operation completes and all keep working
without error or data loss. Mdadm doesn't notice nothing about these
errors: the RAID doesn't get degraded.
But it's quite annoying because happens frequently: about one time every
few minutes.
An excerpt of my errors:
-
dic 22 09:14:26 barone kernel: ata1.00: exception Emask 0x0 SAct 0x700 SErr 0x0
action 0x6 frozen
dic 22 09:14:26 barone kernel: ata1.00: failed command: WRITE FPDMA QUEUED
dic 22 09:14:26 barone kernel: ata1.00: cmd 61/20:40:00:b8:76/07:00:01:00:00/40
tag 8 ncq 933888 out
res 40/00:ff:00:00:00/00:00:00:00:00/00
Emask 0x4 (timeout)
dic 22 09:14:26 barone kernel: ata1.00: status: { DRDY }
dic 22 09:14:26 barone kernel: ata1.00: failed command: WRITE FPDMA QUEUED
dic 22 09:14:26 barone kernel: ata1.00: cmd 61/e0:48:20:bf:76/08:00:01:00:00/40
tag 9 ncq 1163264 out
res 40/00:01:00:00:00/00:00:00:00:00/00
Emask 0x4 (timeout)
dic 22 09:14:26 barone kernel: ata1.00: status: { DRDY }
dic 22 09:14:26 barone kernel: ata1.00: failed command: WRITE FPDMA QUEUED
dic 22 09:14:26 barone kernel: ata1.00: cmd 61/98:50:00:18:77/0e:00:01:00:00/40
tag 10 ncq 1912832 out
res 40/00:ff:00:00:00/00:00:00:00:00/00
Emask 0x4 (timeout)
dic 22 09:14:26 barone kernel: ata1.00: status: { DRDY }
dic 22 09:14:26 barone kernel: ata1: hard resetting link
-
Like you i have an 686-pae 32 bit kernel. Have you got an SSD disk or a
rotational disk?
This morning i've tried linux-image-4.4.0-rc5-686 (4.4~rc5-1~exp1) from
experimental and everything works fine without errors. Tomorrow i'll try
the pae version from experimental to see if it works too.
Cesare.
Bug#786382: Bug resolved
Today i've upgraded my system and the problem looks resolved. For details, see the bug opened upstream: https://bugs.freedesktop.org/show_bug.cgi?id=90617 To me this bug can be closed. Cesare.
Bug#786382: linux-image-4.0.0-1-amd64: Blank screen switching to a VT (Intel Haswell with HD4400)
When I replied I did not realize that what you intended for upstream was freedesktop.org, not kernel.org. I've just filed the bug upstream, as you requested: https://bugs.freedesktop.org/show_bug.cgi?id=90617 Also, in my initial message i did a typo in the notebook model: it's a PU301LA (not LS). Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786382: linux-image-4.0.0-1-amd64: Blank screen switching to a VT (Intel Haswell with HD4400)
2015-05-21 11:28 GMT+02:00 Julien Cristau : > Please file this upstream at > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel > See instructions at > https://01.org/linuxgraphics/documentation/development/how-report-bugs Ok, i'll do. I only ask to the kernel team if you intend to upload an updated package to sid/experimental in the next days, since upstream is two minor version ahead and the regression could be already resolved. Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786382: linux-image-4.0.0-1-amd64: Blank screen switching to a VT (Intel Haswell with HD4400)
Package: src:linux Version: 4.0.2-1 Severity: normal Since kernel version 4.0 (also the previous 4.0.0-trunk from experimental) if i try to switch to a VT from an X session (also from the login manager), the screen becomes black and i'm not able to recover from that situation, neither for the X session. That's always reproducible and i wasn't able to find a workaround. After that you can observe: - the system is not freezed and you can work blindly. - the display shows no output but is powered on: the backlight is on and i can change its brightness. After a reboot, looking in the log i always find two message like those: - mag 21 07:35:40 etna kernel: [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A mag 21 07:35:40 etna kernel: [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun - So it looks like an Intel specific bug. This is an Asuspro PU301LS notebook, with Haswell i7 4500U and HD4400. I had suspected for the "acpi_osi=" kernel parameter that i use to make the backlight works properly, but i found that removing it makes no difference. Note also that if i don't try to switch to a VT, i'm able to works apparently without problems, like now while i'm writing this bug. Cesare. -- Package-specific info: ** Version: Linux version 4.0.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-1-amd64 root=UUID=7ceeef59-c58b-4cfd-b0fd-0482493e48e7 ro quiet systemd.show_status=1 resume=UUID=64fe3b9b-edc0-4672-8c97-be86387d54eb acpi_osi= ** Not tainted ** Kernel log: [9.054357] Bluetooth: Core ver 2.20 [9.054367] NET: Registered protocol family 31 [9.054368] Bluetooth: HCI device and connection manager initialized [9.054370] Bluetooth: HCI socket layer initialized [9.054372] Bluetooth: L2CAP socket layer initialized [9.054378] Bluetooth: SCO socket layer initialized [9.082513] usbcore: registered new interface driver btusb [9.121965] usbcore: registered new interface driver ath3k [9.150369] cfg80211: Calling CRDA to update world regulatory domain [9.158759] asus_wmi: ASUS WMI generic driver loaded [9.159168] asus_wmi: Initialization: 0x1 [9.159203] asus_wmi: BIOS WMI version: 7.9 [9.159241] asus_wmi: SFUN value: 0x4a0877 [9.160159] input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input16 [9.166316] asus_wmi: Backlight controlled by ACPI video driver [9.417111] psmouse serio4: elantech: assuming hardware version 4 (with firmware version 0x490f06) [9.428857] psmouse serio4: elantech: Synaptics capabilities query result 0x50, 0x15, 0x0a. [9.487041] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio4/input/input15 [9.705782] ath: phy0: Set parameters for CUS198 [9.705785] ath: phy0: Set BT/WLAN RX diversity capability [9.711468] ath: phy0: Enable LNA combining [9.712562] ath: EEPROM regdomain: 0x60 [9.712563] ath: EEPROM indicates we should expect a direct regpair map [9.712564] ath: Country alpha2 being used: 00 [9.712565] ath: Regpair used: 0x60 [9.885792] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [9.886024] ieee80211 phy0: Atheros AR9485 Rev:1 mem=0xc9000508, irq=19 [ 10.176217] [drm] Memory usable by graphics device = 2048M [ 10.176221] checking generic (e000 30) vs hw (e000 1000) [ 10.176222] fb: switching to inteldrmfb from simple [ 10.176248] Console: switching to colour dummy device 80x25 [ 10.176308] [drm] Replacing VGA console driver [ 10.199646] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 10.199649] [drm] Driver supports precise vblank timestamp query. [ 10.199741] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 10.252567] fbcon: inteldrmfb (fb0) is primary device [ 10.253880] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 10.255185] media: Linux media interface: v0.10 [ 10.269137] Linux video capture interface: v2.00 [ 10.403276] AVX2 version of gcm_enc/dec engaged. [ 10.403276] AES CTR mode by8 optimization enabled [ 10.405077] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) [ 10.465136] EXT4-fs (sda4): re-mounted. Opts: (null) [ 10.586087] alg: No test for crc32 (crc32-pclmul) [ 10.725375] uvcvideo: Found UVC 1.00 device USB2.0 UVC HD Webcam (13d3:5188) [ 10.731328] input: USB2.0 UVC HD Webcam as /devices/pci:00/:00:1d.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input17 [ 10.731401] usbcore: registered new interface driver uvcvideo [ 10.731402] USB Video Class driver (1.1.1) [ 11.273308] cfg80211: Calling CRDA to update world regulatory domain [ 11.316800] Console: switching to colour frame buffer device 170x48 [ 11.319258] i915 :00:02.0: fb0: inteldrmfb frame buffer device [ 11.319259] i
Bug#784627: lightdm-gtk-greeter: the clock no longer appears
Package: lightdm-gtk-greeter Version: 2.0.0-2 Followup-For: Bug #784627 I confirm what reported by Vincent. As him, i've upgraded from 1.8.5-2 to 2.0.0-2 and since then the clock is not displayed anymore. It's the same if i comment my customized "clock-format" and leave only "show-clock=true". Same /var/log/lightdm/x-0-greeter.log as Vincent, with the added following warning due to suggested accountservice package not installed: ** (lightdm-gtk-greeter:1123): WARNING **: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files Cesare. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lightdm-gtk-greeter depends on: ii libc6 2.19-18 ii libcairo2 1.14.0-2.1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.44.0-2 ii libgtk-3-0 3.14.5-1 ii liblightdm-gobject-1-0 1.14.0-1 ii libx11-62:1.6.3-1 Versions of packages lightdm-gtk-greeter recommends: ii desktop-base 8.0.2 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-themes-standard 3.14.2.2-1 ii policykit-10.105-8 lightdm-gtk-greeter suggests no packages. -- Configuration Files: /etc/lightdm/lightdm-gtk-greeter.conf changed: [greeter] background=/usr/share/images/desktop-base/login-background.svg theme-name=Adwaita xft-antialias=true xft-hintstyle=hintfull xft-rgba=rgb show-indicators=~language;~session;~power show-clock=true clock-format=%A %d %B %Y - %H:%M:%S -- 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#784310: apt update always fails on experimental/non-free
On 05/05/2015 14:58, Axel Beckert wrote: I though currently can't reproduce it on i386. I was almost sure that i got the error on a i386 PC of mine but since i haven't really tried for some time, the doubt started to arise and since your reply i've run some tests. I confirm what Axel said: the error doesn't show under i386. And i've verified also on another i386 PCs (up to date Sid). Then i've verified with two KVM virtual machine, both with updated Sid, same sources.list, but one i386 and one amd64: i can see the error only on amd64. To be honest, now, while writing this mail, on the first i386 PC tested, i get error on experimental/main, but only using httpredir in sources.list and only in the first run after changing mirror. Don't know what to think... Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784310: apt update always fails on experimental/non-free
Package: apt Version: 1.0.9.9 Severity: normal Since months i have an error during the apt update phase, always on experimental/non-free. Initially i thought it was a temporary mirror problem, because changing the repository the error went away. But when in the next days i was doing another update, the error came back, even with the changed mirror. It happens on at least two machine of mine, an i386 and an amd64 arch, with substantially the same sources.list and i think it started to show this behaviour at the same time. And it happens with aptitude too. Apart from sources.list, i think i've never changed nothing from default apt setup. Try these steps, to me are always reproducible: - Take my sources.list. - If you are currently using the same mirror like mine, change it. - apt update - Look that no error are displayed: everything is correctly updated. - Rerun: apt update - Here i see an "Err" line on experimental/non-free Packages. Here is my output: - root@etna:~# apt update Get:1 http://httpredir.debian.org unstable InRelease [204 kB] Get:2 http://httpredir.debian.org experimental InRelease [162 kB] Get:3 http://httpredir.debian.org unstable/contrib Translation-en [42,1 kB] Get:4 http://httpredir.debian.org unstable/main Translation-en [4.878 kB] Get:5 http://httpredir.debian.org unstable/non-free Translation-en [76,4 kB] Get:6 http://httpredir.debian.org experimental/contrib Translation-en [4.527 B] Get:7 http://httpredir.debian.org experimental/main Translation-en [429 kB] Get:8 http://httpredir.debian.org unstable/main amd64 Packages [7.189 kB] Get:9 http://httpredir.debian.org experimental/non-free Translation-en [10,2 kB] Get:10 http://httpredir.debian.org experimental/contrib amd64 Packages [6.144 B] Get:11 http://httpredir.debian.org experimental/non-free amd64 Packages [13,9 kB] Get:12 http://httpredir.debian.org unstable/non-free amd64 Packages [89,2 kB] Get:13 http://httpredir.debian.org unstable/contrib amd64 Packages [54,1 kB] Get:14 http://httpredir.debian.org experimental/main amd64 Packages [737 kB] Fetched 13,9 MB in 24s (568 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 34 packages can be upgraded. Run 'apt list --upgradable' to see them. root@etna:~# root@etna:~# apt update Get:1 http://httpredir.debian.org unstable InRelease [204 kB] Hit http://httpredir.debian.org experimental InRelease Get:2 http://httpredir.debian.org experimental/contrib amd64 Packages/DiffIndex [7.819 B] Get:3 http://httpredir.debian.org experimental/main amd64 Packages/DiffIndex [7.819 B] Get:4 http://httpredir.debian.org experimental/non-free amd64 Packages/DiffIndex [7.819 B] Get:5 http://httpredir.debian.org experimental/contrib Translation-en/DiffIndex [7.819 B] Get:6 http://httpredir.debian.org experimental/main Translation-en/DiffIndex [7.819 B] Get:7 http://httpredir.debian.org experimental/non-free Translation-en/DiffIndex [7.819 B] Get:8 http://httpredir.debian.org unstable/main amd64 Packages/DiffIndex [7.876 B] Get:9 http://httpredir.debian.org unstable/non-free amd64 Packages/DiffIndex [7.819 B] Get:10 http://httpredir.debian.org unstable/contrib amd64 Packages/DiffIndex [7.819 B] Get:11 http://httpredir.debian.org unstable/contrib Translation-en/DiffIndex [7.819 B] Get:12 http://httpredir.debian.org unstable/main Translation-en/DiffIndex [7.876 B] Get:13 http://httpredir.debian.org unstable/non-free Translation-en/DiffIndex [7.819 B] Err http://httpredir.debian.org experimental/non-free amd64 Packages Hit http://httpredir.debian.org experimental/non-free amd64 Packages Fetched 298 kB in 4s (66,2 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 34 packages can be upgraded. Run 'apt list --upgradable' to see them. root@etna:~# - So when you change mirror and update for the first time you get no error. And that's why in the past i thought was a mirror problem: because changing mirror the error apparently went away. But on subsequently updates the error is always present. Cesare. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Esse
Bug#769299: qemu: Readconfig doesn't recognize memory option
Package: qemu Version: 2.1+dfsg-7 Severity: normal The following option is not recognized by qemu config file: [memory] size = "512" To reproduce, follow these steps: * download a memtest image to run with qemu. I've used the live CD SystemRescueCD, that include memtest. * Start qemu with the following command line: qemu-system-x86_64 -m 512 -cdrom \ cd_systemrescuecd-x86-4.4.0.iso --writeconfig a.txt * In the boot menu select: Run system tools from floppy disk image -> MEMTEST * Look that memtest correctly reports 512 MB of ram. The previous qemu command line have created the "a.txt" config file, based on the options used in the command line. So now you can run: qemu-system-x86_64 -readconfig a.txt For me the amount of ram reported by memtest now is 128 MB, the qemu default, showing that the memory option got ignored. Cesare. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu depends on: ii qemu-system 2.1+dfsg-7 ii qemu-user2.1+dfsg-7 ii qemu-utils 2.1+dfsg-7 qemu recommends no packages. Versions of packages qemu suggests: pn qemu-user-static -- 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#769222: Aptitude screenshot
Here is my current situation, before i run "dpkg --configure -a".
Bug#769222: aptitude: Frequent pending actions left
Package: aptitude
Version: 0.6.11-1+b1
Severity: normal
On three different PCs (Debian unstable, i386, 32 bit) i'm frequently
encountering a problem, where aptitude (curses interface), without any
error to the user, leaves some package in an incomplete state.
I usually follow these steps:
- run aptitude from the curses interface.
- update the package list.
- install all the available upgrade.
This process always goes fine, but if after run deborphan it says:
---
deborphan: The status file is in an improper state.
One or more packages are marked as half-installed, half-configured,
unpacked, triggers-awaited or triggers-pending. Exiting.
---
And it is right, because if i return to aptitude, and press "g", i find
a list of some partially installed package.
For example, today in the machine from where i'm reporting this bug, i
can see the attached situation.
If i run "dpkg -C" it says:
---
The following packages are awaiting processing of triggers that they
have activated in other packages. This processing can be requested
using
dselect or dpkg --configure --pending (or dpkg --triggers-only):
libwmf0.2-7:amd64Windows metafile conversion library
The following packages have been triggered, but the trigger processing
has not yet been done. Trigger processing can be requested using
dselect or dpkg --configure --pending (or dpkg --triggers-only):
libgdk-pixbuf2.0-0:amd64 GDK Pixbuf library
---
Aptitude seems not able to correct this situation: if you press "g",
then "g" to repeat the install process, nothing happens. Using the
aptitude curses interface i'm usually able to clean this situation
reinstalling ("L") the packages listes as partially installed.
But i prefer to resolve with this command:
dpkg --configure -a
I'm not sure, but i believe that this problem appeared after one of the
recent dpkg upgrade.
Cesare.
-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude
aptitude version information:
aptitude 0.6.11 compiled at Nov 8 2014 13:34:39
Compiler: g++ 4.9.1
Compiled against:
apt version 4.12.0
NCurses version 5.9
libsigc++ version: 2.4.0
Gtk+ support disabled.
Qt support disabled.
Current library versions:
NCurses version: ncurses 5.9.20140913
cwidget version: 0.5.17
Apt version: 4.12.0
aptitude linkage:
linux-vdso.so.1 (0x7fff8bb9b000)
libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
(0x7f81267fa000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
(0x7f81265c4000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x7f8126399000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7f8126193000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x7f8125e7d000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f8125bb4000)
libboost_iostreams.so.1.55.0 =>
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7f812599c000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7f812558b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f812536d000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f8125062000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8124d61000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f8124b4a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f81247a1000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f812459e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8124399000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f812417e000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
(0x7f8123f6e000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8123d4a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f8123b42000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f812393c000)
/lib64/ld-linux-x86-64.so.2 (0x7f81271cf000)
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages aptitude depends on:
ii aptitude-common 0.6.11-1
ii libapt-pkg4.121.0.9.3
ii libboost-iostreams1.55.0 1.55.0+dfsg-3
ii libc6 2.19-13
ii libcwidget3 0.5.17-2
ii libgcc1 1:4.9.2-1
ii libncursesw5 5.9+20140913-1
ii libsigc++-2.0-0c2a2.4.0-1
ii libsqlite3-0 3.8.7.1-1
ii libstdc++64.9.2-1
ii libtinfo5 5.9+20140913-1
ii libxapian22 1.2.19-1
Versions of packages ap
Bug#767359: [Pkg-xfce-devel] Bug#767359: Bug#767359: lightdm: Selected session not remembered anymore
On 31/10/2014 15:46, Yves-Alexis Perez wrote: > First, it seems that between 1.10.2-2 and 1.10.2-3 the “last > started session” state of lightdm-gtk-greeter (found in > /var/lib/lightdm/.cache/lightdm-gtk-greeter/state) is not saved. On one PC (the one with 1.10.2-3), if i login with session xfce, here is the content of the state file: -- [greeter] last-user=cesare last-session=xfce -- After logging out the content get this: -- [greeter] last-user=*other last-session=xfce -- After "systemctl restart lightdm": -- [greeter] last-user=*other -- On the other PC (the one with the latest 1.10.3-2), if i login with session mate, here is the content of the state file: -- [greeter] last-user=berni\leonardic last-session=mate -- The user name format is because the he is part of a samba domain. After logging out the content get this: -- [greeter] last-user=*other last-session=mate -- After "systemctl restart lightdm": -- greeter] last-user=*other -- > In -3, it seems that the file content (or maybe the file itself) > is lost, which means the settings are not correctly loaded. Yes, the last-session row somehow get deleted: on lightdm shutdown or on startup. > The second issue is that the per-user “last session” (saved in > .dmrc) is not loaded at all. When you enter your username (or > select it from the menu), the user language is loaded (you can see > it change on the top right if it's different from the default > language). At that point, the last user session should be saved > too, but it's not, for some reason. On both PC, .dmrc look always correct and updated every time. Just discarded. In case of request or follow-up, i'll reply you on monday, when i'll come back to work. Best regards. Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767359: [Pkg-xfce-devel] Bug#767359: Bug#767359: lightdm: Selected session not remembered anymore
On 31/10/2014 09:42, Yves-Alexis Perez wrote: > Actually, I think it might not be related to 1.10.2-3 changes, but > rather the new upstream release 1.10.3. It has a NEWS entry: > > * Don't access .dmrc files until information from these files is > required I've done some tests and looks like you are wrong. :-) First, i see the behaviour reported in this bug on two PC, with many similarities: * i386 architecture * regularly updated Debian unstable * Xfce and Mate installed * lightdm-gtk-greeter On one of these PC (the one which this bug comes from), some days ago i've work arounded with: update-alternatives --display x-session-manager On the other i've done what you requested. First from snapshot.debian.org i've downloaded "lightdm_1.10.2-2_i386.deb" and "lightdm_1.10.2-3_i386.deb". Downgrading lightdm to 1.10.2-2 restore the previous behaviour and i've tested following these steps: * systemctl restart lightdm * login changing from default to mate session * logout * systemctl restart lightdm Now if i insert the same username and password in the loginbox, then go to session dropdown menu, i still see "mate". Upgrading to 1.10.2-3 and repeating the steps above, after the last restart of lightdm i see the default session restored. And in this situation here is my .dmrc after login with Mate: [Desktop] Session=mate Language=it_IT.utf8 Layout=it Note that if i simply logout (without rebooting or restarting lightdm), my choice is retained. Thank you for looking into this. Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767359: lightdm: Selected session not remembered anymore
Package: lightdm Version: 1.10.3-2 Severity: normal Suppose you have installed multiple desktop environment (in my case XFCE and MATE). At the lightdm login there is the icon that let you choose which one to start: default, mate, xfce. Well, since some lightdm version (if i recall correctly 1.10.2-3), the user choice is not remembered anymore between reboot and default is always restored. A problem if default is not what you want. So now if you want to keep your preference, you have to use the less obvious and more hidden: update-alternatives --display x-session-manager Is it a bug or is it on purpose? -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.17-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lightdm depends on: ii adduser3.113+nmu3 ii dbus 1.8.8-2 ii debconf [debconf-2.0] 1.5.53 ii libc6 2.19-12 ii libgcrypt201.6.2-4 ii libglib2.0-0 2.42.0-2 ii libpam-systemd 215-5+b1 ii libpam0g 1.1.8-3.1 ii libxcb11.10-3 ii libxdmcp6 1:1.1.1-1 ii lightdm-gtk-greeter [lightdm-greeter] 1.8.5-1 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+7 Versions of packages lightdm suggests: pn accountsservice ii upower 0.99.1-3 -- Configuration Files: /etc/apparmor.d/lightdm-guest-session be13115edc7bacad59293acb370e89ac [Errno 2] No such file or directory: u'/etc/apparmor.d/lightdm-guest-session be13115edc7bacad59293acb370e89ac' -- debconf information: lightdm/daemon_name: /usr/sbin/lightdm * shared/default-x-display-manager: lightdm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740942: [samba] /etc/init.d/samba forbit systemd shutdown system
Package: samba Version: 2:4.1.11+dfsg-1 Followup-For: Bug #740942 Some notes. On shutdown/reboot, occasionally i see this message from systemd, with a countdown and a moving asterisk: - A stop job is running for LSB: ensure samba daemons are started (nmbd and smbd) ( 3 min 2 s / 5 min ) - But normally it's just silent. Launching this: date ; systemctl stop samba ; date In /var/log/syslog i see: Sep 23 08:58:26 barone systemd[1]: samba.service stopping timed out. Terminating. Sep 23 08:58:26 barone samba[1324]: Stopping samba-ad-dc (via systemctl): samba-ad-dc.service Sep 23 08:58:26 barone systemd[1]: Unit samba.service entered failed state. Sep 23 08:58:27 barone samba-ad-dc[1383]: Stopping Samba AD DC daemon: samba. On the command line, the delay happens with both these commands: systemctl stop samba service samba stop But with the old way there is no delay and there is some informative output: /etc/init.d/samba stop * Stopping samba-ad-dc (via systemctl): samba-ad-dc.service * Stopping smbd (via systemctl): smbd.service * Stopping nmbd (via systemctl): nmbd.service Launching the previous commands like that: date ; /etc/init.d/samba-ad-dc stop ; date; sleep 2 ; /etc/init.d/smbd stop ; date ; sleep 2 ; /etc/init.d/nmbd stop ; date mar 23 set 2014, 09.13.26, CEST [ ok ] Stopping samba-ad-dc (via systemctl): samba-ad-dc.service. mar 23 set 2014, 09.13.27, CEST [ ok ] Stopping smbd (via systemctl): smbd.service. mar 23 set 2014, 09.13.30, CEST [ ok ] Stopping nmbd (via systemctl): nmbd.service. mar 23 set 2014, 09.13.33, CEST In /var/log/syslog i see some moessages: Sep 3 09:13:27 barone samba-ad-dc[1661]: Stopping Samba AD DC daemon: samba. Sep 23 09:13:29 barone smbd[1311]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to delete pidfile /var/run/samba/smbd.pid. Error was No such file or directory Sep 23 09:13:30 barone smbd[1694]: Stopping SMB/CIFS daemon: smbd. Sep 23 09:13:32 barone nmbd[1280]: STATUS=daemon 'nmbd' finished starting up and ready to serve connectionsGot SIGTERM: going down... Sep 23 09:13:33 barone nmbd[1727]: Stopping NetBIOS name server: nmbd. Moreover, the following separate commands shows no delay: systemctl stop samba-ad-dc.service systemctl stop smbd.service systemctl stop nmbd.service But if after those i run the following (namely with the three services already stopped), it just delay for 5 min as usual: systemctl stop samba The following doesn't help either: systemctl stop winbind systemctl stop samba Cesare. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages samba depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.13 ii libasn1-8-heimdal1.6~rc2+dfsg-8 ii libbsd0 0.7.0-2 ii libc62.19-11 ii libcomerr2 1.42.12-1 ii libhdb9-heimdal [heimdal-hdb-api-8] 1.6~rc2+dfsg-8 ii libkdc2-heimdal 1.6~rc2+dfsg-8 ii libkrb5-26-heimdal 1.6~rc2+dfsg-8 ii libldb1 1:1.1.17-1 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpopt0 1.16-10 ii libpython2.7 2.7.8-7 ii libroken18-heimdal 1.6~rc2+dfsg-8 ii libtalloc2 2.1.1-2 ii libtdb1 1.3.0-1.1 ii libtevent0 0.9.21-1 ii lsb-base 4.1+Debian13 ii multiarch-support2.19-11 ii procps 1:3.3.9-7 ii python 2.7.8-1 ii python-dnspython 1.12.0-1 ii python-ntdb 1.0-5 ii python-samba 2:4.1.11+dfsg-1 pn python2.7:any ii samba-common 2:4.1.11+dfsg-1 ii samba-common-bin 2:4.1.11+dfsg-1 ii samba-dsdb-modules 2:4.1.11+dfsg-1 ii samba-libs 2:4.1.11+dfsg-1 ii tdb-tools1.3.0-1.1 ii update-inetd 4.43 Versions of packages samba recommends: ii attr 1:2.4.47-2 ii logrotate 3.8.7-1 ii samba-vfs-modules 2:4.1.11+dfsg-1 Versions of packages samba suggests: ii bind9 1:9.9.5.dfsg-4 ii bind9utils 1:9.9.5.dfsg-4 pn ctdb pn ldb-tools ii ntp1:4.2.6.p5+dfsg-3.1 pn smbldap-tools ii winbind2:4.1.11+dfsg-1 -- debconf information: samba/run_mode: daemons samba-c
Bug#740942: [samba] /etc/init.d/samba forbit systemd shutdown system
Package: samba Version: 2:4.1.11+dfsg-1 Followup-For: Bug #740942 I'm experiencing the same problem: 5 minute to shutdown samba service and the same if i try to stop it on the command line. I believed it was related to the fact that i use samba also to login in an active domain but this bug report makes me think it could be unrelated. I'm not 100% sure, but i think i'm experiencing this since the latest upgrade to systemd 215-4. >From this bug report i still haven't get what is the reason for this delay and i'm currently unable to workaround it. Let me know if you need any other infos, config file or else. Cesare. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages samba depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.13 ii libasn1-8-heimdal1.6~rc2+dfsg-8 ii libbsd0 0.7.0-2 ii libc62.19-11 ii libcomerr2 1.42.12-1 ii libhdb9-heimdal [heimdal-hdb-api-8] 1.6~rc2+dfsg-8 ii libkdc2-heimdal 1.6~rc2+dfsg-8 ii libkrb5-26-heimdal 1.6~rc2+dfsg-8 ii libldb1 1:1.1.17-1 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpopt0 1.16-10 ii libpython2.7 2.7.8-7 ii libroken18-heimdal 1.6~rc2+dfsg-8 ii libtalloc2 2.1.1-2 ii libtdb1 1.3.0-1.1 ii libtevent0 0.9.21-1 ii lsb-base 4.1+Debian13 ii multiarch-support2.19-11 ii procps 1:3.3.9-7 ii python 2.7.8-1 ii python-dnspython 1.12.0-1 ii python-ntdb 1.0-5 ii python-samba 2:4.1.11+dfsg-1 pn python2.7:any ii samba-common 2:4.1.11+dfsg-1 ii samba-common-bin 2:4.1.11+dfsg-1 ii samba-dsdb-modules 2:4.1.11+dfsg-1 ii samba-libs 2:4.1.11+dfsg-1 ii tdb-tools1.3.0-1.1 ii update-inetd 4.43 Versions of packages samba recommends: ii attr 1:2.4.47-2 ii logrotate 3.8.7-1 ii samba-vfs-modules 2:4.1.11+dfsg-1 Versions of packages samba suggests: ii bind9 1:9.9.5.dfsg-4 ii bind9utils 1:9.9.5.dfsg-4 pn ctdb pn ldb-tools ii ntp1:4.2.6.p5+dfsg-3.1 pn smbldap-tools ii winbind2:4.1.11+dfsg-1 -- debconf information: samba-common/title: samba/run_mode: daemons -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761881: flashplugin-nonfree: Timeout behind proxy
> I just added a timeout of 15 seconds in get-upstream-version.pl. Maybe this > is > already sufficient for you. Can you try this please ? (First remove > /var/cache/flashplugin-nonfree/get-upstream-version.pl and then run > update-flashplugin-nonfree --status.) Thank you for looking into this. And sure, i can try it. Where can i find your modified version? Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761881: flashplugin-nonfree: Timeout behind proxy
Package: flashplugin-nonfree Version: 1:3.6 Severity: normal Please, add some timeout to wget, both in update-flashplugin-nonfree and in get-upstream-version.pl. If you are behind a proxy and you do the package install/upgrade or "update-flashplugin-nonfree --status", they hang forever (or for a very long time), forcing you to CTRL+C or kill wget. The timeout policy you used in Pepper is much better: aftet about 10-15 seconds it give up. Cesare. -- Package-specific info: Debian version: jessie/sid Architecture: i386 Package version: 1:3.6 Adobe Flash Player version: LNX 11,2,202,406 MD5 checksums: 29c43026b54d7525f196a510314ad9ee /var/cache/flashplugin-nonfree/get-upstream-version.pl 5b1afa315cca86c6c70b05d0797a3516 /var/cache/flashplugin-nonfree/install_flash_player_11_linux.i386.tar.gz 94b8b44d9ddaa0f2eb84ca7cbd06da1d /usr/lib/flashplugin-nonfree/libflashplayer.so Alternatives: flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'. lrwxrwxrwx 1 root root 34 Sep 16 15:21 /usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so /usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to `/etc/alternatives/flash-mozilla.so' -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.16-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flashplugin-nonfree depends on: ii binutils 2.24.51.20140903-1 ii ca-certificates20140325 ii debconf [debconf-2.0] 1.5.53 ii gnupg 1.4.18-4 ii libatk1.0-02.12.0-1 ii libcairo2 1.12.16-5 ii libcurl3-gnutls7.38.0-1 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-1.1 ii libgcc11:4.9.1-14 ii libglib2.0-0 2.40.0-5 ii libgtk2.0-02.24.24-1 ii libnspr4 2:4.10.7-1 ii libnss32:3.17-1 ii libpango1.0-0 1.36.7-1 ii libstdc++6 4.9.1-14 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.2-1 ii libxt6 1:1.1.4-1 ii wget 1.15-1+b1 flashplugin-nonfree recommends no packages. Versions of packages flashplugin-nonfree suggests: pn flashplugin-nonfree-extrasound ii fonts-dejavu2.34-1 pn hal ii iceweasel 31.1.0esr-1 pn konqueror-nsplugins ii ttf-mscorefonts-installer 3.5 pn ttf-xfree86-nonfree -- 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#746448: linux-image-3.14-1-486: acpi-cpufreq not loaded on some older system
Package: src:linux Version: 3.14.2-1 Severity: normal On some older PCs like mine, the acpi-cpufreq module doesn't load anymore with 3.14 kernel (also with the previous rc7 from experimental) so i'm currently stuck with 3.13. The effect on my notebook is that the cpu runs always at full speed, the fan never stop and the system consume a lot of power. Upstream are aware of this and the patch are waiting to be included in some kernel: https://bugzilla.kernel.org/show_bug.cgi?id=73781 https://patchwork.kernel.org/patch/4090951/ I don't know if it will be accepted, included in the current 3.14 branch or in the next 3.15, but if you think it's worth, please consider to apply to the Debian kernel. Cesare. -- Package-specific info: ** Version: Linux version 3.14-1-486 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-16) ) #1 Debian 3.14.2-1 (2014-04-28) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.14-1-486 root=UUID=07b633c9-1242-48ee-a6f4-f37c43f639fd ro quiet systemd.show_status=true lapic hpet=force ** Not tainted ** Kernel log: [6.932851] ACPI: AC Adapter [ACAD] (on-line) [7.039402] [drm] Initialized drm 1.1.0 20060810 [7.049317] yenta_cardbus :02:04.0: CardBus bridge found [104d:818f] [7.049335] yenta_cardbus :02:04.0: Using CSCINT to route CSC interrupts to PCI [7.049338] yenta_cardbus :02:04.0: Routing CardBus interrupts to PCI [7.049344] yenta_cardbus :02:04.0: TI: mfunc 0x01001b22, devctl 0x64 [7.172292] [drm] Memory usable by graphics device = 128M [7.175803] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [7.175809] [drm] Driver supports precise vblank timestamp query. [7.175901] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [7.240007] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 [7.278234] [drm] initialized overlay support [7.284095] yenta_cardbus :02:04.0: ISA IRQ mask 0x0cf8, PCI irq 9 [7.284101] yenta_cardbus :02:04.0: Socket status: 3006 [7.284106] pci_bus :02: Raising subordinate bus# of parent bus (#02) from #02 to #06 [7.284117] yenta_cardbus :02:04.0: pcmcia: parent PCI bridge window: [io 0x3000-0x3fff] [7.284122] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3000-0x3fff: [7.285333] excluding 0x3000-0x303f 0x3400-0x34ff 0x3800-0x38ff [7.293667] yenta_cardbus :02:04.0: pcmcia: parent PCI bridge window: [mem 0xe020-0xe02f] [7.293673] pcmcia_socket pcmcia_socket0: cs: memory probe 0xe020-0xe02f: [7.293676] excluding 0xe020-0xe020 [7.293689] yenta_cardbus :02:04.0: pcmcia: parent PCI bridge window: [mem 0x4000-0x43ff pref] [7.293694] pcmcia_socket pcmcia_socket0: cs: memory probe 0x4000-0x43ff: [7.293705] excluding 0x4000-0x43ff [7.374330] fbcon: inteldrmfb (fb0) is primary device [7.462336] ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 5 [7.462338] PCI: setting IRQ 5 as level-triggered [7.484013] tifm_core: MMC/SD card detected in socket 0:0 [7.498470] intel_rng: FWH not detected [7.689867] lib80211: common routines for IEEE802.11 drivers [7.689868] lib80211_crypt: registered algorithm 'NULL' [7.729248] sony_laptop: Sony Programmable IO Control Driver v0.6 [7.729258] sony_laptop: detected Type2 model [7.731566] input: Sony Vaio Keys as /devices/LNXSYSTM:00/device:00/PNP0A03:00/device:0d/SNY6001:00/input/input5 [7.731644] input: Sony Vaio Jogdial as /devices/LNXSYSTM:00/device:00/PNP0A03:00/device:0d/SNY6001:00/input/input6 [7.740260] sony_laptop: Sony Notebook Control Driver v0.6 [7.845078] Console: switching to colour frame buffer device 128x48 [7.853681] i915 :00:02.0: fb0: inteldrmfb frame buffer device [7.853685] i915 :00:02.0: registered panic notifier [7.860017] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [7.860171] ACPI Warning: SystemIO range 0x1880-0x189f conflicts with OpRegion 0x1880-0x188f (\_SB_.PCI0.SBUS.SBUS) (20131218/utaddress-258) [7.860180] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [8.312610] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x4ff: [8.313899] excluding 0x170-0x177 0x1f0-0x1f7 0x370-0x377 0x3c0-0x3df 0x3f0-0x3f7 0x4d0-0x4d7 [8.314935] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x800-0x8ff: [8.315554] clean. [8.315572] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcff: [8.316714] excluding 0xcf8-0xcff [8.316744] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f: [8.316749] excluding 0xc-0xc7fff 0xd8000-0xf [8.316778] pcmcia_socket pcmcia_socket0: cs: memory probe 0xa000-0xa0ff: [8.316793] clean. [8.316811] pcmcia_socket pcmcia_socket0: cs: memory probe 0x6000
Bug#743739: clearlooks-phenix-theme: Include gtk2-engines as dependency
Package: clearlooks-phenix-theme Version: 3.0.16-3 Severity: normal Xfce is still based on GTK2 and if gtk2-engines in not installed, clearlooks-phenix looks bad. Upstream says that gtk2-engine is required if GTK2 applications are used, so i think it should be made a dependency or recommendation for this package. Bye. Cesare. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13-1-486 Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages clearlooks-phenix-theme depends on: ii libgtk-3-0 3.12.0-4 clearlooks-phenix-theme recommends no packages. clearlooks-phenix-theme 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#736712: apt-listchanges: dpkg-architecture: warning: couldn't type, falling back to default (native compilation)
Package: apt-listchanges Version: 2.85.13 Followup-For: Bug #736712 I see this problem too, on two machine on which gcc is not installed, because i don't need it. The "couldn't determine gcc system type" message is displayed for every package you are about to install. For example: 12 packages, 12 warning messages. If you launch dpkg-architecture alone, you'll get the same message on the first line of the output: --- # dpkg-architecture sh: gcc: command not found dpkg-architecture: warning: couldn't determine gcc system type, falling back to default (native compilation) DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_BITS=32 DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_ARCH_ENDIAN=little DEB_BUILD_ARCH_OS=linux DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_BUILD_MULTIARCH=i386-linux-gnu DEB_HOST_ARCH=i386 DEB_HOST_ARCH_BITS=32 DEB_HOST_ARCH_CPU=i386 DEB_HOST_ARCH_ENDIAN=little DEB_HOST_ARCH_OS=linux DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=linux-gnu DEB_HOST_GNU_TYPE=i486-linux-gnu DEB_HOST_MULTIARCH=i386-linux-gnu --- So looks like this bug should be redirected to dpkg-dev. Cesare. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13-trunk-486 Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages apt-listchanges depends on: ii apt0.9.15.3 ii debconf [debconf-2.0] 1.5.52 ii debianutils4.4 ii dpkg-dev 1.17.6 ii python 2.7.5-5 ii python-apt 0.9.2 ii python-support 1.0.15 ii ucf3.0027+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser]32.0.1700.123-1 ii gnome-terminal [x-terminal-emulator] 3.10.1-1 ii iceweasel [www-browser] 24.3.0esr-1 ii lynx-cur [www-browser]2.8.8pre5-1 ii midori [www-browser] 0.4.3+dfsg-0.1 ii postfix [mail-transport-agent]2.11.0-1 ii python-glade2 2.24.0-3+b1 ii python-gtk2 2.24.0-3+b1 ii w3m [www-browser] 0.5.3-15 ii xfce4-terminal [x-terminal-emulator] 0.6.3-1 ii xterm [x-terminal-emulator] 301-1 -- debconf information: * apt-listchanges/frontend: pager apt-listchanges/confirm: false apt-listchanges/which: news apt-listchanges/email-address: root apt-listchanges/save-seen: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724578: bmon: No qdisc inspection
Package: bmon Version: 1:2.1.1~pre1-1 Severity: wishlist This package doesn't support the netlink module and, as a consequence, bmon cannot show details about qdiscs and classes. It's a big pity, because bmon seems to be the only small program i've found to show useful and human readable qdisc/class statistics. The changelog shows that you have reverted the upload of a 3.0 branch and also the support for libnl, requested by the netlink module. But now 3.1 is out, and seems to be supported by Red Hat: any chance to upgrade with netlink module enabled? Cesare. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.11-trunk-486 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages bmon depends on: ii libasound2 1.0.27.2-1 ii libc62.17-92+b1 ii libdbi1 0.8.4-6 ii libncurses5 5.9+20130608-1 ii librrd4 1.4.7-2+b1 ii libtinfo55.9+20130608-1 bmon recommends no packages. bmon 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#723675: Test on another PC
I've tested 3.11-1~exp1 on a completely different PC, intel based and it boots just fine. Apart for the different CPU vendor, they differ also for the architecture: AMD: i686 Intel: x86_64 No more ideas or things to try. Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723675: CPU details
My initial report doesn't show clearly what CPU i have. Maybe it can be useful to diagnose the problem. # lscpu Architecture: i686 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):1 On-line CPU(s) list: 0 Thread(s) per core:1 Core(s) per socket:1 Socket(s): 1 Vendor ID: AuthenticAMD CPU family:20 Model: 1 Stepping: 0 CPU MHz: 800.000 BogoMIPS: 3199.83 Virtualization:AMD-V L1d cache: 32K L1i cache: 32K L2 cache: 512K # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 20 model : 1 model name : AMD E-350 Processor stepping: 0 microcode : 0x529 cpu MHz : 800.000 cache size : 512 KB fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc nonstop_tsc extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt arat hw_pstate npt lbrv svm_lock nrip_save pausefilter bogomips: 3199.83 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723675: linux-image-3.11-trunk-amd64: kernel panic in early boot
Package: src:linux Version: 3.11-1~exp1 Severity: normal Attached the image that shows what i see booting with: linux-image-3.11-trunk-amd64 (3.11-1~exp1) The panic happens just after "Booting the kernel." and some of its information scrolled off the screen. The boot is ok with: - linux-image-3.11-rc7-amd64 (3.11~rc7-1~exp1) - linux-image-3.11-trunk-486 (3.11-1~exp1) I'm writing this report with rc7. Cesare. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: To Be Filled By O.E.M. product_name: To Be Filled By O.E.M. product_version: To Be Filled By O.E.M. chassis_vendor: To Be Filled By O.E.M. chassis_version: To Be Filled By O.E.M. bios_vendor: American Megatrends Inc. bios_version: P1.60 board_vendor: ASRock board_name: E350M1 board_version: ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root Complex [1022:1510] Subsystem: ASRock Incorporation Device [1849:1510] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- [disabled] Capabilities: Kernel driver in use: radeon 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler HDMI Audio [1002:1314] Subsystem: ASRock Incorporation Device [1849:1314] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel 00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root Port [1022:1512] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40) (prog-if 01 [AHCI 1.0]) Subsystem: ASRock Incorporation Device [1849:4391] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ahci 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Device [1849:4397] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Kernel driver in use: ehci-pci 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Device [1849:4397] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Kernel driver in use: ehci-pci 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller [1002:4385] (rev 42) Subsystem: ASRock Incorporation Device [1849:4385] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: snd_hda_intel 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] (rev 40) Subsystem: ASRock Incorporation Device [1849:439d] Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- 00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399] (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Device [1849:4399] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:15.1 PCI
Bug#670046: xfce4-sensors-plugin: hddtemp error launching xfce4sensors
Package: xfce4-sensors-plugin Version: 1.2.5-2 Followup-For: Bug #670046 Bug still present in this version (Xfce 4.10). At each login (and every time you double click on the applet) an alert is showed for each disk you have on your system: if you have, say, two disks, you get two popup alert message. If it's not easy solvable maybe hddtemp should be changed from recommends to depends. Cesare. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.8-2-486 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xfce4-sensors-plugin depends on: ii libatk1.0-0 2.8.0-2 ii libc62.17-3 ii libcairo21.12.14-4 ii libfontconfig1 2.9.0-7.1 ii libfreetype6 2.4.9-1.1 ii libgdk-pixbuf2.0-0 2.28.1-1 ii libglib2.0-0 2.36.1-2build1 ii libgtk2.0-0 2.24.18-1 ii libnotify4 0.7.5-2 ii libpango-1.0-0 1.32.5-5 ii libpangocairo-1.0-0 1.32.5-5 ii libpangoft2-1.0-01.32.5-5 ii libsensors4 1:3.3.3-1 ii libxfce4ui-1-0 4.10.0-2 ii libxfce4util64.10.1-1 ii xfce4-panel 4.10.1-1 Versions of packages xfce4-sensors-plugin recommends: pn hddtemp ii lm-sensors 1:3.3.3-1 Versions of packages xfce4-sensors-plugin suggests: ii xsensors 0.70-3 -- 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#685108: linux-image-3.2.0-3-amd64: Error message on each boot: [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed
Package: src:linux Followup-For: Bug #685108 Ehm, the attachment... Cesare. -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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/dash dmesg.gz Description: GNU Zip compressed data
Bug#685108: linux-image-3.2.0-3-amd64: Error message on each boot: [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed
Package: src:linux Followup-For: Bug #685108 I see the same message on every boot but the system looks functional. I have a Sandy Bridge too (G640T) with an Intel board (DH1CR). Dmesg attached. Cesare. -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699656: general: System freezes while using multimedia via DRI [Intel 82865G chip] on kernels above 3.2.0-3-686-pae
On 11/02/2013 03:33, Ben Hutchings wrote: I realise it's critical to you, but if it doesn't affect other users then I'm afraid it's just not that high a priority. Most i865 systems have been thrown out by now, and to be brutally honest I personally a more concerned about supporting today's hardware properly. From what i know Intel is still caring about those old hardware and, in particular Chris Wilson, in the last year has made a lot of work around gen2 hardware: today a lot of GPU hangs are now resolved, SNA works and with xf86-video-intel 2.21.0 the even older i830/i845 are now considered stable: http://www.spinics.net/lists/xorg/msg55085.html Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687927: firmware-realtek: Missing rtl8411-1.fw and rtl8402-1.fw
Package: firmware-realtek Version: 0.36 Severity: normal I have an Intel D525MW motherboard (Atom) with a Realtek integrated network card. It doesn't work with the current kernel from testing: linux-image-3.2.0-3-amd64 (3.2.23-1) It doesn't print anything special in the syslog: # dmesg | grep r8169 [1.495121] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [1.495181] r8169 :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [1.495243] r8169 :01:00.0: setting latency timer to 64 [1.495354] r8169 :01:00.0: irq 44 for MSI/MSI-X [1.496836] r8169 :01:00.0: eth0: RTL8168e/8111e at 0xc933, e0:69:95:69:91:6c, XID 0c20 IRQ 44 [1.496849] r8169 :01:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] But doing "ifup eth0" does nothing: no network, no errors. Today i've installed the Debian kernel reported here, from experimental and i think it reports the culprit of the problem: - a curses window report that a required firmware is missing: r8169: rtl_nic/rtl_nic_rtl8411-1.fw, rtl_nic/rtl_nic_rtl8402-1.fw - a message before update-grup repeat the concept saying: update-initramfs: Generating /boot/initrd.img-3.5-trunk-amd64 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for module r8169 run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.5-trunk-amd64 /boot/vmlinuz-3.5-trunk-amd64 Ben, i see that in july you made a commit in the upstream rtl_nic/rtl8402-1.fw. Maybe you know why these firmware are not included in this non-free package. Are there known problem with these? Are they not yet included in the mainline kernel? Cesare. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.5-trunk-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 firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools0.107 ii linux-image-3.2.0-3-486 [linux-image] 3.2.23-1 ii linux-image-3.2.0-3-amd64 [linux-image]3.2.23-1 ii linux-image-3.5-trunk-amd64 [linux-image] 3.5.2-1~experimental.1 -- 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#656813: cfg80211: failed to add phy80211 symlink to netdev!
Package: linux-2.6 Followup-For: Bug #656813 I admit that starting from the Stanislaw Gruszka's reply i was a bit lost in this bug report... With this followup i only wanted to say that with the kernel 3.5 the message "cfg80211: failed to add phy80211 symlink to netdev!" is gone. Now i see a "lpc_ich :00:1f.0: I/O space for GPIO uninitialized", but i think it's another unrelated issue, isn't it? Looking around seems to be related to some hardware not available on my old Centrino. Cesare. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.5-trunk-486 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#653669: Installation works now
On 02/06/2012 07:00, Bernhard wrote: One thing, i have observed during installation: The installation of the packages takes very long. If i use ext4 as filesystem, the installation takes a significant shorter time. Maybe the entry regarding dpkg from this blog article could explain this: http://raphaelhertzog.com/2012/06/01/my-debian-activities-in-may-2012/ Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670046: hddtemp error launching xfce4sensors
In the initial message i wrote: Since few days ago the popup error was single, for sda. Now it pops up also for /dev/sdb that it is neither present on my system: Ok, i think this behaviour is explainable (even if not that clear to me) and reproducible: i often use this laptop to recharge my smartphone. Even if it's not seen as mass storage (Android 2.3: i have to activate this on the device), whenever i attach it to the laptop usb's port, xfce4-sensors show also a /dev/sdb popup error, even if it's not mentioned in /proc/partitions. When i detach it, xfce4-sensors returns to show only the /dev/sda error. Tell me if i should file a new bug for this or can be ignored. Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652941: Seems resolved
I've just upgraded to Iceweasel 10.0.3esr-1 and the problem looks resolved. Recently i've workarounded the problem setting webgl.disabled=true, as someone suggested on upstream bugzilla. Now i've just verified that the crashes reported in this bug doesn't happen anymore with the default webgl.disable setting (false). Looking in the changelog, i guess this is what has brought the solution: - Avoid crashing when there are no GL extensions reported by the GL implementation. bz#728656. Closes: #656611 Thank you. Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652941: This bug will not be resolved
On 09/01/2012 08:51, Mike Hommey wrote: Oh it's not a bug you filed. File a new one, that'll be better. Please mention as much information as you can. Kernel version, X.org driver version, Mesa version, crash backtrace, or even better crash id from the upstream crash reporter (try reproducing the bug with an upstream tarball and try to make it send crash info, then go in about:crashes to have a link to your crashes) Hi Mike. First of all thank you for your assistance and sorry for the late reply. Rather than opening a new bug, i've added details here: https://bugzilla.mozilla.org/show_bug.cgi?id=696636 It is one of the bug i've already reported on msg #15 and it exactly describe what i've reported here. I'm sorry to haven't accomplished your latest suggestion of using Firefox from upstream tarball but i really haven't the time to do this in this period. I've reported your suggestion in that bug report, hoping someone else will be able to do it. However i think that the soon to be released Mesa 8 could be the key to see some advancement in these kind of problems. We will see... Cesare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
