Bug#1031228: nvidia-driver: Broken depencies
Package: nvidia-driver Version: 525.85.12 Severity: grave Justification: renders package unusable Dear Maintainer, I'm trying to install the package nvidia-driver on sid. It fails with the following message: The following packages have unmet dependencies: nvidia-driver : Depends: nvidia-kernel-dkms (= 525.85.12-1) but it is not installable or nvidia-kernel-525.85.12 or nvidia-open-kernel-525.85.12 but it is not installable or nvidia-open-kernel-525.85.12 but it is not installable E: Unable to correct problems, you have held broken packages. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nvidia-driver depends on: pn nvidia-alternative pn nvidia-driver-bin pn nvidia-driver-libs ii nvidia-installer-cleanup 20220217+2 pn nvidia-kernel-dkms | nvidia-kernel-525.85.12 | nvidia-open-kern el-525.85.12 | nvidia-open-kernel-525.85.12 pn nvidia-legacy-check pn nvidia-support pn nvidia-vdpau-driver pn xserver-xorg-video-nvidia Versions of packages nvidia-driver recommends: pn libnvidia-cfg1 pn nvidia-persistenced pn nvidia-settings Versions of packages nvidia-driver suggests: pn nvidia-kernel-dkms | nvidia-kernel-source | nvidia-open-kernel-sour ce | nvidia-open-kernel-source TIA, Michael
Bug#1027971: virtualbox : Depends: python3 (< 3.11) but 3.11.1-1 is installed
Package: virtualbox Version: 7.0.4-dfsg-5 Severity: grave Justification: renders package unusable Dear Maintainer, trying to install virtualbox on sid, but its dependencies are wrong. python3 (<< 3.11), python3 (>= 3.10~), python3.10 Please upgrade to 3.11.1-1. TIA, Michael -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virtualbox depends on: ii python3 3.11.1-1 ii python3.103.10.9-1
Bug#1008605: virtualbox depends on old python package
Package: virtualbox Version: 6.1.32-dfsg-1+b2 Severity: normal Dear Maintainer, the virtualbox package doesn't install on sid anymore. Depends: python3 (< 3.10) but 3.10.4-1 is to be installed. If it really doesn't work with 3.10.4-1 maybe it should depend on python3.9. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) ii python3 3.10.4-1 ii python3.9 3.9.12-1
Bug#1005311: xserver-xorg-video-nvidia: Package has unmet dependencies
Package: xserver-xorg-video-nvidia Version: 470.103.01-1 Followup-For: Bug #1005311 Dear Maintainer, since updating today the nvidia driver package doesn't work anymore. It depends on xserver-xorg-video-nvidia which has unmet dependencies itself. Depends: xserver-xorg-core (< 2:1.20.99) but 2:21.1.3-2 is to be installed -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xserver-xorg-video-nvidia depends on: ii libc6 2.33-5 ii libnvidia-glcore 470.103.01-1 ii nvidia-alternative 470.103.01-1 ii nvidia-installer-cleanup 20151021+13 ii nvidia-legacy-check470.103.01-1 ii nvidia-support 20151021+13 pn xorg-video-abi-24 | xorg-video-abi-23 | xorg-video-abi-20 | x ii xserver-xorg-core 2:21.1.3-2 Versions of packages xserver-xorg-video-nvidia recommends: pn nvidia-driver ii nvidia-kernel-dkms [nvidia-kernel-470.103.01] 470.103.01-1 pn nvidia-settings pn nvidia-vdpau-driver Versions of packages xserver-xorg-video-nvidia suggests: ii nvidia-kernel-dkms 470.103.01-1
Bug#1004679: [Pkg-deepin-devel] Bug#1004679: papirus-icon-theme 20220101-2 fails to install and hangs indefinitly
Hi, I waited - and it really went though. It took real21m24.758s for the whole upgrade including building a new initrd.img. so close this one please and sorry for the noise. I have to say though that a hint that it might take a **long** time would really be helpful. :) * On Mon, Jan 31, 2022 11:41AM -0500 Boyuan Yang (by...@debian.org) wrote: > I could not reproduce this issue. Depending on your computer's performance, > installation may take up to **one hour** due to icon cache refreshing. Please > try again and wait patiently. Please let me know if it does take more than one > hour, and also let me know your PC's model. > 在 2022-01-31星期一的 17:09 +0100，Michael Tatge写道： > > Package: papirus-icon-theme > > Version: 20220101-1 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > > > * What led up to the situation? > > Trying to upgrade from 20220101-1 to 20220101-2 > > > > * What exactly did you do (or not do) that was effective (or > > ineffective)? > > apt full-upgrade > > > > * What was the outcome of this action? > > upgrade process hangs indefinitly an package > > > > * What outcome did you expect instead? > > clean install > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers unstable > > APT policy: (990, 'unstable') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads) > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > > TAINT_UNSIGNED_MODULE > > Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en > > Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled Michael -- PGP-Key-ID: DE3C3D3BEEE7D043 Jabber: in...@jabber.de signature.asc Description: PGP signature
Bug#1004679: papirus-icon-theme 20220101-2 fails to install and hangs indefinitly
Package: papirus-icon-theme Version: 20220101-1 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Trying to upgrade from 20220101-1 to 20220101-2 * What exactly did you do (or not do) that was effective (or ineffective)? apt full-upgrade * What was the outcome of this action? upgrade process hangs indefinitly an package * What outcome did you expect instead? clean install -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages papirus-icon-theme depends on: ii hicolor-icon-theme 0.17-2 papirus-icon-theme recommends no packages. papirus-icon-theme suggests no packages. -- no debconf information
Bug#863727: nut-snmp: UPS Network Management Card 2 (AP9630) snmpv3 not fully supported
Package: nut-snmp Version: 2.7.4-5 Severity: wishlist Dear Maintainer, we have an APC Smart-UPS 1000 with a UPS Network Management Card 2 (AP9630) Trying to configure the snmp-ups driver with secLevel = authPriv failed for unknown reasons. See mail snipplet Model: Smart-UPS 1000 Firmware Revision: 600.3.I Manufacture Date: 05/06/05 Factory Information Hardware Factory Model Number: AP9630 Hardware Revision: 05 Manufacture Date: 01/09/2009 Application Module Name: sumx Version: v6.4.6 APC OS (AOS) Name: aos Version: v6.4.6 APC Boot Monitor Name: bootmon Version: v1.0.8 Email snipplet received from the management card [snip] Name : apc1000 Code : 0x0067 Informational - Detected an unauthorized user attempting to access the SNMPv3 interface from XXX.XXX.XXX.XXX [snip] [ups.conf] driver = snmp-ups port = [IP] snmp_version = v3 mibs = auto secLevel = authPriv secName = [username] authProtocol = SHA authPassword = [passphrase] privProtocol = AES privPassword = [passphrase] Then I tested secLevel = noAuthNoPriv which somehow worked. The driver reports "No matching MIB found for sysOID '.1.3.6.1.4.1.318.1.3.2.7'!" though. *** driver.snmp.log upsdrvctl -D start 0.00 Starting UPS: apc1000 No matching MIB found for sysOID '.1.3.6.1.4.1.318.1.3.2.7'! Please report it to NUT developers, with an 'upsc' output for your device. Going back to the classic MIB detection method. Detected Smart-UPS 1000 on host XXX.XXX.XXX.XXX (mib: apcc 1.2) [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.3.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.3.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.3.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.4.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.4.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.4.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.5.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.5.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.5.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.6.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.6.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.6.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.7.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.7.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.7.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.8.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.8.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.3.1.8.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.2.2.1.4.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.2.2.7.0 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.2.3.5.0 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.2.2.9.0 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.2.3.6.0 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.2.2.6.0 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.2.1.4.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.4.3.4.0 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.4.2.4.0 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.3.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.3.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.3.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.4.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.4.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.4.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.5.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.5.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.5.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.6.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.6.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.6.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.7.1.1.1 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.7.1.1.2 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.7.1.1.3 [apc1000] unhandled ASN 0x81 received from .1.3.6.1.4.1.318.1.1.1.9.3.3.1.8.1.1.1 [apc1000] unhandled ASN
Bug#836694: i3-wm: bindsym --whole-window not working anymore
Package: i3-wm Version: 4.12-2 Severity: normal Dear Maintainer, bindsym --whole-window used to work fine until a few versions ago. I have this line in my config: bindsym --whole-window button8 exec --no-startup-id i3-msg exec ~/bin/openurl; workspace number "2: web" where ~/bin/openurl is a script opening the current selection in my browser. The purpose of --whole-window is that you don't have to move the mouse on the border of the window to make it work, and that's the part not working anymore. i3 behaves like it's ignoring --whole-window completely. If I press button8 on the title bar, it's fine but not anywhere in the window. bindsym $mod+g exec --no-startup-id i3-msg exec ~/bin/openurl; workspace number "2: web" on the other hand works as expected. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages i3-wm depends on: ii libc6 2.24-2 ii libcairo2 1.14.6-1+b1 ii libev41:4.22-1 ii libglib2.0-0 2.49.6-1 ii libpango-1.0-01.40.2-1 ii libpangocairo-1.0-0 1.40.2-1 ii libpcre3 2:8.39-2 ii libstartup-notification0 0.12-4 ii libxcb-cursor00.1.1-3 ii libxcb-icccm4 0.4.1-1 ii libxcb-keysyms1 0.4.0-1 ii libxcb-randr0 1.11.1-1.1 ii libxcb-render01.11.1-1.1 ii libxcb-util0 0.3.8-3 ii libxcb-xinerama0 1.11.1-1.1 ii libxcb-xkb1 1.11.1-1.1 ii libxcb1 1.11.1-1.1 ii libxkbcommon-x11-00.6.1-1 ii libxkbcommon0 0.6.1-1 ii libyajl2 2.1.0-2 ii perl 5.22.2-5 ii x11-utils 7.7+3 Versions of packages i3-wm recommends: ii aterm [x-terminal-emulator] 1.0.1-9 ii fonts-dejavu-core 2.37-1 ii gnome-terminal [x-terminal-emulator] 3.21.90-2 ii konsole [x-terminal-emulator] 4:16.04.2-1 ii libanyevent-i3-perl 0.16-1 ii libjson-xs-perl 3.010-2+b1 ii lxterminal [x-terminal-emulator] 0.2.0-1 ii rxvt-unicode [x-terminal-emulator]9.22-1 ii terminal.app [x-terminal-emulator]0.9.8-1+nmu1+b2 ii xfonts-base 1:1.0.4+nmu1 ii xterm [x-terminal-emulator] 325-1 i3-wm suggests no packages. -- no debconf information
Bug#799675: [virtualbox] missing packages in sid
Source: virtualbox Version: 5.0.4-dfsg-3 Followup-For: Bug #799675 Problem still persists. Push^^ ..deb packages from virtualbox.org won't install, too, because they depend on libvpx1 (>= 1.0.0) which has no installation candidate. I'd be very happy about a fix :) Micha
Bug#792002: lvm2-monitor service causes long delay at boot (encrypted root/swap)
* On Fri, Aug 07, 2015 12:08PM +0200 I wrote: Package: lvm2 Version: 2.02.126-2 Followup-For: Bug #792002 I found that changing ExecStart=/sbin/lvm vgchange --monitor y --ignoreskippedcluster to ExecStart=/sbin/lvm vgchange --activate y --monitor y --ignoreskippedcluster The problem seems to have resolved with the latest unstable version (2.02.126-3). Thanks, Michael -- PGP-Key-ID: EEE7D043 Jabber: in...@jabber.de
Bug#792002: lvm2-monitor service causes long delay at boot (encrypted root/swap)
Package: lvm2 Version: 2.02.126-2 Followup-For: Bug #792002 Dear Maintainer, I'm running into a slightly different problem. I too have root/swap encrypted and they are mounted at boot time. My other encrypted volumes though are not (and they cause the timeout delay at boot time). Those volumes are luks encrypted on a lvm volume group. # lsblk /dev/sdb6 NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb6 8:22 0 1.3T 0 part ├─knecht40-var 254:1028G 0 lvm │ └─var_crypt 254:5028G 0 crypt /var ├─knecht40-home 254:20 372.5G 0 lvm │ └─home_crypt 254:60 372.5G 0 crypt /home └─knecht40-tmp 254:3028G 0 lvm └─tmp_crypt 254:4028G 0 crypt /tmp The system boots into maintenace mode but the logical volumes are INACTIVE. After manually running vgchange --activate y the lvs are activated and the luks containers are opened and automounted as intended. Here's the complete setup lsblk /dev/sda1 /dev/sda2 /dev/sdb5 /dev/sdb6 NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda1 8:10 142M 0 part /boot sda2 8:20 23.3G 0 part └─sda2_crypt254:00 23.3G 0 crypt / sdb5 8:21 0 14.9G 0 part └─sdb5_crypt254:70 14.9G 0 crypt [SWAP] sdb6 8:22 0 1.3T 0 part ├─knecht40-var 254:1028G 0 lvm │ └─var_crypt 254:5028G 0 crypt /var ├─knecht40-home 254:20 372.5G 0 lvm │ └─home_crypt 254:60 372.5G 0 crypt /home └─knecht40-tmp 254:3028G 0 lvm └─tmp_crypt 254:4028G 0 crypt /tmp /etc/crypttab: home_crypt UUID=3c5d677c-c709-47b8-9ad5-f97ee082e6fc /etc/keys/home.key luks tmp_crypt UUID=8e2be6a6-8f7d-4c6c-acbc-3f5b6739de35 /etc/keys/tmp.key luks var_crypt UUID=f194e984-56bd-4b9e-806b-3de2fbcad477 /etc/keys/var.key luks sdb5_crypt /dev/sdb5 /dev/urandom cipher=aes-xts-plain64,size=256,swap /etc/fstab: /dev/mapper/home_crypt /home ext4defaults0 2 /dev/mapper/tmp_crypt /tmp ext4defaults0 2 /dev/mapper/var_crypt /var ext4defaults0 2 /dev/mapper/sdb5_crypt none swapsw 0 0 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lvm2 depends on: ii dmeventd 2:1.02.103-2 ii dmsetup 2:1.02.103-2 ii init-system-helpers 1.23 ii initscripts 2.88dsf-59.2 ii libc6 2.19-19 ii libdevmapper-event1.02.1 2:1.02.103-2 ii libdevmapper1.02.12:1.02.103-2 ii liblvm2app2.2 2.02.126-2 ii libreadline5 5.2+dfsg-3 ii libudev1 224-1 ii lsb-base 4.1+Debian13+nmu1 lvm2 recommends no packages. Versions of packages lvm2 suggests: pn thin-provisioning-tools none -- no debconf information # systemctl status lvm2-lvmetad.socket ● lvm2-lvmetad.socket - LVM2 metadata daemon socket Loaded: loaded (/lib/systemd/system/lvm2-lvmetad.socket; enabled; vendor preset: enabled) Active: active (running) since Fri 2015-08-07 08:07:40 CEST; 3h 25min ago Docs: man:lvmetad(8) Listen: /run/lvm/lvmetad.socket (Stream) # systemctl status dm-event.service ● dm-event.service - Device-mapper event daemon Loaded: loaded (/lib/systemd/system/dm-event.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2015-08-07 08:07:40 CEST; 3h 28min ago Docs: man:dmeventd(8) Main PID: 322 (dmeventd) CGroup: /system.slice/dm-event.service └─322 /sbin/dmeventd -f # systemctl status -l lvm2-monitor.service ● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling Loaded: loaded (/lib/systemd/system/lvm2-monitor.service; enabled; vendor preset: enabled) Active: active (exited) since Fri 2015-08-07 08:07:41 CEST; 3h 27min ago Docs: man:dmeventd(8) man:lvcreate(8) man:lvchange(8) man:vgchange(8) Process: 330 ExecStart=/sbin/lvm vgchange --monitor y --ignoreskippedcluster (code=exited, status=0/SUCCESS) Main PID: 330 (code=exited, status=0/SUCCESS) CGroup: /system.slice/lvm2-monitor.service I found that changing ExecStart=/sbin/lvm vgchange --monitor y --ignoreskippedcluster to ExecStart=/sbin/lvm vgchange --activate y --monitor y --ignoreskippedcluster in /lib/systemd/system/lvm2-monitor.service solves the problem. And the system boots normally. Up to you to value that as a crude hack or not ;) HTH, Michael ---
Bug#784903: [Pkg-fglrx-devel] Bug#784903: fglrx-driver: broken depends on xorg-video-abi-18
* On Tue, May 12, 2015 07:51PM +0200 Patrick Matthäi (pmatth...@debian.org) wrote: Am 10.05.2015 um 14:18 schrieb Michael Tatge: Source: fglrx-driver Version: 1:14.9+ga14.201-2 Severity: grave Justification: renders package unusable fglrx-driver depends on xorg-video-abi-18 but xserver-xorg-core provides xorg-video-abi-19 thus rendering the package uninstallable. I will check in the next days if the experimental 14.12 version is compatible with it, but I do not think so. It seems it is not. Even amd say it's only compatible with Xorg up to 1.16. For the time being I downgraded to 1.16 since I cannot get the radeon driver to *not* use xinerama or mergedfb... Michael -- PGP-Key-ID: EEE7D043 Jabber: in...@jabber.de signature.asc Description: Digital signature
Bug#784903: fglrx-driver: broken depends on xorg-video-abi-18
Source: fglrx-driver Version: 1:14.9+ga14.201-2 Severity: grave Justification: renders package unusable Dear Maintainer, fglrx-driver depends on xorg-video-abi-18 but xserver-xorg-core provides xorg-video-abi-19 thus rendering the package uninstallable. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
