Bug#1031046: asterisk gone from bookworm ?
Hi all, Is there any news from the asterisk maintainers regarding this? what are the chances that asterisk 20 will be included in bookworm ? Thanks, Bogdan Veringioiu
Bug#1000481: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip
Hi this issue affecting the LVDS connector was reported here: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 and fixed. Any chance it will be backported in 5.10? Thanks On 10.06.22 15:01, Bogdan Veringioiu wrote: Hi Diederik, thanks for answering. I am attaching dmesg, Xorg, xrandr output as well as a listing of /sys/class/drm directory of: - a buster install running kernel 4.19.98 which is working fine - a bullseye install running kernel 5.10.106 which is not working As mentioned intel_iommu parameter does not help me. After more tests, I understood what is happening under bullseye with 5.10 kernel. The built-in monitor of the POS PC is connected via LVDS. This LVDS connection is not detected/listed at all by the i915 driver upon initialization on boot and the screen goes blank. See the Xorg + xrand outputs. Under buster + kernel 4.19 it works perfectly. Additionaly (bullseye): If I hook an external VGA monitor using the VGA connector in the back of the POS PC, that monitor is detected and it is working fine, Xorg is using it as the main display. The built-in LVDS monitor remains blank, the LVDS connection is not listed. Regards Bogdan On 10.06.22 12:35, Diederik de Haas wrote: Control: found -1 linux/5.10.106-1 Control: found -1 linux/5.16.12-1~bpo11+1 On Friday, 10 June 2022 07:57:12 CEST Bogdan Veringioiu wrote: the bug is still exists in kernel version 5.10.106 (32 bit). Also tried a newer kernel linux-image-5.16.0-0.bpo.4 from bullseye-backports, with the same result. Thanks for that. Metadata updated accordingly. Symptoms: The monitor gets blank when the i915 changes resolution on boot. The PC remains accessible (ssh). That seems different from what Ben reported, which may be useful info. @Ben: can you tell whether you can ssh into your device or not? The intel_iommu=off does not work. Some details about the system below: $ dmesg | grep 915 [ 8.816308] i915 :00:02.0: vgaarb: deactivate vga console [ 8.846333] i915 :00:02.0: [drm] Failed to find VBIOS tables (VBT) When putting "i915 [drm] Failed to find VBIOS tables (VBT)" into a search engine, most results were about GPU passthrough (VMs). I don't see a (direct) connection with this bug, but thought I'd share this observation in case it might give a clue to others. [ 8.846882] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 9.116269] i915 :00:02.0: [drm] Initialized overlay support. [ 9.118527] [drm] Initialized i915 1.6.0 20200917 for :00:02.0 on minor 0 [ 9.163178] fbcon: i915drmfb (fb0) is primary device [ 9.203620] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device Request to both Bogdan and Ben: Can you share the full dmesg output of the 'failing' system and in case of a working workaround (like "intel_iommu=off"), also the dmesg output of that? The full dmesg output may contain clues as to why this issue occurs.
Bug#998088: hitting this issue on a dell t150 server on bullseye
Hi, I have encountered the same issue described in this bug. Aug 16 06:13:14 v802limat1 systemd-udevd[296]: sdb1: Spawned process 'checkScript.sh' [350] is taking longer than 59s to complete Aug 16 06:13:14 v802limat1 systemd-udevd[279]: sdb1: Worker [296] processing SEQNUM=2164 is taking a long time Aug 16 06:14:12 v802limat1 systemd[1]: ifupdown-pre.service: Main process exited, code=exited, status=1/FAILURE Aug 16 06:14:12 v802limat1 systemd[1]: ifupdown-pre.service: Failed with result 'exit-code'. Aug 16 06:14:12 v802limat1 systemd[1]: Failed to start Helper to synchronize boot up for ifupdown. Aug 16 06:14:12 v802limat1 systemd[1]: Dependency failed for Raise network interfaces. Aug 16 06:14:12 v802limat1 systemd[1]: networking.service: Job networking.service/start failed with result 'dependency'. Aug 16 06:14:12 v802limat1 systemd[1]: ifupdown-pre.service: Consumed 4.534s CPU time. It seems to happen when udev is waiting on a custom script (triggered by custom udev rule when USB stick insert is detected). This did not happen under buster. -- Bogdan Veringioiu Amano Parking Europe N.V. Uersfeld 24 52072 Aachen, Germany e-mail: bogdan.veringi...@amano.eu web: www.amano.eu
Bug#1000481: encountered this bug on a POS system (Toshiba Surepos 500) running the same graphic chip
Hello, the bug is still exists in kernel version 5.10.106 (32 bit). Also tried a newer kernel linux-image-5.16.0-0.bpo.4 from bullseye-backports, with the same result. Symptoms: The monitor gets blank when the i915 changes resolution on boot. The PC remains accessible (ssh). xrandr shows no monitor connected. Somehow the i915 driver is not detecting the built-in monitor when resolution is changing on boot. $ xrandr Screen 0: minimum 8 x 8, current 1024 x 768, maximum 32767 x 32767 VGA1 disconnected primary (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Connecting an external VGA monitor works without issues. The intel_iommu=off does not work. Some details about the system below: lspci .. 00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02) $ dmesg | grep 915 [ 8.816308] i915 :00:02.0: vgaarb: deactivate vga console [ 8.846333] i915 :00:02.0: [drm] Failed to find VBIOS tables (VBT) [ 8.846882] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 9.116269] i915 :00:02.0: [drm] Initialized overlay support. [ 9.118527] [drm] Initialized i915 1.6.0 20200917 for :00:02.0 on minor 0 [ 9.163178] fbcon: i915drmfb (fb0) is primary device [ 9.203620] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device Thank you Bogdan
Bug#947844: also affected by libservlet3.1-java: 8.5.50-0+deb9u1 breaks upgrades to Buster
Hello I am also affected by this bug. Is there any fix on the way? Thank you very much -- Bogdan Veringioiu
Bug#934023: resiprocate missing in buster
Thanks for the info! We actually managed to build the package on buster. Not yet tested though... About maintaining it, we will check. Bogdan On 27.08.19 07:57, Petter Reinholdtsen wrote: [Bogdan Veringioiu] resiprocate source is not being built in buster anymore. We are using it in a sip client app. Is there any chance that resiprocate will be reinserted in buster? As far as I can tell from https://tracker.debian.org/pkg/resiprocate >, it was removed from unstable (and thus buster) because it was unmaintained. If it is important to you, perhaps you can reintroduce it and maintain it?
Bug#934023: resiprocate missing in buster
Hi, is there any update on libresiprocate being built on buster? Thanks
Bug#934023: resiprocate missing in buster
Package: libresiprocate-1.11 Version: NA resiprocate source is not being built in buster anymore. We are using it in a sip client app. Is there any chance that resiprocate will be reinserted in buster? Thanks -- Bogdan Veringioiu Amano Parking Europe N.V. Uersfeld 24 52072 Aachen, Germany e-mail: bogdan.veringi...@amano.eu web: www.amano.eu
Bug#898935: Tomcat 8 security issues in Stretch
Thank you! Bogdan On 25.08.2018 00:05, Markus Koschany wrote: A security update has been sent to Debian's security team and we expect that the current open issues in Stretch will be fixed in due time. Please note that Tomcat 7 in Stretch is not vulnerable to any of those issues because we only build the servlet API. Regards, Markus
Bug#898935: migrate fix to stretch security
Hello all, is there any plan to migrate the fix to stretch security ? I would be interested in the fixes for CVE-2018-1304, CVE-2018-1305 (resolved in 7.0.88, and in 8.5.32-1 testing) which are important for a security certification (PCI) on our stretch machines. Thank you, -- Bogdan Veringioiu Amano Parking Europe N.V. Uersfeld 24 52072 Aachen, Germany e-mail: bogdan.veringi...@amano.eu web: www.amano.eu
