Bug#1033616: cups prepends job number to job-name so job names near 255 characters may be too long
Package: cups
Version: 2.3.3op2-3+deb11u2
Severity: normal
Dear Maintainer,
* What led up to the situation?
I printed a page from firefox with a very, very long URL. Firefox used the
first 255 bytes of the URL as the job name.
* What was the outcome of this action?
The job mysteriously didn't print. Lookin in the cups log (with debug on) I
found the lines:
D [28/Mar/2023:18:14:44 +0200] [Job 365] job-name nameWithoutLanguage 365 -
https://xxx//xx
D [28/Mar/2023:18:27:36 +0200] [Job 369] Validate-Job:
client-error-request-value-too-long (client-error-request-value-too-long)
notice how the job name passed to cups ("https://xxx...;) is shorter than 255
characters, but when the job number "365 - " is prepended it is longer tnan 255
characters and so overflows.
* What outcome did you expect instead?
That my print job be printed rather than just geting stuck in the print queue
forever.
How to reproduce:
lp -o
'job-name=https://xxx//xx'
-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cups depends on:
ii cups-client2.3.3op2-3+deb11u2
ii cups-common2.3.3op2-3+deb11u2
ii cups-core-drivers 2.3.3op2-3+deb11u2
ii cups-daemon2.3.3op2-3+deb11u2
ii cups-filters 1.28.7-1+deb11u1
ii cups-ppdc 2.3.3op2-3+deb11u2
ii cups-server-common 2.3.3op2-3+deb11u2
ii debconf [debconf-2.0] 1.5.77
ii ghostscript9.53.3~dfsg-7+deb11u2
ii libavahi-client3 0.8-5+deb11u1
ii libavahi-common3 0.8-5+deb11u1
ii libc6 2.31-13+deb11u5
ii libcups2 2.3.3op2-3+deb11u2
ii libgcc-s1 10.2.1-6
ii libstdc++6 10.2.1-6
ii libusb-1.0-0 2:1.0.24-3
ii poppler-utils 20.09.0-3.1+deb11u1
ii procps 2:3.3.17-5
Versions of packages cups recommends:
ii avahi-daemon 0.8-5+deb11u1
ii colord1.4.5-3
Versions of packages cups suggests:
ii cups-bsd 2.3.3op2-3+deb11u2
pn cups-pdf
ii foomatic-db-compressed-ppds [foomatic-db] 20200820-1
ii smbclient 2:4.13.13+dfsg-1~deb11u5
ii udev 247.3-7+deb11u1
-- debconf information:
cupsys/backend: lpd, socket, usb, snmp, dnssd
cupsys/raw-print: true
Bug#989906: openssh-server: With GSSAPIKeyExchage "yes" openssh presents poor quality key exchange methods
On 12/02/2023 18:51, Felix Hädicke wrote: As far as I can tell there is no way of configuring openssh to avoid using gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==. It is possible with option "GSSAPIKexAlgorithms", see man page for ssh_config / sshd_config. Unfortunately that option doesn't exist in the obsolete openssh-server 1:7.9p1-10+deb10u2 I'm using :( Time to get back on the upgrade treadmill. -- John Hughes, CalvaEDI -- an Esker company.
Bug#989906: openssh-server: With GSSAPIKeyExchage "yes" openssh presents poor quality key exchange methods
On 12/02/2023 18:51, Felix Hädicke wrote: As far as I can tell there is no way of configuring openssh to avoid using gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==. It is possible with option "GSSAPIKexAlgorithms", see man page for ssh_config / sshd_config. Well, I feel like a bit of an idiot for missing that, thanks for the tip. However, the default for GSSAPIKexAlgorithms should be adjusted. See patch: https://github.com/felixhaedicke/openssh/commit/11244c7dd5fb5a8d8ecf07016e0d7afff982f0a3.diff Seems reasonable to me. -- John Hughes, CalvaEDI -- an Esker company.
Bug#710490: Well, the zombie bug just bit me again
One of my workstations had a bad ethernet cable, so it was connecting to the switch at 100M instead of 1G. The extra negotiation time meant that automount was always being started before the network was ready. (Debian bullseye). -- *John HUGHES* Directeur technique *CalvaEDI* An Esker Company 58/A rue du Dessous des Berges, 75013 Paris Tel. : (+33) 1 4313 3131 Fax : (+33) 1 4313 3139
Bug#1014606: cssc: the sccsdiff command leaves empty get.xxxxx files hanging around
Package: cssc Version: 1.4.0-6jh2 Severity: normal Dear Maintainer, * What led up to the situation? did an "sccs sccsdiff command" * What was the outcome of this action? an empty get.x file was created in the current directory * What outcome did you expect instead? no useless empty files Problem is in the sccsdiff shell script, it contains the useless line: getprefix=$(mktemp get.XXX). which makes the temporary file. getprefix is mentioned nowhere else in the script. Removing this line gets rid of the problem. -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cssc depends on: ii libc6 2.28-10+deb10u1 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 cssc recommends no packages. Versions of packages cssc suggests: pn groff -- no debconf information
Bug#998642: Valgrind output with debug symbols available (+patch to fix problem)
I built cssc from source to get the debug symbols and valgrind shows:
valgrind cssc-1.4.1/src/get s._x-xx
==319086== Memcheck, a memory error detector
==319086== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==319086== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==319086== Command: cssc-1.4.1/src/get s._x-xx
==319086==
==319086== Invalid read of size 1
==319086==at 0x483BC82: strlen (vg_replace_strmem.c:459)
==319086==by 0x4AC5F34: fputs (iofputs.c:33)
==319086==by 0x111B59: sccs_file::write_subst(char const*,
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:113)
==319086==by 0x111CED: sccs_file::write_subst(char const*,
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:245)
==319086==by 0x110BFD: sccs_file::get(std::__cxx11::basic_string,
std::allocator > const&, seq_state&, sccs_file::subst_parms&, bool, int, int, int,
bool, bool) (sf-get.cc:416)
==319086==by 0x10FAAA: sccs_file::get(_IO_FILE*, std::__cxx11::basic_string, std::allocator > const&, _IO_FILE*, sid, sccs_date,
range_list, range_list, int, char const*, int, int, int, bool) (sf-get2.cc:519)
==319086==by 0x10C88B: main (get.cc:463)
==319086== Address 0x4d75c80 is 0 bytes inside a block of size 18 free'd
==319086==at 0x483A08B: operator delete(void*, unsigned long)
(vg_replace_malloc.c:593)
==319086==by 0x111B4B: deallocate (new_allocator.h:133)
==319086==by 0x111B4B: deallocate (alloc_traits.h:492)
==319086==by 0x111B4B: _M_destroy (basic_string.h:237)
==319086==by 0x111B4B: _M_dispose (basic_string.h:232)
==319086==by 0x111B4B: ~basic_string (basic_string.h:658)
==319086==by 0x111B4B: sccs_file::write_subst(char const*,
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:112)
==319086==by 0x111CED: sccs_file::write_subst(char const*,
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:245)
==319086==by 0x110BFD: sccs_file::get(std::__cxx11::basic_string,
std::allocator > const&, seq_state&, sccs_file::subst_parms&, bool, int, int, int,
bool, bool) (sf-get.cc:416)
==319086==by 0x10FAAA: sccs_file::get(_IO_FILE*, std::__cxx11::basic_string, std::allocator > const&, _IO_FILE*, sid, sccs_date,
range_list, range_list, int, char const*, int, int, int, bool) (sf-get2.cc:519)
==319086==by 0x10C88B: main (get.cc:463)
==319086== Block was alloc'd at
==319086==at 0x4838DEF: operator new(unsigned long)
(vg_replace_malloc.c:342)
==319086==by 0x11297C: void std::__cxx11::basic_string,
std::allocator >::_M_construct(char*, char*, std::forward_iterator_tag)
[clone .isra.0] (basic_string.tcc:219)
==319086==by 0x113301: _M_construct_aux (basic_string.h:247)
==319086==by 0x113301: _M_construct (basic_string.h:266)
==319086==by 0x113301: basic_string (basic_string.h:451)
==319086==by 0x113301: gfile (sccsname.h:87)
==319086==by 0x113301: sccs_file::get_module_name[abi:cxx11]() const
(sccsfile.cc:694)
==319086==by 0x111B2B: sccs_file::write_subst(char const*,
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:112)
==319086==by 0x111CED: sccs_file::write_subst(char const*,
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:245)
==319086==by 0x110BFD: sccs_file::get(std::__cxx11::basic_string,
std::allocator > const&, seq_state&, sccs_file::subst_parms&, bool, int, int, int,
bool, bool) (sf-get.cc:416)
==319086==by 0x10FAAA: sccs_file::get(_IO_FILE*, std::__cxx11::basic_string, std::allocator > const&, _IO_FILE*, sid, sccs_date,
range_list, range_list, int, char const*, int, int, int, bool) (sf-get2.cc:519)
==319086==by 0x10C88B: main (get.cc:463)
==319086==
So this patch fixes the problem:
--- src/writesubst.cc.orig 2019-05-07 13:40:13.0 +0200
+++ src/writesubst.cc 2021-11-05 14:26:23.229149292 +0100
@@ -109,8 +109,8 @@
case 'M':
{
-const char *mod = get_module_name().c_str();
-err = fputs_failed(fputs(mod, out));
+string mod = get_module_name();
+err = fputs_failed(fputs(mod.c_str(), out));
}
break;
Bug#998642: cssc: The "get" command fails to interpolate the "module name" for long filenames
Package: cssc Version: 1.4.1-1 Severity: normal Dear Maintainer, * What led up to the situation? We found that the %M% SCCS keyword in some of our files was not being correctly interpolated. * What exactly did you do (or not do) that was effective (or ineffective)? Did a "get" on a file called s._x-xx * What was the outcome of this action? In the created file _x-xx the %M% keyword was replaced by an empty string instead of the module name _x-xx * What outcome did you expect instead? That %M% be replaced by _x-xx This used to work with older versions of cssc. I have tried running "get" under valgrind and was surprised to see "Invalid read" errors: $ valgrind /usr/lib/x86_64-linux-gnu/cssc/get -t "SCCS/s._x-xx" ==24638== Memcheck, a memory error detector ==24638== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==24638== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==24638== Command: /usr/lib/x86_64-linux-gnu/cssc/get -t SCCS/s._x-xx ==24638== ==24638== Invalid read of size 1 ==24638==at 0x4838CC2: __strlen_sse2 (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==24638==by 0x4BF84A4: fputs (iofputs.c:33) ==24638==by 0x111F27: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x112057: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x110EF0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x10FBD0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x10CBAA: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x4BAC09A: (below main) (libc-start.c:308) ==24638== Address 0x4d685a0 is 0 bytes inside a block of size 18 free'd ==24638==at 0x4836EAB: operator delete(void*) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==24638==by 0x111F1C: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x112057: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x110EF0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x10FBD0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x10CBAA: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x4BAC09A: (below main) (libc-start.c:308) ==24638== Block was alloc'd at ==24638==at 0x4835DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==24638==by 0x10E56C: void std::__cxx11::basic_string, std::allocator >::_M_construct(char*, char*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x114165: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x111F05: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x112057: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x110EF0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x10FBD0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x10CBAA: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get) ==24638==by 0x4BAC09A: (below main) (libc-start.c:308) ==24638== -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cssc depends on: ii libc62.31-13+deb11u2 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libstdc++6 10.2.1-6 cssc recommends no packages. Versions of packages cssc suggests: pn groff -- no debconf information
Bug#994242: linux-image-5.10.0-8-amd64: On a DELL Optiplex 5090 the screen goes black on boot
Package: src:linux Version: 5.10.46-4 Severity: important Dear Maintainer, * What led up to the situation? Installed Debian Bullseye on a new DELL Optiplex 5090 PC * What was the outcome of this action? After the initial boot messages the screen goes blank. * What outcome did you expect instead? A nice Gnome greeting. The kernel linux-image-5.14.0-trunk-amd64 (5.14.3-1~exp1) from experimental works OK. -- Package-specific info: ** Version: Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root=UUID=487ddbab-4e6f-4edd-9990-6eca189de994 ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [1.138692] [ cut here ] [1.138693] i915 :00:02.0: drm_WARN_ON(!IS_PLATFORM(dev_priv, INTEL_TIGERLAKE) && !IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)) [1.138730] WARNING: CPU: 3 PID: 171 at drivers/gpu/drm/i915/intel_pch.c:123 intel_pch_type+0x898/0x950 [i915] [1.138731] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper xhci_pci xhci_hcd cec ahci libahci drm libata nvme usbcore e1000e(+) nvme_core scsi_mod t10_pi crc_t10dif crc32_pclmul crc32c_intel ptp i2c_i801 intel_lpss_pci crct10dif_generic pps_core crct10dif_pclmul i2c_smbus crct10dif_common intel_lpss idma64 usb_common wmi video button [1.138744] CPU: 3 PID: 171 Comm: systemd-udevd Not tainted 5.10.0-8-amd64 #1 Debian 5.10.46-4 [1.138745] Hardware name: Dell Inc. OptiPlex 5090/0X4H68, BIOS 1.1.24 05/17/2021 [1.138772] RIP: 0010:intel_pch_type+0x898/0x950 [i915] [1.138774] Code: 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 61 89 dc d4 48 c7 c1 80 c6 9c c0 4c 89 e2 48 c7 c7 75 65 9f c0 48 89 c6 e8 6b 57 02 d5 <0f> 0b e9 19 f9 ff ff 48 8b 7b 18 4c 8b 67 50 4d 85 e4 75 03 4c 8b [1.138774] RSP: 0018:a864805bfb80 EFLAGS: 00010282 [1.138775] RAX: RBX: 959d5068 RCX: 966b33a8 [1.138776] RDX: c000efff RSI: efff RDI: 0247 [1.138777] RBP: 959d0151e000 R08: R09: a864805bf9a0 [1.138777] R10: a864805bf998 R11: 966cb3e8 R12: 959d014c4e40 [1.138778] R13: 4380 R14: 959d50680808 R15: 959d5068 [1.138779] FS: 7f10ed71c8c0() GS:95a07d4c() knlGS: [1.138779] CS: 0010 DS: ES: CR0: 80050033 [1.138780] CR2: 7f10ed707b7a CR3: 0002d822e005 CR4: 003706e0 [1.138781] Call Trace: [1.138808] intel_detect_pch+0x5b/0x2f0 [i915] [1.138833] i915_driver_probe+0x2c1/0xc90 [i915] [1.138837] ? acpi_dev_found+0x63/0x70 [1.138839] ? vga_switcheroo_client_probe_defer+0x1f/0x40 [1.138863] ? i915_pci_probe+0x3f/0x150 [i915] [1.138865] local_pci_probe+0x42/0x80 [1.138867] ? _cond_resched+0x16/0x40 [1.138868] pci_device_probe+0xfd/0x1b0 [1.138870] really_probe+0xf2/0x440 [1.138871] driver_probe_device+0xe1/0x150 [1.138873] device_driver_attach+0xa1/0xb0 [1.138874] __driver_attach+0x8a/0x150 [1.138875] ? device_driver_attach+0xb0/0xb0 [1.138877] ? device_driver_attach+0xb0/0xb0 [1.138878] bus_for_each_dev+0x78/0xc0 [1.138879] bus_add_driver+0x12b/0x1e0 [1.138881] driver_register+0x8b/0xe0 [1.138882] ? 0xc0adf000 [1.138909] i915_init+0x5d/0x70 [i915] [1.138918] do_one_initcall+0x44/0x1d0 [1.138921] ? do_init_module+0x23/0x260 [1.138922] ? kmem_cache_alloc_trace+0xf5/0x200 [1.138924] do_init_module+0x5c/0x260 [1.138925] __do_sys_finit_module+0xb1/0x110 [1.138928] do_syscall_64+0x33/0x80 [1.138930] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1.138931] RIP: 0033:0x7f10edbd59b9 [1.138932] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48 [1.138932] RSP: 002b:7ffc2a995708 EFLAGS: 0246 ORIG_RAX: 0139 [1.138933] RAX: ffda RBX: 56262c355170 RCX: 7f10edbd59b9 [1.138934] RDX: RSI: 7f10edd60e2d RDI: 000e [1.138935] RBP: 0002 R08: R09: 56262c355010 [1.138935] R10: 000e R11: 0246 R12: 7f10edd60e2d [1.138936] R13: R14: 56262c354fc0 R15: 56262c355170 [1.138937] ---[ end trace 5a3b3d1667028c7c ]--- [1.139370] i915 :00:02.0: [drm] VT-d active for gfx access [1.139372] checking generic (40 1fa4000) vs hw (60 100) [1.139372] checking generic (40 1fa4000) vs hw (40 1000) [1.139373] fb0: switching to inteldrmfb from EFI VGA [1.139432] Console: switching to colour
Bug#989906: openssh-server: With GSSAPIKeyExchage "yes" openssh presents poor quality key exchange methods
Package: openssh-server Version: 1:7.9p1-10+deb10u2 Severity: important Dear Maintainer, What did I do? * Configured GSSAPIKeyExchange "yes", because it's a good idea and the automatic updating of renewed credentials it allows is very, very useful. What happened? * When connecting to the OpenSSH server I see some quite horrible key exchange methods proposed and accepted: debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group1-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q== debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g== * What outcome did you expect instead? Something more modern? Some security scanners have started reporting at least gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g== as a vulnerability, e.g. Qualys calls it "QID 38739: Deprecated SSH Cryptographic Settings" https://qualys-secure.force.com/customer/s/article/06407 As far as I can tell there is no way of configuring openssh to avoid using gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==. -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.7 ii libaudit1 1:2.8.4-3 ii libc6 2.28-10 ii libcom-err21.44.5-1+deb10u3 ii libgssapi-krb5-2 1.17-3+deb10u1 ii libkrb5-3 1.17-3+deb10u1 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libselinux12.8-1+b1 ii libssl1.1 1.1.1d-0+deb10u6 ii libsystemd0241-7~deb10u7 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 ii openssh-client 1:7.9p1-10+deb10u2 ii openssh-sftp-server1:7.9p1-10+deb10u2 ii procps 2:3.3.15-2 ii ucf3.0038+nmu1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 241-7~deb10u7 ii ncurses-term 6.1+20181013-2+deb10u2 ii xauth1:1.0.10-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw -- debconf information excluded
Bug#915008: I've seen a similar problem and managed to work around it.
0:00:14.3: Found debug configuration: 0 Jul 29 12:13:09 oceanic kernel: [ 15.072269] iwlwifi :00:14.3: loaded firmware version 46.a41adfe7.0 9000-pu-b0-jf-b0-46.ucode op_mode iwlmvm Jul 29 12:13:09 oceanic kernel: [ 15.226922] iwlwifi :00:14.3: Detected Intel(R) Wireless-AC 9560 160MHz, REV=0x318 Jul 29 12:13:09 oceanic kernel: [ 15.235063] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM Jul 29 12:13:09 oceanic kernel: [ 15.235387] iwlwifi :00:14.3: Allocated 0x0040 bytes for firmware monitor. Jul 29 12:13:09 oceanic kernel: [ 15.280681] iwlwifi :00:14.3: base HW address: ac:67:5d:2d:e3:ee Jul 29 12:13:09 oceanic kernel: [ 15.518852] iwlwifi :00:14.3 wlo1: renamed from wlan0 Jul 29 12:13:10 oceanic kernel: [ 15.859594] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM Jul 29 12:13:10 oceanic kernel: [ 15.974940] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM Jul 29 12:13:10 oceanic kernel: [ 16.039011] iwlwifi :00:14.3: FW already configured (0) - re-configuring Jul 29 12:13:10 oceanic kernel: [ 16.078459] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM Jul 29 12:13:10 oceanic kernel: [ 16.207940] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM Jul 29 12:13:10 oceanic kernel: [ 16.275045] iwlwifi :00:14.3: FW already configured (0) - re-configuring It is possible that this problem was caused by the laptop battery running completely flat, and the Linux driver or firmware missing some initialisation step. -- *John HUGHES* Directeur technique *CalvaEDI* An Esker Company 58/A rue du Dessous des Berges, 75013 Paris Tel. : (+33) 1 4313 3131 Fax : (+33) 1 4313 3139
Bug#892325: linphone: please package linphone 4.0
On Thu, 8 Mar 2018 12:52:03 +0100 "Dr. Tobias Quathamer" wrote: > > I think dropping the deprecated GTK client is fine. Please, whatever happens, the gtk version of linphone should *not* be dropped. It is much more "old fashioned" in appearance than the new Qt version but is infinitely more useful as a working phone. The new Qt linphone doesn't even have a working call history!
Bug#959104: linphone: ldap is enabled but the ldap configuration page is not visible
Package: linphone Version: 3.12.0-3 Severity: normal Dear Maintainer, * What led up to the situation? wanted to try ldap * What exactly did you do (or not do) that was effective (or ineffective)? went to preferences page * What was the outcome of this action? No ldap tab is visible * What outcome did you expect instead? ldap configuration tab There is something wrong with parameters.ui, the ldap tab doesn't show up. If I hack around the file I can make it appear in place of the user interface tab and it appears to work, but I don't really know what I'm doing. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linphone depends on: ii libatk1.0-0 2.36.0-2 ii libbctoolbox10.6.0-2+b2 ii libbelcard1 1.0.2-1+b1 hi libbellesip0 1.6.3-5 ii libbzrtp01.0.6-3 ii libc62.30-4 ii libcairo21.16.0-4 ii libgcc-s1 [libgcc1] 10-20200418-1 ii libgcc1 1:10-20200418-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-4 ii libglib2.0-0 2.64.2-1 ii libgtk2.0-0 2.24.32-4 ii libmediastreamer-base10 1:2.16.1-4+b2 ii libmediastreamer-voip10 1:2.16.1-4+b2 ii libnotify4 0.7.9-1 ii libortp131:1.0.2-1.1 ii libpango-1.0-0 1.44.7-4 ii libpangocairo-1.0-0 1.44.7-4 ii libpangoft2-1.0-01.44.7-4 ii libpangoxft-1.0-01.44.7-4 ii libsqlite3-0 3.31.1-5 ii libstdc++6 10-20200418-1 ii libudev1 245.5-2 ii libxml2 2.9.10+dfsg-5 hi linphone-nogtk 3.12.0-3 ii zlib1g 1:1.2.11.dfsg-2 linphone recommends no packages. Versions of packages linphone suggests: ii yelp 3.36.0-1 -- no debconf information
Bug#954328: linphone loops sending REGISTER because it doesn't believe the SIP OK matches the SIP register
Package: linphone
Version: 3.12.0-3.1
Severity: normal
Dear Maintainer,
* What led up to the situation?
Trying to work from home due to covid-19 :(
* What exactly did you do (or not do) that was effective (or
ineffective)?
Set up linphone to talk to our existing asterisk setup.
* What was the outcome of this action?
Everything works but linphone takes about 20% cpu when idle
* What outcome did you expect instead?
Lower CPU usage when calls not in progress.
Details:
I've configured linphone to send calls to our asterisk and asterisk to be able
to call linphone as an extension. This works but I see linphone using a
constant ~20% of cpu. In the linphone debug window I see that linphone
doesn't believe that the SIP OK in reply to the SIP register matches, so
linphone (or, more exactly belle-sip) resends the REGISTER endlessly.
For example:
message: 2020-03-19 08:58:37:816 channel [0x5652c055ea30]: message sent to
[UDP://masked.masked.com:5060], size: [728] bytes
REGISTER sip:masked.masked.com SIP/2.0
Via: SIP/2.0/UDP 10.27.128.3:5060;branch=z9hG4bK.Xy81vVGP5;rport
From: ;tag=kiyGbhQuT
To: sip:j...@masked.masked.com
CSeq: 15003 REGISTER
Call-ID: -jz0iptAjY
Max-Forwards: 70
Supported: replaces, outbound
Accept: application/sdp
Accept: text/plain
Accept: application/vnd.gsma.rcs-ft-http+xml
Contact:
;+sip.instance=""
Expires: 3600
User-Agent: Linphone/3.12.0 (belle-sip/1.6.3)
Authorization: Digest realm="asterisk", nonce="7a074ecd", algorithm=MD5,
username="john", uri="sip:masked.masked.com",
response="27e6d621c10672a7a553e82addb894cc"
message: 2020-03-19 08:58:37:844 channel [0x5652c05ba260]: received [553] new
bytes from [UDP://:::10.27.128.1:5060]:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
10.27.128.3:5060;branch=z9hG4bK.Xy81vVGP5;received=10.27.128.3;rport=5060
From: ;tag=kiyGbhQuT
To: sip:j...@masked.masked.com;tag=as33ad5d3a
Call-ID: -jz0iptAjY
CSeq: 15003 REGISTER
Server: Asterisk PBX 13.14.1~dfsg-2+deb9u4
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 3600
Contact: ;expires=3600
Date: Thu, 19 Mar 2020 07:58:37 GMT
Content-Length: 0
message: 2020-03-19 08:58:37:846 channel [0x5652c05ba260] [553] bytes parsed
message: 2020-03-19 08:58:37:846 Found transaction matching response.
message: 2020-03-19 08:58:37:846 Changing [client] [REGISTER] transaction
[0x5652c0bdac10], from state [TRYING] to [COMPLETED]
message: 2020-03-19 08:58:37:847 Refresher [0x5652c039da00]: contact address
[10.27.128.3:5060] does not match channel address[(null):0] on channel
[0x5652c055ea30]
message: 2020-03-19 08:58:37:847 belle_sip_refresher_start(): refresher
[0x5652c039da00] is resubmitting request because contact sent was not correct
in original request.
The message "contact address ... does not match channel address" is in
belle-sip src/refresher.c function is_contact_request_accurate:
if (channel_public_port == contact_port
&& channel_public_ip && contact_ip
&& strcmp(channel_public_ip,contact_ip) == 0) {
/*nothing to do contact is accurate*/
belle_sip_header_contact_set_unknown(contact,FALSE);
return TRUE;
} else {
belle_sip_message("Refresher [%p]: contact address
[%s:%i] does not match channel address[%s:%i] on channel [%p]" ,refresher
,contact_ip
,contact_port
,channel_public_ip
,channel_public_port
,refresher->transaction->base.channel);
return FALSE;
}
It seems that when we get here refresher->transaction->base.channel->public_ip
is NULL.
Here is the part of my .linphonerc where the proxy is defined:
[proxy_0]
reg_proxy=sip:masked.masked.com
reg_identity=sip:j...@masked.masked.com
quality_reporting_enabled=0
quality_reporting_interval=0
reg_expires=3600
reg_sendregister=1
publish=1
avpf=0
avpf_rr_interval=5
dial_escape_plus=0
privacy=32768
publish_expires=-1
I made a simple hack to refresher.c to accept OK replies if "public_ip" was
NULL, which drops the CPU time and seems to have no bad effects but is almost
certainly the wrong "fix".
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linphone depends on:
ii libatk1.0-0 2.34.1-1
ii
Bug#948277: certbot: stretch-backports certbot is version 0.28, --dry-run fails
Package: certbot Version: 0.28.0-1~bpo9+1 Severity: wishlist Dear Maintainer, * What led up to the situation? trying to use let's encrypt / certbot * What exactly did you do (or not do) that was effective (or ineffective)? Tried to do a --dry-run to test certificate renewal * What was the outcome of this action? got an error: urn:ietf:params:acme:error:malformed :: The request message was malformed :: Method not allowed. * What outcome did you expect instead? Dry run success According to Let's encrypt this is a bug in --dry-run for versions of certbot <= 0.32. Could we have 0.32 or greater backported to Stretch? https://community.letsencrypt.org/t/problem-with-renew-certificates-the-request-message-was-malformed-method-not-allowed/107889 -- System Information: Debian Release: 9.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-11-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages certbot depends on: ii python3 3.5.3-1 ii python3-certbot 0.28.0-1~bpo9+1 certbot recommends no packages. Versions of packages certbot suggests: pn python-certbot-doc ii python3-certbot-apache 0.28.0-1~bpo9+1 pn python3-certbot-nginx -- no debconf information
Bug#803197: Exactly the same problem happens with sendmail.
On 30/12/2018 02:40, Ryan Tandy wrote: I'm sorry for not responding to this for so long, but do you recall what release of Debian you saw this behaviour on? squeeze (yes, it's completely out of date :( ) I've been looking at this ticket again and it looks like in stretch (Debian 9) and later, GnuTLS uses the getrandom() system call and does not open/reopen anything. So I'm wondering whether you encountered this problem in stretch as well, or only in jessie - or whether getrandom() is for some reason not available on your setup and GnuTLS falls back to opening urandom. If you still have the same problem on stretch or buster, I'd welcome any info about how to set up a system to reproduce it. I actually "fixed" it by rerouting the mail via a system running stretch.
Bug#911602: thunderbird: error console doesn't work -- all categories disabled, can't enable
Package: thunderbird Version: 1:60.2.1-1 Severity: normal Dear Maintainer, * What led up to the situation? Thunderbird 60 was installed (as a security update), the error console stopped working. * What exactly did you do (or not do) that was effective (or ineffective)? Opening Tools/Developper Tools/Error console pops up the error console but... * What was the outcome of this action? The console is empty abd clicking on the drop down menu items -- Net, CSS, JS, Security, Logging, Server -- shows checkboxes for different message levels (e.g. Errors, Warnings, XHR, Log for Net) but all levels are unchecked and cannot be checked. * What outcome did you expect instead? The usual spew of unitelligable errors, which is occasionally useful. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunderbird depends on: ii debianutils 4.8.6 ii fontconfig2.13.1-1 ii libatk1.0-0 2.30.0-1 ii libc6 2.27-6 ii libcairo-gobject2 1.15.12-1 ii libcairo2 1.15.12-1 ii libdbus-1-3 1.12.10-1 ii libdbus-glib-1-2 0.110-3 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-8 ii libfontconfig12.13.1-1 ii libfreetype6 2.8.1-2 ii libgcc1 1:8.2.0-7 ii libgdk-pixbuf2.0-02.38.0+dfsg-6 ii libglib2.0-0 2.58.1-2 ii libgtk-3-03.24.1-2 ii libgtk2.0-0 2.24.32-3 ii libhunspell-1.6-0 1.6.2-1+b1 ii libicu60 60.2-6 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.20-1 ii libnss3 2:3.39-1 ii libpango-1.0-01.42.4-3 ii libpangocairo-1.0-0 1.42.4-3 ii libpangoft2-1.0-0 1.42.4-3 ii libsqlite3-0 3.25.2-1 ii libstartup-notification0 0.12-5 ii libstdc++68.2.0-7 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-shm0 1.13.1-1 ii libxcb1 1.13.1-1 ii libxext6 2:1.3.3-1+b2 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii psmisc23.2-1 ii x11-utils 7.7+4 ii zlib1g1:1.2.11.dfsg-1 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1 ii hunspell-fr-classical [hunspell-dictionary] 1:6.3-1 ii lightning1:60.2.1-1 Versions of packages thunderbird suggests: ii apparmor 2.13-8 pn fonts-lyx ii libgssapi-krb5-2 1.16.1-1 -- no debconf information
Bug#571617: multipath-tools: multipathd "switch multipath group" leads to strange state
On 11/08/18 21:38, Chris Hofstaedtler wrote: Do you still see this behaviour in stretch and/or buster? I'm not using multipath tools at the moment.
Bug#886746: Bug is fixed in vanilla kernel 4.9.77
This bug appears to have been fixed somewhere between 4.9.65 and 4.9.77 -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#886746: Bug exists in vanilla kernel 4.9.65
I've compiled a vanilla kernel 4.9.65 (from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git) and the bug is present. Vanilla kernel 4.9.30 works. I'll roll up my sleeves and start bisecting. -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#886746: Bug also present in linux-image-4.9.0-4-amd64 4.9.65-3+deb9u1
Versionn linux-image-4.9.0-3-amd64 seems Ok. -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#886746: linux-image-4.9.0-5-amd64: screen connected via displayport hub flashes black
Package: src:linux Version: 4.9.65-3+deb9u2 Severity: normal Dear Maintainer, * What led up to the situation? Installed linux-image-4.9.0-5-amd64 version 4.9.65-3+deb9u2 * What exactly did you do (or not do) that was effective (or ineffective)? Open a gnome-terminal window, wait a while then type something * What was the outcome of this action? Sometimes one of the two connected monitors will suddenly go black for a few seconds. (It's happened three or four times as I type this bug report). * What outcome did you expect instead? That the monitor not go black. This bug didn't happen with the previous version of the kernel, linux-image-4.9.0-4-amd64 The system has intel graphics, one displayport connector. Two monitors are connected via a 3 port displayport hub. No messages appear in the kernel log or journal when the screen goes black. One FIFO underrun message is in the kernel log, but it's many minutes before the screen flashing: Jan 9 14:17:45 cymric kernel: [ 140.418643] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A Jan 9 14:17:45 cymric kernel: [ 140.418655] [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun -- Package-specific info: ** Version: Linux version 4.9.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-5-amd64 root=UUID=81e06bed-a8c7-4345-9e2c-9c70a0b8e6d6 ro quiet splash ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Dell Inc. product_name: OptiPlex 3020 product_version: 01 chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: A03 board_vendor: Dell Inc. board_name: 0WMJ54 board_version: A00 ** Loaded modules: fuse cbc cts rpcsec_gss_krb5 nfsv4 dns_resolver nfs lockd grace fscache intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_realtek kvm snd_hda_codec_generic irqbypass snd_hda_codec_hdmi crct10dif_pclmul snd_hda_intel snd_hda_codec crc32_pclmul ghash_clmulni_intel snd_hda_core snd_hwdep snd_pcm snd_timer intel_cstate snd intel_uncore iTCO_wdt iTCO_vendor_support soundcore dcdbas intel_rapl_perf sg mei_me pcspkr evdev serio_raw lpc_ich mfd_core mei battery shpchp parport_pc ppdev lp parport auth_rpcgss oid_registry sunrpc ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache hid_generic usbhid hid sr_mod cdrom sd_mod crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse ahci libahci libata i915 i2c_i801 scsi_mod i2c_smbus i2c_algo_bit xhci_pci ehci_pci xhci_hcd drm_kms_helper ehci_hcd r8169 mii usbcore drm usb_common fan thermal video button ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06) Subsystem: Dell 4th Gen Core Processor DRAM Controller [1028:0612] 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: hsw_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Generation Core Processor Family Integrated Graphics Controller [8086:041e] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Dell 4th Generation Core Processor Family Integrated Graphics Controller [1028:0612] 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: i915 Kernel modules: i915 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) Subsystem: Dell Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [1028:0612] 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 Kernel modules: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Dell 8 Series/C220 Series Chipset Family USB xHCI [1028:0612] 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: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04) Subsystem: Dell 8 Series/C220 Series Chipset Family MEI
Bug#879115: hplip can't print jobs with unicode surrogate characters
Package: hplip
Version: 3.16.11+repack0-3
Severity: normal
Tags: upstream
Dear Maintainer,
* What led up to the situation?
Tried to print PDF from evince
* What exactly did you do (or not do) that was effective (or
ineffective)?
Pressed the print button
* What was the outcome of this action?
The print job "stopped"
* What outcome did you expect instead?
Some printed paper.
Looking in the cups error_log I see:
D [19/Oct/2017:14:03:08 +0200] [Job 2204] File
\"/usr/share/hplip/base/sixext.py\", line 109, in to_bytes_utf8
D [19/Oct/2017:14:03:08 +0200] [Job 2204] return s.encode(\"utf-8\")
D [19/Oct/2017:14:03:08 +0200] [Job 2204] UnicodeEncodeError: \'utf-8\' codec
can\'t encode character \'\\udcc3\' in position 19: surrogates not allowed
This appears to be the launchpad bug:
https://bugs.launchpad.net/hplip/+bug/1498366
A simple, possibly incorrect, fix is:
--- /usr/share/hplip/base/sixext.py.orig2017-05-04 18:35:44.0
+0200
+++ /usr/share/hplip/base/sixext.py 2017-10-19 17:40:51.946105373 +0200
@@ -106,7 +106,7 @@
def to_bytes_utf8(s):
-return s.encode("utf-8")
+return s.encode("utf-8", errors="surrogateescape")
def to_string_utf8(s):
-- Package-specific info:
Saving output in log file: /home/john/hp-check.log
HP Linux Imaging and Printing System (ver. 3.16.11)
Dependency/Version Check Utility ver. 15.1
Copyright (c) 2001-15 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.
Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling
the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper
dependencies are installed
to successfully compile HPLIP.
2. Run-time check mode (-r or --run): Use this mode to determine if a distro
supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball
has the proper
dependencies installed to successfully run.
3. Both compile- and run-time check mode (-b or --both) (Default): This mode
will check both of the above cases (both compile- and run-time dependencies).
Check types:
a. EXTERNALDEP - External Dependencies
b. GENERALDEP - General Dependencies (required both at compile and run time)
c. COMPILEDEP - Compile time Dependencies
d. [All are run-time checks]
PYEXT SCANCONF QUEUES PERMISSION
Status Types:
OK
MISSING - Missing Dependency or Permission or Plug-in
INCOMPAT - Incompatible dependency-version or Plugin-version
warning: 2-9.1 version is not supported. Using 2-8.6 versions dependencies to
verify and install...
---
| SYSTEM INFO |
---
Kernel: 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) GNU/Linux
Host: persic
Proc: 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) GNU/Linux
Distribution: 2 9.1
Bitness: 64 bit
---
| HPLIP CONFIGURATION |
---
HPLIP-Version: HPLIP 3.16.11
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for 2 distro
9.1 version
Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf. Generated from hplip.conf.in by configure.
[hplip]
version=3.16.11
[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip
html=/usr/share/doc/hplip-doc
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv
bin=/usr/bin
apparmor=/etc/apparmor.d
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=yes
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
Bug#802612: Or to put it another way...
Another way to read "fakeroot fails in user namespaces" is "fakeroot only works on stretch if you change init". -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#803197: Exactly the same problem happens with sendmail.
Sendmail, on start, closes all fd's above 2. Since sendmail is linked to libldap, which is linked to gnutls this means sendmail closes fd 3, on which gnutls has opened /dev/urandom. Later on in the sendmail run fd 3 gets reopened, and if a ldap function is called then gnutls unceremoniously closes the fd and reopens /dev/urandom. From sendmail's point of view it looks like one of its files has suddenly been replaced with random garbage! I've hacked my copy of sendmail to close fds above 3, which works around the problem for me, but is a bit ugly. -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#870198: This is issue 67 in upstream -- Filters editing window hangs in TB 47
https://github.com/thsmi/sieve/issues/67 There is a patch for it -- https://github.com/thsmi/sieve/commit/cdf54a49fe50641dac73e657346e8c2249fbb63f -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#873171: mdadm starts arrays on boot even though AUTO -all specified if no ARRAY in mdadm.conf
Package: mdadm Version: 3.4-4+b1 Severity: normal Dear Maintainer, * What led up to the situation? Upgraded from Jessie to Stretch * What exactly did you do (or not do) that was effective (or ineffective)? We want to start our mdadm raid arrays manually, so we have no ARRAY lines in mdadm.conf and we have AUTO -all. * What was the outcome of this action? Arrays are not started on udev events (which is good), but they *are* started on boot (which is bad). * What outcome did you expect instead? No array to be automatically started. What is happening is: When the /usr/share/initramfs-tools/hooks/mdadm script is run during initrd creation it notices that we have no ARRAY lines in our mdadm.conf, so it uses /usr/share/mdadm/mkconf to make a new mdadm.conf which means that all arrays connected to the machine when the initrd is created will be started on boot. As a workaround we have added a dummy ARRAY declaration to our mdadm.conf: AUTO -all ARRAY name=unused And now, although mkinitrd issues many boring warnings about arrays not being in mdadm.conf it doesn't start all our arrays on boot. -- Package-specific info: --- mdadm.conf DEVICE partitions CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST MAILADDR sta...@olympic.calvaedi.com AUTO -all ARRAY name=unused --- /etc/default/mdadm AUTOCHECK=true START_DAEMON=true DAEMON_OPTIONS="--syslog" VERBOSE=false --- /proc/mdstat: Personalities : [raid1] [raid10] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] md125 : active raid1 sdb[2] sdd[3] 3906887360 blocks super 1.2 [2/2] [UU] bitmap: 0/30 pages [0KB], 65536KB chunk md126 : active raid1 sdc[2] sde[3] 1953511869 blocks super 1.1 [2/2] [UU] bitmap: 0/466 pages [0KB], 2048KB chunk md127 : active raid10 sdz[0] sdi[11] sdq[12] sdj[9] sdt[8] sdk[7] sdu[6] sdl[5] sdw[4] sdm[3] sdx[2] sdn[1] 429729792 blocks super 1.2 512K chunks 2 near-copies [12/12] [] bitmap: 1/4 pages [4KB], 65536KB chunk unused devices: --- /proc/partitions: major minor #blocks name 80 71041024 sda 81 498688 sda1 82 1 sda2 85 70539264 sda5 1101048575 sr0 8 16 3907018584 sdb 8 32 1953514584 sdc 8 48 3907018584 sdd 8 64 1953514584 sde 8 80 976762584 sdf 8 96 143374740 sdg 8 112 71687325 sdh 8 128 71687325 sdi 8 144 71687325 sdj 8 160 71687325 sdk 8 176 71687325 sdl 8 192 71687325 sdm 8 208 71687325 sdn 8 224 143374740 sdo 8 240 62522712 sdp 650 71687325 sdq 65 16 976762584 sdr 65 32 143374740 sds 65 48 71687325 sdt 65 64 71687325 sdu 65 80 62522712 sdv 65 96 71687325 sdw 65 112 71687325 sdx 65 128 143374740 sdy 65 144 71687325 sdz 25307811072 dm-0 2531 23437312 dm-1 2532 15622144 dm-2 25337811072 dm-3 9 127 429729792 md127 2590 258016 md127p1 2591 429471504 md127p2 9 126 1953511869 md126 9 125 3906887360 md125 --- LVM physical volumes: PV VGFmt Attr PSize PFree /dev/sda5 arabic-vg lvm2 a-- 67.27g 15.12g --- mount output sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=12328556k,nr_inodes=3082139,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=2468104k,mode=755) /dev/mapper/arabic--vg-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on
Bug#873116: mdadm: If no arrays are specified in mdadm.conf then initrd starts all arrays
Package: mdadm Version: 3.4-4+b1 Severity: normal Dear Maintainer, * What led up to the situation? upgraded from jessie to stretch * What exactly did you do (or not do) that was effective (or ineffective)? We want to manually start our arrays, rather than having them started on boot or udev detection, so we specify: AUTO -all with no ARRAYs in mdadm.conf * What was the outcome of this action? On boot all arrays were started. * What outcome did you expect instead? No arrays automatically started What happens is that the script /usr/share/initramfs-tools/hooks/mdadm notices that there are no ARRAYs defined in mdadm.conf it uses the script /usr/share/mdadm/mkconf to make a configuration including all arrays attached to the system. As a workaround we have added a dummy array: ARRAY name=unused to our configuration and now no arrays get started on boot (which is what we want). The messages about currently running arrays that are not in the config are annoying, but we can ignore them. -- Package-specific info: --- mdadm.conf DEVICE partitions CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST MAILADDR sta...@olympic.calvaedi.com AUTO -all ARRAY name=unused --- /etc/default/mdadm AUTOCHECK=true START_DAEMON=true DAEMON_OPTIONS="--syslog" VERBOSE=false --- /proc/mdstat: Personalities : [raid1] [raid10] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] md125 : active raid1 sdb[2] sdd[3] 3906887360 blocks super 1.2 [2/2] [UU] bitmap: 0/30 pages [0KB], 65536KB chunk md126 : active raid1 sdc[2] sde[3] 1953511869 blocks super 1.1 [2/2] [UU] bitmap: 0/466 pages [0KB], 2048KB chunk md127 : active raid10 sdz[0] sdi[11] sdq[12] sdj[9] sdt[8] sdk[7] sdu[6] sdl[5] sdw[4] sdm[3] sdx[2] sdn[1] 429729792 blocks super 1.2 512K chunks 2 near-copies [12/12] [] bitmap: 1/4 pages [4KB], 65536KB chunk unused devices: --- /proc/partitions: major minor #blocks name 80 71041024 sda 81 498688 sda1 82 1 sda2 85 70539264 sda5 1101048575 sr0 8 16 3907018584 sdb 8 32 1953514584 sdc 8 48 3907018584 sdd 8 64 1953514584 sde 8 80 976762584 sdf 8 96 143374740 sdg 8 112 71687325 sdh 8 128 71687325 sdi 8 144 71687325 sdj 8 160 71687325 sdk 8 176 71687325 sdl 8 192 71687325 sdm 8 208 71687325 sdn 8 224 143374740 sdo 8 240 62522712 sdp 650 71687325 sdq 65 16 976762584 sdr 65 32 143374740 sds 65 48 71687325 sdt 65 64 71687325 sdu 65 80 62522712 sdv 65 96 71687325 sdw 65 112 71687325 sdx 65 128 143374740 sdy 65 144 71687325 sdz 25307811072 dm-0 2531 23437312 dm-1 2532 15622144 dm-2 25337811072 dm-3 9 127 429729792 md127 2590 258016 md127p1 2591 429471504 md127p2 9 126 1953511869 md126 9 125 3906887360 md125 --- LVM physical volumes: PV VGFmt Attr PSize PFree /dev/sda5 arabic-vg lvm2 a-- 67.27g 15.12g --- mount output sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=12328556k,nr_inodes=3082139,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=2468104k,mode=755) /dev/mapper/arabic--vg-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/cpuset type cgroup
Bug#867311: Enviroment variables
The problem is that on gdm3 3.22 when we get to "pam_setcred(PAM_REINITIALIZE_CRED)" we have not set the KRB5CCNAME environment variable. The pam-krb5 readme (https://www.eyrie.org/~eagle/software/pam-krb5/readme.html) says: The normal sequence of events when refreshing a ticket cache (such as inside a screensaver) is: pam_authenticate pam_setcred(PAM_REINITIALIZE_CRED) pam_acct_mgmt (PAM_REFRESH_CRED may be used instead.) Authentication proceeds as above. At the pam_setcred stage, rather than creating a new ticket cache, the module instead finds the current ticket cache (from the KRB5CCNAME environment variable or the default ticket cache location from the Kerberos library) and then reinitializes it with the credentials from the temporary pam_authenticate ticket cache. When refreshing a ticket cache, the application should *not* open a session. Calling pam_acct_mgmt is optional; pam-krb5 doesn't do anything different when it's called in this case. So it won't work if we don't set the KRB5CCNAME environment variable. But when? Should we special case this one or set all PAM environment variables? -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#867311: How ticket renewal "works" on Stretch
The difference between gdm3-3.14 and gdm3-3.22 seems to be that in 3.22 the PAM "setcred" operation is done by the gdm-session-worker started by gdm, where in gdm 3.14 a second gdm-session-worker is started with the enviromnent returmed by PAM. -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#867311: How ticket renewal works on Jessie (gdm3-3.14.1-7)
gdm3 sends a StartReauthentication message to the gdm-session-worker. gdm-session-worker creates a ReauthenticationRequest. reauthentication_request_new creates a GdmSession with the environment from PAM (including KRB5CCNAME) session_worker_job starts a new gdm-session-worker with that environment the new worker does the reauthentication, then pam_sm_setcred: entry (reinit) which refreshes the ticket cache.
Bug#867311: Info received (Log from a jessie system (gdm3-3.14.1-7))
Further debugging by printf shows that: On Jessie when libpam_krb5 gets to "pam_sm_setcred: entry (reinit)" the ticket cache name is in the environment (KRB5CCNAME) (the real environment, not the PAM args one). On Stretch at the same place KRB5CCNAME is unset.
Bug#867311: Log from a jessie system (gdm3-3.14.1-7)
Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:auth): (user john) attempting authentication as j...@calvaedi.com Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:auth): user john authenticated as j...@calvaedi.com Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:auth): (user john) temporarily storing credentials in /tmp/krb5cc_pam_IsIrXX Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:auth): pam_sm_authenticate: exit (success) Jul 7 15:15:25 tauric gdm-password][3741]: gkr-pam: unlocked login keyring Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:account): pam_sm_acct_mgmt: entry Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:account): (user john) retrieving principal from cache Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:account): pam_sm_acct_mgmt: exit (success) Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:setcred): pam_sm_setcred: entry (reinit) Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:setcred): (user john) refreshing ticket cache /tmp/krb5cc_1001_BN2igY Jul 7 15:15:25 tauric gdm-password][3741]: pam_krb5(gdm-password:setcred): pam_sm_setcred: exit (success) And, of course, the screen unlock updates the krb5 ticket with no problem.
Bug#867311: Problem also noted in Ubuntu launchpad bug 1336663
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1336663 Which is about lightdm, bug also notes that the same bug exists in gdm3. -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#867311: gdm3: gnome unlock screen doesn't refresh kerberos ticket (via PAM)
Package: gdm3
Version: 3.22.3-3
Severity: normal
Dear Maintainer,
* What led up to the situation?
We use kerberos (and nfsv4) and gnome
* What exactly did you do (or not do) that was effective (or
ineffective)?
Locked my screen (or let my screen autolock), left the desk for a few
hours then came back and unlocked it
* What was the outcome of this action?
My kerberos ticket was not updated
* What outcome did you expect instead?
The kerberos ticket to be updated, like it used to be in Jessie.
Putting on a bit of debugging info by adding:
[appdefaults]
pam = {
debug = true
}
to /etc/krb5.conf
I see that pam appears to be updating the wrong ticket cache.
Jul 5 18:00:56 celtic gdm-password]: pam_krb5(gdm-password:account):
pam_sm_acct_mgmt: entry
Jul 5 18:00:56 celtic gdm-password]: pam_krb5(gdm-password:account): (user
john) retrieving principal from cache
Jul 5 18:00:56 celtic gdm-password]: pam_krb5(gdm-password:account):
pam_sm_acct_mgmt: exit (success)
Jul 5 18:00:56 celtic gdm-password]: pam_krb5(gdm-password:setcred):
pam_sm_setcred: entry (reinit)
Jul 5 18:00:56 celtic gdm-password]: pam_krb5(gdm-password:setcred): (user
john) refreshing ticket cache /tmp/krb5cc_0
Jul 5 18:00:56 celtic gdm-password]: pam_krb5(gdm-password:setcred):
pam_sm_setcred: exit (success)
If I look in /tmp/krb5cc_0 I do indeed see that I have a new ticket. The
problem being that that's not my ticket cache.
If, instead of locking the screen, I switch "virtual terminals" then it seems
to do the right thing:
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:auth): (user john)
attempting authentication as j...@calvaedi.com
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:auth): user john
authenticated as j...@calvaedi.com
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:auth): (user john)
temporarily storing credentials in /tmp/krb5cc_pam_foCdYY
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:auth):
pam_sm_authenticate: exit (success)
Jul 5 17:57:07 celtic gdm-password]: gkr-pam: unlocked login keyring
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:account):
pam_sm_acct_mgmt: entry
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:account): (user
john) retrieving principal from cache
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:account):
pam_sm_acct_mgmt: exit (success)
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:setcred):
pam_sm_setcred: entry (reinit)
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:setcred): (user
john) refreshing ticket cache /tmp/krb5cc_1001_M6avll
Jul 5 17:57:07 celtic gdm-password]: pam_krb5(gdm-password:setcred):
pam_sm_setcred: exit (success)
-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gdm3 depends on:
ii accountsservice 0.6.43-1
ii adduser 3.115
ii dconf-cli 0.26.0-2+b1
ii dconf-gsettings-backend 0.26.0-2+b1
ii debconf [debconf-2.0] 1.5.61
ii gir1.2-gdm-1.03.22.3-3
ii gnome-session [x-session-manager] 3.22.3-1
ii gnome-session-bin 3.22.3-1
ii gnome-settings-daemon 3.22.2-2
ii gnome-shell 3.22.3-3
ii gnome-terminal [x-terminal-emulator] 3.22.2-1
ii gsettings-desktop-schemas 3.22.0-1
ii libaccountsservice0 0.6.43-1
ii libaudit1 1:2.6.7-2
ii libc6 2.24-11+deb9u1
ii libcanberra-gtk3-00.30-3
ii libcanberra0 0.30-3
ii libgdk-pixbuf2.0-02.36.5-2
ii libgdm1 3.22.3-3
ii libglib2.0-0 2.50.3-2
ii libglib2.0-bin2.50.3-2
ii libgtk-3-03.22.11-1
ii libkeyutils1 1.5.9-9
ii libpam-modules1.1.8-3.6
ii libpam-runtime1.1.8-3.6
ii libpam-systemd232-25
ii libpam0g 1.1.8-3.6
ii librsvg2-common 2.40.16-1+b1
ii libselinux1 2.6-3+b1
ii libsystemd0 232-25
ii libwrap0 7.6.q-26
ii libx11-6 2:1.6.4-3
ii libxau6 1:1.0.8-1
ii libxcb1 1.12-1
ii libxdmcp6
Bug#833427: nautilus: Nautilus freezes when searching
Package: nautilus Version: 3.14.1-2 Severity: important Dear Maintainer, Any attempt to search in Nautilus causes Nautilus to freeze completely until the process is ended in System Monitor. It is then impossible to start Nautilus again until any tracker-* process is also ended in System Monitor. Action: use Nautilus search to search for files or folders. Outcome: Nautilus freezes until both it and tracker-related processes are ended manually. Expected outcome: Nautilus presents search results without crashing. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nautilus depends on: ii desktop-file-utils 0.22-1 ii gsettings-desktop-schemas 3.14.1-1 ii gvfs 1.22.2-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-18+deb8u4 ii libcairo-gobject2 1.14.0-2.1+deb8u1 ii libcairo2 1.14.0-2.1+deb8u1 ii libexempi3 2.2.1-2 ii libexif12 0.6.21-2 ii libgail-3-03.14.5-1+deb8u1 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u5 ii libglib2.0-0 2.42.1-1+b1 ii libglib2.0-data2.42.1-1 ii libgnome-desktop-3-10 3.14.1-1 ii libgtk-3-0 3.14.5-1+deb8u1 ii libnautilus-extension1a3.14.1-2 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-01.36.8-3 ii libselinux12.3-2 ii libtracker-sparql-1.0-01.2.4-2 ii libx11-6 2:1.6.2-3 ii libxml22.9.1+dfsg1-5+deb8u2 ii nautilus-data 3.14.1-2 ii shared-mime-info 1.3-1 Versions of packages nautilus recommends: ii eject 2.1.5+deb1+cvs20081104-13.1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-sushi3.12.0-2+b1 ii gvfs-backends 1.22.2-1 ii librsvg2-common2.40.5-1+deb8u2 Versions of packages nautilus suggests: ii brasero 3.11.4-1.1 ii eog 3.14.1-1 ii evince [pdf-viewer] 3.14.1-2+deb8u1 ii totem3.14.0-2 ii tracker 1.2.4-2 ii xdg-user-dirs0.15-2 -- no debconf information
Bug#824171: icedove can't open folder on IMAP server, shows "checking server capabilites" then nothing.
Package: icedove Version: 38.7.0-1~deb8u3 Severity: important Dear Maintainer, * What led up to the situation? Did an aptitude upgrade, upgraded icedove from 38.5.0-1~deb8u1 to 38.7.0-1~deb8u3 * What exactly did you do (or not do) that was effective (or ineffective)? Started icedove, tried to open folder on my imap server * What was the outcome of this action? Icedove displays Checking mail server capabilities... but does not show contents of folder. * What outcome did you expect instead? Display contents of folder, let me see the messages. Possibly related, I have the sieve extension and if I try to edit my sieve filters I get a "server terminated unexpectedly the connection". My imap server, cyrus-imapd-2.4, version 2.4.16-4+deb7u2 uses SSL and kerberos. I have an internal CA, which is added to the icedove CA list. If I downgrade to 38.5.0-1~deb8u1 everything works as before. -- System Information: Debian Release: 8.4 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.2-jh1 (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 Init: systemd (via /run/systemd/system) Versions of packages icedove depends on: ii debianutils 4.4+b1 ii fontconfig2.11.0-6.3 ii libasound21.0.28-1 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-18+deb8u4 ii libcairo2 1.14.0-2.1+deb8u1 ii libdbus-1-3 1.8.20-0+deb8u1 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-2 ii libffi6 3.1-2+b2 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.5.2-4 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-02.31.1-2+deb8u4 ii libglib2.0-0 2.42.1-1+b1 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libhunspell-1.3-0 1.3.3-3 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpixman-1-0 0.32.6-3 ii libsqlite3-0 3.8.7.4-1 ii libstartup-notification0 0.12-4 ii libstdc++64.9.2-10 ii libx11-6 2:1.6.2-3 ii libxcomposite11:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.1-2+b2 ii libxrender1 1:0.9.8-1+b1 ii libxt61:1.1.4-1+b1 ii psmisc22.21-2 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages icedove recommends: ii hunspell-en-us [hunspell-dictionary] 20070829-6 ii hunspell-fr-comprehensive [hunspell-dictionary] 1:5.2-1 ii iceowl-extension 38.7.0-1~deb8u3 Versions of packages icedove suggests: ii fonts-lyx 2.1.3-1 ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u2 -- no debconf information
Bug#772848: This is also 818502
Václav Ovsík, being much smarter than me, has tracked this bug down and found a patch that fixes it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818502 -- John Hughes, CalvaEDI S.A.S. -- An Esker Company <john.hug...@calva.com> +33 1 4313 3131
Bug#792582: simple-scan: With HP network connected MFC simple-scan gives model as scanner name
Package: simple-scan Version: 3.16.1.1-1 Severity: normal Dear Maintainer, * What led up to the situation? I have two HP MFC devices * What exactly did you do (or not do) that was effective (or ineffective)? I tried to pick the scanner I wanted from the simple-scan preferences * What was the outcome of this action? Since the to MFCs are the same model simple-scan gives them the same name, I can't tell which is which and they are not in the same office. * What outcome did you expect instead? Some way of telling which MFC is which, perhaps based on the cups description or location Here are my two scanners: $ scanimage -L device `hpaio:/net/HP_Color_LaserJet_MFP_M476dw?ip=' is a Hewlett-Packard HP_Color_LaserJet_MFP_M476dw all-in-one device `hpaio:/net/HP_Color_LaserJet_MFP_M476dw?ip=yy' is a Hewlett-Packard HP_Color_LaserJet_MFP_M476dw all-in-one simple-scan shows them both as HP_Color_LaserJet_MFP_M476dw. gscan2pdf at least shows me the ip=xx part. But what would be nicest is if I could see the cups description or location information. -- Package-specific info: -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages simple-scan depends on: ii adwaita-icon-theme 3.14.0-2 ii dbus-x11 1.8.18-0+deb8u1 ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii libatk1.0-0 2.14.0-1 ii libc62.19-18 ii libcairo-gobject21.14.0-2.1 ii libcairo21.14.0-2.1 ii libcolord2 1.2.1-1+b2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk-3-0 3.14.5-1 ii libgudev-1.0-0 215-17+deb8u1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libsane 1.0.24-9 ii xdg-utils1.1.0~rc1+git20111210-7.4 ii zlib1g 1:1.2.8.dfsg-2+b1 simple-scan recommends no packages. simple-scan suggests no packages. -- no debconf information [+0.07s] DEBUG: simple-scan.vala:594: Starting Simple Scan 3.16.1.1, PID=14148 [+0.07s] DEBUG: Connecting to session manager [+0.11s] DEBUG: ui.vala:1880: Loading state from /home/john/.cache/simple-scan/state [+0.15s] DEBUG: ui.vala:1848: Restoring window to 1082x1225 pixels [+0.15s] DEBUG: autosave-manager.vala:64: Loading autosave information [+0.15s] DEBUG: autosave-manager.vala:259: Waiting to autosave... [+0.24s] DEBUG: scanner.vala:1446: sane_init () - SANE_STATUS_GOOD [+0.24s] DEBUG: scanner.vala:1452: SANE version 1.0.24 [+0.24s] DEBUG: scanner.vala:1513: Requesting redetection of scan devices [+0.24s] DEBUG: scanner.vala:802: Processing request [+0.25s] DEBUG: autosave-manager.vala:281: Autosaving book information [+0.43s] DEBUG: ui.vala:1971: Saving state to /home/john/.cache/simple-scan/state [+4.05s] DEBUG: scanner.vala:338: sane_get_devices () - SANE_STATUS_GOOD [+4.05s] DEBUG: scanner.vala:350: Device: name=hpaio:/net/HP_Color_LaserJet_MFP_M476dw?ip= vendor=Hewlett-Packard model=HP_Color_LaserJet_MFP_M476dw type=all-in-one [+4.05s] DEBUG: scanner.vala:350: Device: name=hpaio:/net/HP_Color_LaserJet_MFP_M476dw?ip=yy vendor=Hewlett-Packard model=HP_Color_LaserJet_MFP_M476dw type=all-in-one [+11.79s] DEBUG: autosave-manager.vala:195: Deleting autosave records [+11.85s] DEBUG: scanner.vala:1586: Stopping scan thread [+11.85s] DEBUG: scanner.vala:802: Processing request [+11.86s] DEBUG: scanner.vala:1597: sane_exit () device `hpaio:/net/HP_Color_LaserJet_MFP_M476dw?ip=' is a Hewlett-Packard HP_Color_LaserJet_MFP_M476dw all-in-one device `hpaio:/net/HP_Color_LaserJet_MFP_M476dw?ip=yy' is a Hewlett-Packard HP_Color_LaserJet_MFP_M476dw all-in-one Bus 002 Device 003: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0a81 Chesen Electronics Corp. idProduct 0x0205 PS/2 Keyboard+Mouse Adapter bcdDevice0.10 iManufacturer 1 iProduct2 iSerial 0
Bug#759786: Bug is in intel drm, not gdm3, bug is still present.
Well, I spoke too soon - it doesn't work with 3.14.1-3, the problem is still present. I'm now convinced that it's a kernel bug - in the intel driver. Often, when I try to change the Gnome primary display from the built-in lvds panel to the external (HDMI) monitor I get errrors like: [ 111.840599] [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up [ 112.053452] [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up [ 112.061261] [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up [ 112.069045] [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up [ 112.076858] [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up [ 112.084674] [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up [ 112.092458] [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up [ 112.092625] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 112.121420] [drm:cpt_verify_modeset] *ERROR* mode set failed: pipe A stuck And, on occasion: [ 296.173419] [ cut here ] [ 296.173498] WARNING: CPU: 2 PID: 1341 at /build/linux-CMiYW9/linux-3.16.7-ckt2/drivers/gpu/drm/i915/intel_display.c:3324 intel_crtc_wait_for_pending_flips+0x165/0x170 [i915]() [ 296.173503] Modules linked in: binfmt_misc bnep cpufreq_stats cpufreq_powersave cpufreq_userspace cpufreq_conservative qmi_wwan cdc_wdm usbnet joydev tpm_infineon qcserial option usb_wwan usbserial arc4 iTCO_wdt iTCO_vendor_support uvcvideo ecb iwldvm x86_pkg_temp_thermal videobuf2_vmalloc videobuf2_memops snd_hda_codec_hdmi intel_powerclamp mac80211 intel_rapl videobuf2_core coretemp v4l2_common snd_hda_codec_realtek kvm_intel videodev snd_hda_codec_generic kvm media psmouse pcspkr serio_raw btusb iwlwifi bluetooth 6lowpan_iphc rtsx_pci_ms i2c_i801 memstick snd_hda_intel snd_hda_controller cfg80211 snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss sony_laptop snd_pcm rfkill snd_timer battery tpm_tis snd tpm evdev soundcore processor ac mei_me shpchp mei lpc_ich loop fuse parport_pc ppdev lp parport [ 296.173593] autofs4 ext4 crc16 mbcache jbd2 sha256_ssse3 sha256_generic algif_skcipher af_alg dm_crypt dm_mod raid0 md_mod sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel rtsx_pci_sdmmc mmc_core aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci libata scsi_mod i915 ehci_pci i2c_algo_bit xhci_hcd ehci_hcd drm_kms_helper r8169 mii drm rtsx_pci mfd_core usbcore i2c_core usb_common thermal button video thermal_sys [ 296.173662] CPU: 2 PID: 1341 Comm: Xorg Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt2-1 [ 296.173666] Hardware name: Sony Corporation VPCZ22AGX/VAIO, BIOS R1010H5 07/28/2011 [ 296.173670] 0009 81507263 81065847 [ 296.173677] 88025291e000 880252f18210 880252b2f800 [ 296.173683] 880252b2f800 a021fe85 88009636d370 [ 296.173690] Call Trace: [ 296.173703] [81507263] ? dump_stack+0x41/0x51 [ 296.173713] [81065847] ? warn_slowpath_common+0x77/0x90 [ 296.173745] [a021fe85] ? intel_crtc_wait_for_pending_flips+0x165/0x170 [i915] [ 296.173754] [810a5940] ? prepare_to_wait_event+0xf0/0xf0 [ 296.173782] [a0222fd0] ? intel_crtc_disable_planes+0x30/0x1a0 [i915] [ 296.173809] [a0223555] ? ironlake_crtc_disable+0x45/0x910 [i915] [ 296.173831] [a00aeb5a] ? drm_modeset_lock+0x2a/0xd0 [drm] [ 296.173840] [8150bace] ? mutex_lock+0xe/0x2a [ 296.173868] [a0224817] ? intel_crtc_update_dpms+0x67/0x90 [i915] [ 296.173897] [a0228419] ? intel_connector_dpms+0x59/0x70 [i915] [ 296.173921] [a00a5fd6] ? drm_mode_obj_set_property_ioctl+0x396/0x3b0 [drm] [ 296.173942] [a00a601e] ? drm_mode_connector_property_set_ioctl+0x2e/0x40 [drm] [ 296.173962] [a00958b7] ? drm_ioctl+0x1c7/0x5b0 [drm] [ 296.173976] [812b4c88] ? lockref_put_or_lock+0x48/0x80 [ 296.173984] [811bb44f] ? dput+0x1f/0x170 [ 296.173990] [811b7d2f] ? do_vfs_ioctl+0x2cf/0x4b0 [ 296.173997] [8108314c] ? task_work_run+0x9c/0xd0 [ 296.174003] [811b7f91] ? SyS_ioctl+0x81/0xa0 [ 296.174010] [8150d5ea] ? int_signal+0x12/0x17 [ 296.174016] [8150d32d] ? system_call_fast_compare_end+0x10/0x15 [ 296.174021] ---[ end trace a16743e82932155b ]--- [ 296.553911] [ cut here ] [ 296.553986] WARNING: CPU: 2 PID: 1341 at /build/linux-CMiYW9/linux-3.16.7-ckt2/drivers/gpu/drm/i915/intel_display.c:953 ironlake_crtc_disable+0x90/0x910 [i915]() [ 296.553991] pipe_off wait timed out [ 296.553993] Modules linked in: binfmt_misc bnep cpufreq_stats cpufreq_powersave cpufreq_userspace cpufreq_conservative qmi_wwan
Bug#759786: Works with gdm3 3.14.1-3
Well, now it seems to work again. As far as I can tell the problem was that the login page was being displayed on the built-in screen, but it was turned off. (Although I never managed to login by typing blind, so maybe it was worse than that). Now I have 3.14.1-3 all is well again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286: Info received (It looks like a conspiracy between libvirt and kvm)
Well, I've upgraded to: # dpkg -l libvirt* qemu* | grep '^ii' ii libvirt-bin 1.2.9-6~bpo70+1amd64 programs for the libvirt library ii libvirt-clients 1.2.9-6~bpo70+1amd64 programs for the libvirt library ii libvirt-daemon 1.2.9-6~bpo70+1amd64 programs for the libvirt library ii libvirt-daemon-system 1.2.9-6~bpo70+1 amd64Libvirt daemon configuration files ii libvirt0 1.2.9-6~bpo70+1amd64library for interfacing with different virtualization systems ii qemu-kvm 2.1+dfsg-9~bpo70+1 amd64QEMU Full virtualization on x86 hardware ii qemu-system-common 2.1+dfsg-9~bpo70+1 amd64QEMU full system emulation binaries (common files) ii qemu-system-x86 2.1+dfsg-9~bpo70+1 amd64 QEMU full system emulation binaries (x86) ii qemu-utils 2.1+dfsg-9~bpo70+1 amd64QEMU utilities But I get the same results: adriatic:~# virsh attach-device cedric.CalvaEDI.COM zz.xml error: Failed to attach device from zz.xml error: internal error: unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging However, I have found a clue: cedric:~# dmesg | grep -i ACPI [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI BIOS Error (bug): A valid RSDP was not found (20140424/tbxfroot-211) [0.245347] ACPI: Interpreter disabled. [0.351414] pnp: PnP ACPI: disabled And, looking on the host syststem I see: adriatic:~# ps -ef | grep qemu | grep --color=always acpi 107 3088 1 1 12:38 ?00:01:27 qemu-system-x86_64 -enable-kvm -name cedric.CalvaEDI.COM -S -machine pc-1.1,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 99cfca83-cf28-ce9b-86a4-947debc202b5 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cedric.CalvaEDI.COM.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/disk/by-id/md-name-cedric:root,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/disk/by-id/md-name-belgic:archive,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:65:2d:8e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on Note: ... -no-acpi ... No ACPI, no hotplug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286:
On 19/12/14 14:59, Michael Tokarev wrote: 19.12.2014 16:50, John Hughes wrote: Note: ... -no-acpi ... No ACPI, no hotplug? The linux guest-side module to handle hotplug is acpiphp. I think the name speaks for itself. When I can get my users to stop doing real work to let me play with my toy I'll try with featureacpi//feature. If it works then I contend the bug is the error message -- it would be really helpful if it said You can't hotplug because you haven't got ACPI. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286:
On 19/12/14 15:10, Michael Tokarev wrote: Also, libvirt isn't right (IMHO) to stick with particular machine version (in your case, -M pc-1.1). It is needed for certain guest OS types, for example windows, to keep its activation changes (so that hw should not change). Linux is much more tolerant for hw changes. And even for windows it does not help in all cases (provided you don't use corporate version of this OS where hw changes are not relevant). That's libvirt's translation of my previous Xen configuration. (In fact I think that all of my problems have come about because of libvirt being rather dumb about converting from Xen to KVM). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286:
On 19/12/14 15:53, Michael Tokarev wrote: acpi is not the only possible way. More recent qemu (not pc-1.1 which you used) also has pcie bus, which does support hotplugging without acpi. But you used both pc-1.1 (old non-pcie machine) and no-acpi. Ok, thanks. Still waiting for people to stop work so I can try this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286: Happiness!
Ok, I've added featureacpi//feature and got rid of the pc-1.1 rubbish, now the qemu looks like: qemu-system-x86_64 -enable-kvm -name cedric.CalvaEDI.COM -S -machine pc-i440fx-2.1,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 99cfca83-cf28-ce9b-86a4-947debc202b5 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cedric.CalvaEDI.COM.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/disk/by-id/md-name-cedric:root,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/disk/by-id/md-name-belgic:archive,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:65:2d:8e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on and when I try the virsh attach-device I get: adriatic:~# virsh attach-device cedric.CalvaEDI.COM zz.xml Device attached successfully On the guest I see that /dev/vdc has been created. I get an amazing amount of rubbish in the guest dmesg: [ 872.777513] pci :00:02.0: [1af4:1001] type 00 class 0x01 [ 872.778795] pci :00:02.0: reg 0x10: [io 0x-0x003f] [ 872.778862] pci :00:02.0: reg 0x14: [mem 0x-0x0fff] [ 872.781190] pci :00:02.0: BAR 1: assigned [mem 0xc000-0xcfff] [ 872.781238] pci :00:02.0: BAR 0: assigned [io 0x1000-0x103f] [ 872.781272] pci :00:00.0: no hotplug settings from platform [ 872.781275] pci :00:00.0: using default PCI settings [ 872.781326] pci :00:01.0: no hotplug settings from platform [ 872.781328] pci :00:01.0: using default PCI settings [ 872.781378] ata_piix :00:01.1: no hotplug settings from platform [ 872.781380] ata_piix :00:01.1: using default PCI settings [ 872.781429] uhci_hcd :00:01.2: no hotplug settings from platform [ 872.781432] uhci_hcd :00:01.2: using default PCI settings [ 872.781533] piix4_smbus :00:01.3: no hotplug settings from platform [ 872.781537] piix4_smbus :00:01.3: using default PCI settings [ 872.781606] virtio-pci :00:03.0: no hotplug settings from platform [ 872.781610] virtio-pci :00:03.0: using default PCI settings [ 872.781677] virtio-pci :00:04.0: no hotplug settings from platform [ 872.781680] virtio-pci :00:04.0: using default PCI settings [ 872.781746] virtio-pci :00:05.0: no hotplug settings from platform [ 872.781749] virtio-pci :00:05.0: using default PCI settings [ 872.781815] virtio-pci :00:07.0: no hotplug settings from platform [ 872.781818] virtio-pci :00:07.0: using default PCI settings [ 872.781885] pci :00:02.0: no hotplug settings from platform [ 872.781888] pci :00:02.0: using default PCI settings [ 872.782255] virtio-pci :00:02.0: enabling device ( - 0003) [ 872.833568] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 [ 872.836572] virtio-pci :00:02.0: irq 47 for MSI/MSI-X [ 872.836609] virtio-pci :00:02.0: irq 48 for MSI/MSI-X [ 872.840793] vdc: unknown partition table [ 872.841169] pci :00:00.0: no hotplug settings from platform [ 872.841172] pci :00:00.0: using default PCI settings [ 872.841225] pci :00:01.0: no hotplug settings from platform [ 872.841228] pci :00:01.0: using default PCI settings [ 872.841278] ata_piix :00:01.1: no hotplug settings from platform [ 872.841280] ata_piix :00:01.1: using default PCI settings [ 872.841330] uhci_hcd :00:01.2: no hotplug settings from platform [ 872.841332] uhci_hcd :00:01.2: using default PCI settings [ 872.841381] piix4_smbus :00:01.3: no hotplug settings from platform [ 872.841384] piix4_smbus :00:01.3: using default PCI settings [ 872.841434] virtio-pci :00:03.0: no hotplug settings from platform [ 872.841436] virtio-pci :00:03.0: using default PCI settings [ 872.841510] virtio-pci :00:04.0: no hotplug settings from platform [ 872.841513] virtio-pci :00:04.0: using default PCI settings [ 872.841563] virtio-pci :00:05.0: no hotplug settings from platform [ 872.841566] virtio-pci :00:05.0: using default PCI settings [ 872.841615] virtio-pci :00:07.0: no hotplug settings from platform [ 872.841617] virtio-pci :00:07.0: using default PCI settings [ 872.841666] virtio-pci :00:02.0: no hotplug settings from platform [ 872.841669] virtio-pci :00:02.0: using default PCI settings [ 872.841756] pci :00:00.0: no hotplug settings from platform [
Bug#773286: It looks like a conspiracy between libvirt and kvm
I've restarted my VM and tried again.
This is what I see:
adriatic:~# lsof /dev/md124
adriatic:~# virsh attach-device cedric.CalvaEDI.COM zz.xml
error: Failed to attach device from zz.xml
error: internal error unable to execute QEMU command 'device_add': Bus
'pci.0' does not support hotplugging
adriatic:~# lsof /dev/md124
COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME
kvm 30592 libvirt-qemu 28u BLK 9,124 0x3a3797b 4608551
/dev/md124
adriatic:~#
So libvirt doesn't think the device has been attached, but kvm has
opened it. Nothing seems to have happened in the guest (running 3.16
backport).
Here's what libvirt tried to do:
5302 write(21,
{\execute\:\drive_add\,\arguments\:{\pci_addr\:\dummy\,\opts\:\file=/dev/disk/by-id/md-name-cedric:new,if=none,id=drive-virtio-disk3,format=raw,cache=none\},\id\:\libvirt-7\}\r\n,
176) = 176
5302 read(21, {\id\: \libvirt-7\, \error\: {\class\:
\CommandNotFound\, \desc\: \The command drive_add has not been
found\, \data\: {\name\: \drive_add\}}}\r\n, 1023) = 143
5302 read(21, 0x7f31a4247b3f, 880) = -1 EAGAIN (Resource
temporarily unavailable)
5302 write(21,
{\execute\:\human-monitor-command\,\arguments\:{\command-line\:\drive_add
dummy
file=/dev/disk/by-id/md-name-cedric:new,if=none,id=drive-virtio-disk3,format=raw,cache=none\},\id\:\libvirt-8\}\r\n,
193) = 193
5302 read(21, {\return\: \OK\\r\\n\, \id\: \libvirt-8\}\r\n,
1023) = 41
5302 read(21, 0xa220d9, 982) = -1 EAGAIN (Resource
temporarily unavailable)
5302 write(21,
{\execute\:\device_add\,\arguments\:{\driver\:\virtio-blk-pci\,\scsi\:\off\,\bus\:\pci.0\,\addr\:\0x8\,\drive\:\drive-virtio-disk3\,\id\:\virtio-disk3\},\id\:\libvirt-9\}\r\n,
172) = 172
5302 read(21, {\id\: \libvirt-9\, \error\: {\class\:
\BusNoHotplug\, \desc\: \Bus 'pci.0' does not support
hotplugging\, \data\: {\bus\: \pci.0\}}}\r\n, 1023) = 135
So first it tries drive_add, which is an unknown command.
Then it tries human-monitor-command drive_add, which seems to work,
but has no effect on the guest
Then, even though the human-monitor-command worked it tries
device_add, which fails, possibly because the human-monitor-command
drive_add added something with the same id.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286: qemu-kvm: attemt to attach block device fails Bus 'pci.0' does not support hotplugging
Package: qemu-kvm Version: 1.1.2+dfsg-6+deb7u6 Severity: normal Dear Maintainer, * What led up to the situation? Tried to add a new disk to a running kvm guest * What exactly did you do (or not do) that was effective (or ineffective)? Using the virsh attach-device command I tried to add a new disk * What was the outcome of this action? # virsh attach-device cedric.CalvaEDI.COM zz.xml error: Failed to attach device from zz.xml error: internal error unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging * What outcome did you expect instead? Happiness. The running vm looks like: /usr/bin/kvm -S -M pc-1.1 -enable-kvm -m 8192 -smp 1,sockets=1,cores=1,threads=1 -name cedric.CalvaEDI.COM -uuid 99cfca83-cf28-ce9b-86a4-947debc202b5 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cedric.CalvaEDI.COM.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/disk/by-id/md-name-cedric:root,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/disk/by-id/md-name-belgic:archive,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/dev/disk/by-id/md-name-belgic:backups,if=none,id=drive-virtio-disk2,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk2,id=vir! tio-disk2 -netdev tap,fd=20,id=hostnet0,vhost=on,vhostfd=21 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:65:2d:8e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 Or, in libvirt xml format: domain type='kvm' id='3' namecedric.CalvaEDI.COM/name uuid99cfca83-cf28-ce9b-86a4-947debc202b5/uuid memory unit='KiB'8388608/memory currentMemory unit='KiB'4194304/currentMemory vcpu placement='static'1/vcpu os type arch='x86_64' machine='pc-1.1'hvm/type boot dev='hd'/ /os clock offset='utc' adjustment='reset'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/bin/kvm/emulator disk type='block' device='disk' driver name='qemu' type='raw' cache='none'/ source dev='/dev/disk/by-id/md-name-cedric:root'/ target dev='vda' bus='virtio'/ alias name='virtio-disk0'/ address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /disk disk type='block' device='disk' driver name='qemu' type='raw'/ source dev='/dev/disk/by-id/md-name-belgic:archive'/ target dev='vdb' bus='virtio'/ alias name='virtio-disk1'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /disk disk type='block' device='disk' driver name='qemu' type='raw'/ source dev='/dev/disk/by-id/md-name-belgic:backups'/ target dev='vdc' bus='virtio'/ alias name='virtio-disk2'/ address type='pci' domain='0x' bus='0x00' slot='0x06' function='0x0'/ /disk controller type='usb' index='0' alias name='usb0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller interface type='bridge' mac address='00:16:3e:65:2d:8e'/ source bridge='calvaedi'/ target dev='vnet0'/ model type='virtio'/ alias name='net0'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' source path='/dev/pts/0'/ target port='0'/ alias name='serial0'/ /serial console type='pty' tty='/dev/pts/0' source path='/dev/pts/0'/ target type='serial' port='0'/ alias name='serial0'/ /console memballoon model='virtio' alias name='balloon0'/ address type='pci' domain='0x' bus='0x00' slot='0x07' function='0x0'/ /memballoon /devices seclabel type='none'/ /domain The device I tried to add looks like: disk type='block' device='disk' driver name='qemu' type='raw' cache='none'/ source dev='/dev/disk/by-id/md-name-cedric:new'/ target dev='vdd' bus='virtio'/ /disk The error in libvirtd.log is: 2014-12-16 13:22:50.831+: 5305: error : qemuMonitorJSONCheckError:342 : internal error unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging 2014-12-16 13:22:50.832+: 5305: warning : qemuDomainAttachPciDiskDevice:255 : qemuMonitorAddDevice failed on file=/dev/disk/by-id/md-name-cedric:new,if=none,id=drive-virtio-disk3,format=raw,cache=none (virtio-blk-pci,scsi=off,bus=pci.0,addr=0xb,drive=drive-virtio-disk3,id=virtio-disk3) From strace it seems that the commands
Bug#773286: qemu-kvm: attemt to attach block device fails Bus 'pci.0' does not support hotplugging
Well, it looks like the command has half worked -- lsof shows me that kvm has opened the block device I tried to add. Now how to make it give it up? # lsof /dev/md/cedric\:new COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME kvm 28159 libvirt-qemu 28u BLK 9,124 0x3a3797b 4608551 /dev/md/../md124 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772848: ext3 fs gets ext4_mb_release_inode_pa error, remounted read-only)
It turns out that this is not the first time I've seen this bug, it happened on another VM (on another physical machine). The storage stack is similar: On the host (3.16-0.bpo.2-amd64): mdadm raid (2 SATA disks) LVM On the guest (3.16-0.bpo.2-amd64) LVM2, ext3 filesystem. Dec 10 22:33:24 cedric kernel: [646155.908027] EXT4-fs (dm-1): pa 880103533160: logic 32, phys. 789350252, len 96 Dec 10 22:33:24 cedric kernel: [646155.944885] EXT4-fs error (device dm-1): ext4_mb_release_inode_pa:3773: group 24089, free 34, pa_free 32 Dec 10 22:33:24 cedric kernel: [646155.947737] Aborting journal on device dm-1-8. Dec 10 22:33:25 cedric kernel: [646156.258525] EXT4-fs (dm-1): Remounting filesystem read-only Dec 11 11:20:44 cedric kernel: [692195.795880] EXT4-fs error (device dm-1): ext4_put_super:792: Couldn't clean up the journal ... fsck'd here Dec 11 11:21:48 cedric kernel: [692259.615214] EXT4-fs (dm-1): mounting ext3 file system using the ext4 subsystem Dec 11 11:21:48 cedric kernel: [692259.657377] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro On the same system I'm also seeing: Dec 7 11:16:19 cedric kernel: [346330.080063] EXT4-fs (dm-0): error count since last fsck: 3 Dec 7 11:16:19 cedric kernel: [346330.080070] EXT4-fs (dm-0): initial error at time 1417556618: ext4_mb_release_inode_pa:3773 Dec 7 11:16:19 cedric kernel: [346330.080074] EXT4-fs (dm-0): last error at time 1417596801: ext4_remount:4853 Dec 8 11:18:06 cedric kernel: [432837.600121] EXT4-fs (dm-0): error count since last fsck: 3 Dec 8 11:18:06 cedric kernel: [432837.600170] EXT4-fs (dm-0): initial error at time 1417556618: ext4_mb_release_inode_pa:3773 Dec 8 11:18:06 cedric kernel: [432837.600174] EXT4-fs (dm-0): last error at time 1417596801: ext4_remount:4853 Dec 9 11:19:54 cedric kernel: [519345.120055] EXT4-fs (dm-0): error count since last fsck: 3 Dec 9 11:19:54 cedric kernel: [519345.120093] EXT4-fs (dm-0): initial error at time 1417556618: ext4_mb_release_inode_pa:3773 Dec 9 11:19:54 cedric kernel: [519345.120097] EXT4-fs (dm-0): last error at time 1417596801: ext4_remount:4853 Dec 10 11:21:41 cedric kernel: [605852.640041] EXT4-fs (dm-0): error count since last fsck: 3 Dec 10 11:21:41 cedric kernel: [605852.640076] EXT4-fs (dm-0): initial error at time 1417556618: ext4_mb_release_inode_pa:3773 Dec 10 11:21:41 cedric kernel: [605852.640080] EXT4-fs (dm-0): last error at time 1417596801: ext4_remount:4853 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772848: ext3 fs gets ext4_mb_release_inode_pa error, remounted read-only
Here's what the fsck looked like. No serious damage. root@olympic:~# fsck -y /dev/olympic/olympic-imap fsck from util-linux 2.20.1 e2fsck 1.42.5 (29-Jul-2012) olympic-imap: recovering journal olympic-imap contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +60816 Fix? yes Free blocks count wrong (2898092, counted=2898073). Fix? yes Free inodes count wrong (4789723, counted=4789721). Fix? yes olympic-imap: * FILE SYSTEM WAS MODIFIED * olympic-imap: 453159/5242880 files (24.0% non-contiguous), 7587687/10485760 blocks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772848: linux-image-3.16-0.bpo.2-amd64: ext3 fs gets ext4_mb_release_inode_pa error, remounted read-only
Package: src:linux Version: 3.16.3-2~bpo70+1 Severity: normal Dear Maintainer, I'm running cyrus imapd on a KVM hosted virtual machine with kernel 3.16-0.bpo.2-amd64 Twice (so far) I've seen the error: [957229.875900] EXT4-fs (dm-4): pa 88001f7ff980: logic 0, phys. 9176576, le$ [957229.878640] EXT4-fs error (device dm-4): ext4_mb_release_inode_pa:3773: gro$ [957229.881350] Aborting journal on device dm-4-8. [957229.891273] EXT4-fs (dm-4): Remounting filesystem read-only both times during a cyrus squatter run. fsck only finds minor errors with the filesystem (block count missmatches) and everyting proceeds normally. The filesystem is on a LVM2 logical volume : root@olympic:~# lvdisplay --maps /dev/olympic/olympic-imap --- Logical volume --- LV Path/dev/olympic/olympic-imap LV Nameolympic-imap VG Nameolympic LV UUIDFPLD20-eiVk-qJzG-N4fs-0yhj-wOMT-rdvP7A LV Write Accessread/write LV Creation host, time , LV Status available # open 1 LV Size40.00 GiB Current LE 10240 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:4 --- Segments --- Logical extent 0 to 10239: Typelinear Physical volume /dev/vda2 Physical extents5901 to 16140 The host system is running 3.16-0.bpo.3-amd64 and the disk device passed to the KVM guest is a mdadm raid1 volume: root@baltic:~# virsh dumpxml olympic disk type='block' device='disk' driver name='qemu' type='raw' cache='none'/ source dev='/dev/disk/by-id/md-name-olympic:70a'/ target dev='vda' bus='virtio'/ alias name='virtio-disk0'/ address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /disk /dev/disk/by-id/md-name-olympic:70a: Version : 1.2 Creation Time : Sun Nov 30 13:38:15 2014 Raid Level : raid1 Array Size : 71621696 (68.30 GiB 73.34 GB) Used Dev Size : 71621696 (68.30 GiB 73.34 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Thu Dec 11 18:08:01 2014 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Name : olympic:70a UUID : 4bd87dc8:9f7a4a00:96545c8f:bcd03ea6 Events : 43 Number Major Minor RaidDevice State 0 8 480 active sync /dev/sdd 1 8 1761 active sync /dev/sdl The raid component devices are SCSI. There are no errors in the logs on the host system. -- Package-specific info: ** Version: Linux version 3.16-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.16.3-2~bpo70+1 (2014-09-21) ** Command line: BOOT_IMAGE=/vmlinuz-3.16-0.bpo.2-amd64 root=/dev/mapper/olympic-olympic--root ro console=tty0 console=ttyS0,19200n8 quiet ** Not tainted ** Kernel log: [0.950706] virtio-pci :00:08.0: PCI-APIC IRQ transform: INT A - IRQ 35 [0.952374] SCSI subsystem initialized [0.959904] usbcore: registered new interface driver usbfs [0.959921] usbcore: registered new interface driver hub [0.967119] usbcore: registered new device driver usb [0.969438] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [0.969994] virtio-pci :00:09.0: PCI-APIC IRQ transform: INT A - IRQ 34 [0.975456] uhci_hcd: USB Universal Host Controller Interface driver [0.976063] virtio-pci :00:0a.0: PCI-APIC IRQ transform: INT A - IRQ 34 [0.991641] uhci_hcd :00:01.2: PCI-APIC IRQ transform: INT D - IRQ 35 [0.991745] uhci_hcd :00:01.2: UHCI Host Controller [0.991756] uhci_hcd :00:01.2: new USB bus registered, assigned bus number 1 [0.991794] uhci_hcd :00:01.2: detected 2 ports [0.991931] uhci_hcd :00:01.2: irq 35, io base 0xc180 [0.993252] libata version 3.00 loaded. [0.994803] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [0.994807] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.994809] usb usb1: Product: UHCI Host Controller [0.994811] usb usb1: Manufacturer: Linux 3.16-0.bpo.2-amd64 uhci_hcd [0.994814] usb usb1: SerialNumber: :00:01.2 [0.995546] hub 1-0:1.0: USB hub found [0.995558] hub 1-0:1.0: 2 ports detected [0.997345] ata_piix :00:01.1: version 2.13 [1.007162] scsi0 : ata_piix [1.019756] scsi1 : ata_piix [1.019837] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc1e0 irq 14 [1.019840] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc1e8 irq 15 [1.053210] virtio-pci :00:04.0: irq 40 for MSI/MSI-X [1.053247] virtio-pci :00:04.0: irq 41 for MSI/MSI-X [1.055136] virtio-pci :00:03.0: irq 42 for MSI/MSI-X [1.055173] virtio-pci
Bug#772848: ext3 fs gets ext4_mb_release_inode_pa error, remounted read-only)
Looks superficaly like: http://thread.gmane.org/gmane.comp.file-systems.ext4/43443/focus=43448 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770472: libfreeipmi12: programs using libfreeipmi2 crash the first time after a system boot (on Xen)
On 11/21/2014 10:30 PM, Albert Chu wrote: I imagine the bug is somewhere in xen's memory mapped I/O area if it's happening the first time after boot. Since I'm just using the normal in() and out() calls, not sure there's much I can do. If there is a way to massage freeipmi to not trigger the bug we could work around it, but I have no idea how one might massage it. I'm pretty sure this is a Xen bug -- another datapoint is that I have another machine with the same setup where the Dom0 has spontaneously rebooted 4 times - the problem went away when I tried ipmi-sensors on it. I imagine the reboots were caused by the kernel hitting the same trap. I'll reassign to Xen and do more testing Monday. \ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770472: libfreeipmi12: programs using libfreeipmi2 crash the first time after a system boot
Package: libfreeipmi12 Version: 1.1.5-3 Severity: normal Dear Maintainer, * What led up to the situation? Ran a program linked against libfreeipmi2, for example bmc-config. * What was the outcome of this action? Segfault: [ 304.932148] traps: bmc-config[6848] general protection ip:7fa773b714d8 sp:7bda9070 error:0 in libfreeipmi.so.12.0.3[7fa773a13000+29d000] * What outcome did you expect instead? No segfault? The very very strange part of the bug is that this happens the first time libfreeipmi12 is used after a system boot, not subsequent times. This is on 3.16-0.bpo.2-amd64, as the Dom0 for xen-4.1. The hardware is a Dell Poweredge 840. -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.2-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 Versions of packages libfreeipmi12 depends on: ii freeipmi-common 1.1.5-3 ii libc62.13-38+deb7u6 ii libgcrypt11 1.5.0-5+deb7u2 libfreeipmi12 recommends no packages. libfreeipmi12 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#770472: Acknowledgement (libfreeipmi12: programs using libfreeipmi2 crash the first time after a system boot)
Ok, it's not exactly how I described it, bmc-config (and some other commands) will crash *until* ipmi-sensors is run, at which point it will start working. Until the next reboot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770472: Info received (Bug#770472: Acknowledgement (libfreeipmi12: programs using libfreeipmi2 crash the first time after a system boot))
The bug only happens when running under xen, not on the bare metal. So I guess it's a xen bug really. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762939: nfs-common: /etc/init.d/nfs-common starts #!/bin/bash
Package: nfs-common Version: 1:1.2.8-9 Severity: wishlist Dear Maintainer, /etc/init.d/nfs-common starts #!/bin/bash, but doesn't seem to contain any bashisms. It'd be nice to use /bin/sh. -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 54578 status 1000241 tcp 34482 status -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD=yes NEED_GSSD=yes RPCGSSDOPTS= -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs Domain = calvaedi.com Local-Realm = CALVAEDI.COM [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- olympic:/local /usr/local nfs4sec=krb50 3 -- /proc/mounts -- olympic:/local /usr/local nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.6.107,local_lock=none,addr=192.168.6.67 0 0 olympic.calvaedi.com:/home/john /home/john nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.6.107,local_lock=none,addr=192.168.6.67 0 0 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.4 ii libc6 2.19-10 ii libcap2 1:2.24-4 ii libcomerr2 1.42.12-1 ii libdevmapper1.02.1 2:1.02.88-1 ii libevent-2.0-5 2.0.21-stable-1.1 ii libgssapi-krb5-21.12.1+dfsg-7 ii libk5crypto31.12.1+dfsg-7 ii libkeyutils11.5.9-5 ii libkrb5-3 1.12.1+dfsg-7 ii libmount1 2.20.1-5.8 ii libnfsidmap20.25-5 ii libtirpc1 0.2.4-2.1 ii libwrap07.6.q-25 ii lsb-base4.1+Debian13 ii rpcbind 0.2.1-6 ii ucf 3.0030 Versions of packages nfs-common recommends: ii python 2.7.8-1 Versions of packages nfs-common suggests: pn open-iscsi none pn watchdognone -- Configuration Files: /etc/default/nfs-common changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762937: minissdpd: Please don't use /bin/bash in initscript
Package: minissdpd Version: 1.2.20130907-3 Severity: wishlist Dear Maintainer, /etc/init.d/minissdpd starts: #!/bin/bash It doesn't seem to contain any bashisms so it'd be nicer to use /bin/sh -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages minissdpd depends on: ii libc6 2.19-10 minissdpd recommends no packages. minissdpd 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#762940: grub-pc preinst and postrm scripts use bash
Package: grub-pc Version: 2.02~beta2-11 Severity: wishlist Dear Maintainer, The preinst and postrm scripts use bash, but don't seem to include any bashisms. It'd be nice to use /bin/sh instead. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grub-pc depends on: ii debconf [debconf-2.0] 1.5.53 ii grub-common2.02~beta2-11 ii grub-pc-bin2.02~beta2-11 ii grub2-common 2.02~beta2-11 ii ucf3.0030 grub-pc recommends no packages. grub-pc suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759786: gdm3: multiple displays handled incorrectly (used to work)
Package: gdm3 Version: 3.12.2-2.1 Severity: normal Dear Maintainer, * What led up to the situation? Booted my laptop with external display attached * What was the outcome of this action? Internal display turned off, no login screen on secondary display * What outcome did you expect instead? Preferably login screen mirrored on all displays, at least leave built in display turned on. If I boot the system with the external display disconnected then connect it after the login screen turns on it works 'till I log off. Attempts to change the display layout often leave me with no workable display. This all used to work perfectly. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gdm3 depends on: ii accountsservice 0.6.37-3 ii adduser 3.113+nmu3 ii dconf-cli0.20.0-2 ii dconf-gsettings-backend 0.20.0-2 ii debconf [debconf-2.0]1.5.53 ii gir1.2-gdm3 3.12.2-2.1 ii gnome-session [x-session-manager]3.12.1-3 ii gnome-session-bin3.12.1-3 ii gnome-session-flashback [x-session-manager] 3.8.1-1 ii gnome-settings-daemon3.12.2-1+b1 ii gnome-shell 3.12.2-3 ii gnome-terminal [x-terminal-emulator] 3.12.3-2 ii gsettings-desktop-schemas3.12.2-1 ii libaccountsservice0 0.6.37-3 ii libatk1.0-0 2.12.0-1 ii libaudit11:2.3.7-1 ii libc62.19-10 ii libcairo-gobject21.12.16-3 ii libcairo21.12.16-3 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgdm1 3.12.2-2.1 ii libglib2.0-0 2.40.0-5 ii libglib2.0-bin 2.40.0-5 ii libgtk-3-0 3.12.2-3+b1 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpam-systemd 208-8 ii libpam0g 1.1.8-3.1 ii libpango-1.0-0 1.36.6-1 ii libpangocairo-1.0-0 1.36.6-1 ii librsvg2-common 2.40.3-1 ii libselinux1 2.3-1 ii libsystemd-daemon0 208-8 ii libsystemd-id128-0 208-8 ii libsystemd-journal0 208-8 ii libsystemd-login0208-8 ii libwrap0 7.6.q-25 ii libx11-6 2:1.6.2-3 ii libxau6 1:1.0.8-1 ii libxdmcp61:1.1.1-1 ii libxrandr2 2:1.4.2-1 ii lsb-base 4.1+Debian13 ii metacity [x-window-manager] 1:3.12.0-2 ii policykit-1 0.105-6.1 ii ucf 3.0030 ii x11-common 1:7.7+7 ii x11-xserver-utils7.7+3 ii xterm [x-terminal-emulator] 308-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.12.0-2 ii desktop-base 7.0.3 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii x11-xkb-utils 7.7+1 ii xserver-xephyr 2:1.16.0-1 ii xserver-xorg 1:7.7+7 ii zenity 3.12.1-1.1 Versions of packages gdm3 suggests: ii gnome-orca3.12.2-1 ii libpam-gnome-keyring 3.12.2-1 -- Configuration Files: /etc/gdm3/greeter.gsettings [Errno 2] No such file or directory: u'/etc/gdm3/greeter.gsettings' -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755703: libtirpc1 0.2.4-1 causes rpc.gssd to crash on nfs4 sec=krb5 mount
Package: libtirpc1 Version: 0.2.3-2 Severity: important Dear Maintainer, * What led up to the situation? Upgraded to libtirpc1_0.2.4-1_amd64.deb * What was the outcome of this action? nfs4 sec=krb5 mounts stopped working, rpc.gssd segfaults in libgssapi_krb5 Jul 22 16:22:22 celtic kernel: [ 285.086078] rpc.gssd[1611]: segfault at 6c ip 7f24c8f9e72f sp 7fff60b1df10 error 4 in libgssapi_krb5.so.2.2[7f24c8f8b000+45000 Downgrading to 0.2.3-2 fixes the problem. Note that some non-Debian people seem to have the same problem, e.g. http://forums.opensuse.org/showthread.php/494292-segmentation-fault-OpenSUSE-13-1-when-mounting-nfs4-with-kerberos or: https://bugs.archlinux.org/task/39217 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libtirpc1 depends on: ii libc6 2.19-7 ii libgssglue10.4-2 ii multiarch-support 2.19-7 libtirpc1 recommends no packages. libtirpc1 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#727192: The patch from the gnome bugzilla works for me
I've been running for two days now with the patch from the gnome bugzilla and everything works OK. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727192: This looks like gnome bug 691269 - lock screen with pam_krb5 authentication doesn't update ticket cache
*https://bugzilla.gnome.org/show_bug.cgi?id=691269* https://bugzilla.redhat.com/show_bug.cgi?id=1032154 And Redhat bug***1032154* https://bugzilla.redhat.com/show_bug.cgi?id=1032154 -gdm calls pam_setcred with PAM_ESTABLISH_CRED instead of PAM_REINITIALIZE_CRED during screen unlock https://bugzilla.redhat.com/show_bug.cgi?id=1032154 The gnome bugzilla has a patch. I'll try it.
Bug#745823: libwww-perl: an https request with iso-8859-1 headers, chunked transfer and data with utf8 bit on is corrupted.
On 26/04/14 18:49, John Hughes wrote:
if (ref($content_ref) eq 'CODE') {
my $buf = $content_ref();
$buf = unless defined($buf);
+utf8::downgrade ($buf);
$buf = sprintf %x%s%s%s, length($buf), $CRLF, $buf, $CRLF
if $chunked;
substr($buf, 0, 0) = $req_buf if $req_buf
But that's the wrong place to fix it. The bug is realy in
$socket-syswrite, aka Crypt::SSLeay::Conn::write.
That's where the bug should be fixed.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745823: libwww-perl: an https request with iso-8859-1 headers, chunked transfer and data with utf8 bit on is corrupted.
On 27/04/14 10:35, John Hughes wrote:
But that's the wrong place to fix it. The bug is realy in
$socket-syswrite, aka Crypt::SSLeay::Conn::write.
That's where the bug should be fixed.
This patch fixes it for me.
--- SSLeay.xs.dist 2007-08-13 19:42:33.0 +0200
+++ SSLeay.xs 2014-04-27 13:43:47.0 +0200
@@ -283,20 +283,40 @@
int len;
int offset = 0;
int n;
+ U8* tmpbuf = NULL;
INPUT:
char* buf = SvPV(ST(1), blen);
CODE:
+
+ if (DO_UTF8(ST(1))) {
+ STRLEN tmplen = blen;
+ bool is_utf8 = TRUE;
+ U8 * const result = bytes_from_utf8((const U8*) buf, tmplen, is_utf8);
+ if (is_utf8)
+ croak(Wide character in SSL write (bytes required));
+
+ if (result != (U8*)buf) {
+ tmpbuf = result;
+ buf = (char*) tmpbuf;
+ blen = tmplen;
+ }
+ }
+
if (items 2) {
len = SvOK(ST(2)) ? SvIV(ST(2)) : blen;
if (items 3) {
offset = SvIV(ST(3));
if (offset 0) {
- if (-offset blen)
+ if (-offset blen) {
+ Safefree(tmpbuf);
croak(Offset outside string);
+ }
offset += blen;
}
- else if (offset = blen blen 0)
+ else if (offset = blen blen 0) {
+ Safefree(tmpbuf);
croak(Offset outside string);
+ }
}
if (len blen - offset)
len = blen - offset;
@@ -311,6 +331,7 @@
else {
RETVAL = PL_sv_undef;
}
+ Safefree(tmpbuf);
OUTPUT:
RETVAL
Bug#745823: libwww-perl: an https request with iso-8859-1 headers, chunked transfer and data with utf8 bit on is corrupted.
On 25/04/14 22:01, Niko Tyni wrote:
found 745823 6.06-1
thanks
My pleasure.
Interesting. I can reproduce this on (mostly current) sid with
libwww-perl 6.06-1.
Ah, I was going to test that Monday :-)
Quoting HTTP::Request documentation:
$r-content( $bytes )
Note that the content should be a string of bytes. Strings in
perl can contain characters outside the range of a byte.
The Encode module can be used to turn such strings into a
string of bytes.
So this is not totally unexpected, but the particular failure mode you've
run into is certainly rather horrible.
Possibly the content() method should croak when the UTF8 bit is set?
Interestingly in the my case, although the UTF8 bit is set, the data is
all code points below 256. In fact the first time i ran into the bug
the data was XXX. (Read from a file with binmode :utf8 on).
Maybe something like
if (utf8::is_utf8($data)) {
eval {
utf8::downgrade ($data);
};
croak content not bytes if $@;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745823: libwww-perl: an https request with iso-8859-1 headers, chunked transfer and data with utf8 bit on is corrupted.
On 26/04/14 16:11, John Hughes wrote:
Maybe something like
if (utf8::is_utf8($data)) {
eval {
utf8::downgrade ($data);
};
croak content not bytes if $@;
}
That's ridiculously over the top.
We could just unconditionaly call utf8::downgrade ($data);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745823: libwww-perl: an https request with iso-8859-1 headers, chunked transfer and data with utf8 bit on is corrupted.
On 26/04/14 18:12, John Hughes wrote:
We could just unconditionaly call utf8::downgrade ($data);
Interestingly there is code in HTTP::Message that does that, but we're
going from LWP::Protocol::http::request to
LWP::Protocol::https::Socket-syswrite.
This fixes it for me.
--- /usr/share/perl5/LWP/Protocol/http.pm 2010-01-22 22:44:52.0
+0100
+++ /usr/local/share/perl/5.10.1/LWP/Protocol/http.pm 2014-04-26
18:45:56.0 +0200
@@ -240,6 +240,7 @@
if (ref($content_ref) eq 'CODE') {
my $buf = $content_ref();
$buf = unless defined($buf);
+ utf8::downgrade ($buf);
$buf = sprintf %x%s%s%s, length($buf), $CRLF, $buf, $CRLF
if $chunked;
substr($buf, 0, 0) = $req_buf if $req_buf
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745823: libwww-perl: an https request with iso-8859-1 headers, chunked transfer and data with utf8 bit on is corrupted.
Package: libwww-perl
Version: 5.836-1
Severity: normal
This was horrible to narrow down, but:
1. I'm doing a POST to a HTTPS url
2. Some of my headers containg iso-8859-1 data
3. The body is sent with transfer-encoding: chunked
4. the is_utf8 bit was set on the data (although it happens to be
all in code points 256).
(changing *any* of these conditions makes the bug go away).
The request headers get corrupted, sent in utf-8 instead of iso-8859-1
some of the data doesn't get sent, messing up the chunked counts, or
even trashing the request headers.
The number of missing bytes seems related to the difference in length
between the iso-8859-1 headers and the incorrect utf-8 versions.
For example my request should look like:
POST / HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost:4433
User-Agent: LWP UTF8 BUG
Subject:
Transfer-Encoding: chunked
1
®
0
But it is sent as:
POST / HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost:4433
User-Agent: LWP UTF8 BUG
Subject: ®®®®®®®®®®®®
Transfer-Encoding: chunk0
Here's my test program:
#! /usr/bin/perl
use strict;
use LWP::UserAgent;
my $agent = LWP::UserAgent-new (agent = 'LWP UTF8 BUG');
# Bug only happens if https
my $req = HTTP::Request-new (POST = 'https://localhost:4433');
# Bug only happens if utf8 bit is set on data to be written
my $body = substr (\x{f00f}\xae, 1, 1);
print utf8 bit set\n if utf8::is_utf8($body);
# Bug only happens with chunked content
my $read_body = sub {
my $buf = $body;
$body = ;
$buf
};
$req-content ($read_body);
# Bug only happens if header with iso-8859-1 data
$req-header (Subject = \xae x 12);
my $ret = $agent-request ($req);
# Request sent is malformed - iso-8859-1 data sent as utf-8 and
# bytes missing from output (number of bytes missing equal to
# difference in length between iso-8859-1 and utf-8 representations.
---
-- System Information:
Debian Release: 6.0.7
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libwww-perl depends on:
ii libhtml-parser-perl3.66-1collection of modules that parse H
ii libhtml-tagset-perl3.20-2Data tables pertaining to HTML
ii libhtml-tree-perl 3.23-2Perl module to represent and creat
ii liburi-perl1.54-2module to manipulate and access UR
ii netbase4.45 Basic TCP/IP networking system
ii perl 5.10.1-17squeeze6 Larry Wall's Practical Extraction
Versions of packages libwww-perl recommends:
ii libhtml-format-perl2.04-2format HTML syntax trees into text
ii libio-compress-perl2.024-1 bundle of IO::Compress modules
ii libmailtools-perl 2.06-1Manipulate email in perl programs
ii perl [libio-compress-p 5.10.1-17squeeze6 Larry Wall's Practical Extraction
Versions of packages libwww-perl suggests:
ii libcrypt-ssleay-perl 0.57-2 Support for https protocol in LWP
ii libio-socket-ssl-perl1.33-1+squeeze1 Perl module implementing object or
-- 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#743796: flash-kernel: kirkwood+ should be considered the same as kirkwood
Package: flash-kernel Version: 3.3+deb7u2 Severity: normal Dear Maintainer, * What led up to the situation? Built a custom kernel with make-kpkg * What exactly did you do (or not do) that was effective (or ineffective)? I built it in the directory containing the .git subdirectory * What was the outcome of this action? make-kpkg decided to call the kernel -kirkwood+- instead of xxx-kirkwood-xxx, so flash-kernel considers it's no good for my system. * What outcome did you expect instead? flash-kernel should accept an image called xxx-kirkwood+ as valid for a kirkwood system -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 3.8.0-jh1-kirkwood Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flash-kernel depends on: ii devio1.2-1+b1 ii initramfs-tools 0.109.1 ii linux-base 3.5 flash-kernel recommends no packages. Versions of packages flash-kernel suggests: ii u-boot-tools 2012.04.01-2 -- 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#740933: linux-image-3.13-1-amd64: sony vaio z1 lspci hangs reading /sys/bus/pci/devices/0000:01:00.1/config
Package: src:linux Version: 3.13.5-1 Severity: normal Dear Maintainer, * What led up to the situation? I upgraded from 3.2.0-4-amd64 to 3.13-1-amd64 * What exactly did you do (or not do) that was effective (or ineffective)? tried to see my pci devices with a lspci * What was the outcome of this action? lspci hung trying to read /sys/bus/pci/devices/:01:00.1/config eventualy (some minutes later) it suceeded, at which point the keyboard became inoperable and 100% of the cpu time was in kworker/0:2 * What outcome did you expect instead? nice lcpci report. In dmesg I see: [ 109.460605] ACPI Warning: \_SB_.PCI0.P0P2.DGPU._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95) [ 109.606870] ACPI: \_SB_.PCI0: Bus check notify on hotplug_event_root [ 109.842723] hda-intel :01:00.1: Enabling via VGA-switcheroo (after I type lspci). Oddly :01:00.1 seems to be 01:00.1 Audio device: NVIDIA Corporation GT216 HDMI Audio Controller (rev a1) while running on 3.2.0-4-amd64 -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Sony Corporation product_name: VPCZ11Z9R product_version: J0045VZX chassis_vendor: Sony Corporation chassis_version: N/A bios_vendor: INSYDE bios_version: R3031C3 board_vendor: Sony Corporation board_name: VAIO board_version: N/A ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 02) Subsystem: Sony Corporation Device [104d:905a] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied Kernel driver in use: agpgart-intel 00:01.0 PCI bridge [0604]: Intel Corporation Core Processor PCI Express x16 Root Port [8086:0045] (rev 02) (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- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 6000-6fff Memory behind bridge: d000-d10f Prefetchable memory behind bridge: a000-b1ff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Sony Corporation Device [104d:905a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 43 Region 0: Memory at d140 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at c000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 7078 [size=8] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06) Subsystem: Sony Corporation Device [104d:905a] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 5 Region 0: Memory at d7828100 (64-bit, non-prefetchable) [size=16] Capabilities: access denied 00:19.0 Ethernet controller [0200]: Intel Corporation 82577LC Gigabit Network Connection [8086:10eb] (rev 05) Subsystem: Sony Corporation Device [104d:905a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 41 Region 0: Memory at d780 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at d7825000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 7040 [size=32] Capabilities: access denied Kernel driver in use: e1000e 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series
Bug#740933: Bug exists in 3.12, not in 3.11
I've tried 3.12.8-1 and 3.11.10-1 (the kernels I just happened to have lying around). Same behaviour in 3.12 3.11 seems to work ok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740933: This is what lspci (eventualy) shows on 3.13
Just before the system goes into cpu-bound loops: root@russia:~# lspci -vvv -s :01:00.1 ... long delay... 01:00.1 Audio device: NVIDIA Corporation GT216 HDMI Audio Controller (rev a1) Subsystem: Sony Corporation Device 905a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at d100 (32-bit, non-prefetchable) [size=16K] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 4us, L1 64us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s 256ns, L1 1us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl: ASPM L0s L1 Enabled; RCB 128 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Kernel driver in use: snd_hda_intel I'm also getting: BUG: soft lockup - CPU#2 stuck for 22s ! [kworker/2:1:213] BUG: soft lockup - CPU#3 stuck for 23s ! [migration/3:22] ... similar repeats... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623130: Same behaviour from some French government forms, for example CERFA 13752
A link: https://www.formulaires.modernisation.gouv.fr/gf/showFormulaireSignaletiqueConsulter.do?numCerfa=13752 Where they even say: /Le logiciel Adobe Reader version 8.0 ou + est nécessaire pour visualiser et utiliser ce formulaire. Cliquez *http://get.adobe.com/fr/reader/* pour le télécharger gratuitement. /modernisation.gouv.fr my ass.
Bug#623130: This is poppler bug: https://bugs.freedesktop.org/show_bug.cgi?id=14265
Turns out the so called pdf isn't a pdf at all: I started looking at what it would take to implement javascript. The problem is all the javascript in this pdf does is check the viewer version and if 7.0 loads the XFA plugin. The pdf contains a stream with 600KB of XML starting with template xmlns=http://www.xfa.org/schema/xfa-template/2.1/;. There is a 1500 page specification for XFA at http://partners.adobe.com/public/developer/en/xml/xfa_spec_3_3.pdf Needless to say, at this point I gave up. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730177: The patch fixes the bug for me.
Gdm3 now starts up OK even with /usr/local mounted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730177: Added to Gnome Bugzilla
https://bugzilla.gnome.org/show_bug.cgi?id=721629 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734141: This bug is caused by patch glib-2.22.5-gio-local-stat-selinux-mls-2.patch
That was done to fix RedHat bug https://bugzilla.redhat.com/show_bug.cgi?id=586412 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730177: I can't really understand whats happening.
On 03/01/14 12:05, Simon McVittie wrote:
Could you share the source code of your FUSE filesystem, please?
Thanks, S
Ok, attached.
Run it as root:
perl ./eacces.pl --nonempty --logfile logfile [--allow_other] /usr/local
It makes a bind mount of /usr/local to /tmp/original.$$ then uses fuse
to redirect all access to /usr/local to that bind mount. If you don't
give the allow_other option anybody but root will get EACCES.
It's just a hacked version of the loopback.pl script from the Perl
Fuse package (libfuse-perl)
#!/usr/bin/perl -w
use strict;
use Carp ();
local $SIG{'__WARN__'} = \Carp::cluck;
my $has_threads = 0;
eval {
require threads;
require threads::shared;
1;
} and do {
$has_threads = 1;
threads-import();
threads::shared-import();
};
my $has_Filesys__Statvfs = 0;
eval {
require Filesys::Statvfs;
1;
} and do {
$has_Filesys__Statvfs = 1;
Filesys::Statvfs-import();
};
my $use_lchown = 0;
eval {
require Lchown;
1;
} and do {
$use_lchown = 1;
Lchown-import();
};
my $has_mknod = 0;
eval {
require Unix::Mknod;
1;
} and do {
$has_mknod = 1;
Unix::Mknod-import();
};
# use blib;
use Fuse;
use IO::File;
use POSIX qw(EACCES ENOTDIR ENOENT ENOSYS EEXIST EPERM O_RDONLY O_RDWR O_APPEND O_CREAT setsid);
use Fcntl qw(S_ISBLK S_ISCHR S_ISFIFO SEEK_SET S_ISREG S_ISFIFO S_IMODE S_ISCHR S_ISBLK S_ISSOCK);
use Getopt::Long;
my %extraopts = ( 'threaded' = 0, 'debug' = 0 );
my($use_real_statfs, $pidfile, $logfile);
my $mountopts = ;
my $eacces;
GetOptions(
'use-threads' = sub {
if ($has_threads) {
$extraopts{'threaded'} = 1;
}
},
'debug' = sub {
$extraopts{'debug'} = 1;
},
'nonempty' = sub {
$mountopts .= , if $mountopts;
$mountopts .= nonempty;
},
'allow_other' = sub {
$mountopts .= , if $mountopts;
$mountopts .= allow_other;
},
'use-real-statfs' = \$use_real_statfs,
'pidfile=s' = \$pidfile,
'logfile=s' = \$logfile,
'eacces' = \$eacces,
) || die('Error parsing options');
my $original = /tmp/original.$$;
sub fixup { return $original . shift }
sub x_getattr {
my ($file) = fixup(shift);
my (@list) = lstat($file);
return -$! unless @list;
return -EACCES() if $eacces;
return @list;
}
sub x_getdir {
my ($dirname) = fixup(shift);
unless(opendir(DIRHANDLE,$dirname)) {
return -ENOENT();
}
return -EACCES() if $eacces;
my (@files) = readdir(DIRHANDLE);
closedir(DIRHANDLE);
return (@files, 0);
}
sub x_open {
my ($file) = fixup(shift);
my ($mode) = shift;
return -$! unless sysopen(FILE,$file,$mode);
close(FILE);
return -EACCES() if $eacces;
return 0;
}
sub x_release {
my ($file) = fixup(shift);
return 0;
}
sub x_read {
my ($file,$bufsize,$off) = @_;
my ($rv) = -ENOSYS();
my ($handle) = new IO::File;
return -ENOENT() unless -e ($file = fixup($file));
my ($fsize) = -s $file;
return -ENOSYS() unless open($handle,$file);
if(seek($handle,$off,SEEK_SET)) {
read($handle,$rv,$bufsize);
}
return -EACCES() if $eacces;
return $rv;
}
sub x_read_buf {
my ($file, $size, $off, $bufvec) = @_;
my $rv = 0;
my ($handle) = new IO::File;
return -ENOENT() unless -e ($file = fixup($file));
my ($fsize) = -s $file;
return -ENOSYS() unless open($handle,$file);
if(seek($handle,$off,SEEK_SET)) {
$rv = $bufvec-[0]{'size'} = read($handle,$bufvec-[0]{'mem'},$size);
}
return -EACCES() if $eacces;
return $rv;
}
sub x_write {
my ($file,$buf,$off) = @_;
my ($rv);
return -ENOENT() unless -e ($file = fixup($file));
return -EACCES() if $eacces;
my ($fsize) = -s $file;
return -ENOSYS() unless open(FILE,'+',$file);
if($rv = seek(FILE,$off,SEEK_SET)) {
$rv = print(FILE $buf);
}
$rv = -ENOSYS() unless $rv;
close(FILE);
return length($buf);
}
sub x_write_buf {
my ($file,$off,$bufvec) = @_;
my ($rv);
return -ENOENT() unless -e ($file = fixup($file));
return -EACCES() if $eacces;
my ($fsize) = -s $file;
return -ENOSYS() unless open(FILE,'+',$file);
# If by some chance we get a non-contiguous buffer, or an FD-based
# buffer (or both!), then copy all of it into one contiguous buffer.
if ($#$bufvec 0 || $bufvec-[0]{flags} Fuse::FUSE_BUF_IS_FD()) {
my $single = [ {
flags = 0,
fd = -1,
mem = undef,
pos = 0,
size= Fuse::fuse_buf_size($bufvec),
} ];
Fuse::fuse_buf_copy($single, $bufvec);
$bufvec = $single;
}
if($rv = seek(FILE,$off,SEEK_SET)) {
$rv = print(FILE $bufvec-[0]{mem});
}
$rv = -ENOSYS() unless $rv;
close(FILE);
return $rv;
}
sub err { return (-shift || -$!) }
sub x_readlink { return
Bug#730177: I can't really understand whats happening.
Fed up with strace I've been looking at the gdm3 log files, and I think
I see an earlier difference in the behaviour.
A working session has this in :0-greeter.log
gnome-session[]: DEBUG(+): GsmAutostartApp: started pid:2489
gnome-session[]: DEBUG(+): GsmManager: ending phase APPLICATION
gnome-session[]: DEBUG(+): GsmManager: starting phase RUNNING
gnome-session[]: DEBUG(+): gsm_xsmp_server_start
gnome-session[]: DEBUG(+): GsmPresence: adding idle watch (1) for 300 secs
gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
...
gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[]: DEBUG(+): GsmShell: Connected to the shell
gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
...
gnome-session[]: DEBUG(+): GsmDBusClient:
obj_path=/org/gnome/SessionManager/Presence
interface=org.freedesktop.DBus.Properties method=GetAll
gnome-session[]: DEBUG(+): Detected that screensaver has appeared on the bus
... much exciting looking stuff
gnome-session[]: DEBUG(+): emitting SessionIsActive
But the failed sessions look like:
gnome-session[]: DEBUG(+): GsmAutostartApp: started pid:2626
gnome-session[]: DEBUG(+): GsmManager: ending phase APPLICATION
gnome-session[]: DEBUG(+): GsmManager: starting phase RUNNING
gnome-session[]: DEBUG(+): gsm_xsmp_server_start
gnome-session[]: DEBUG(+): GsmPresence: adding idle watch (1) for 300 secs
gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
...
gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[]: DEBUG(+): GsmShell: Connected to the shell
gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
...
JS ERROR: !!! Exception was: Gio.IOErrorEnum: Permission denied
JS ERROR: !!! message = 'Permission denied'
JS ERROR: !!! fileName = '/usr/share/gnome-shell/js/misc/fileUtils.js'
JS ERROR: !!! lineNumber = '13'
JS ERROR: !!! stack = '0 anonymous(res = [object GObject_Object],
obj = [object GObject_Object])@/usr/share/gnome-shell/js/misc/fileUtils.js:13
'
gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[]: DEBUG(+): emitting SessionIsActive
The failed session jumps over screeds of stuff after the javascript error.
Going back to the strace output I can see this error here:
2638 writev(6,
[{\2036\n\0\326\2\0\0\326\2\0\0\0\0\0\0o\0\0\0\3\0\1\0\1\0\1\0\1\0\0\0\f\0\0\0\36\0\0\0,
40}, {NULL, 0}, {, 0}], 3) = 40
2638 poll([{fd=6, events=POLLIN}], 1, 4294967295) = 1 ([{fd=6,
revents=POLLIN}])
2638 recvfrom(6,
\0016\213\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, 4096, 0,
NULL, NULL) = 32
2638 recvfrom(6, 0x13c1e64, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
2638 recvfrom(6, 0x13c1e64, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
2638 recvfrom(6, 0x13c1e64, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
2638 poll([{fd=5, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6,
events=POLLIN}, {fd=13, events=POLLIN}, {fd=11, events=POLLIN}], 5, 0) = 0
(Timeout)
2638 fstat(2, {st_mode=S_IFREG|0644, st_size=12814, ...}) = 0
2638 lseek(2, 12814, SEEK_SET) = 12814
2638 write(2, JS LOG: Permission denied, 31) = 31
2638 write(2, \n, 1)
(The log message is slightly different because I tried to add a
try/catch around the error in fileUtils.js but I obviously did it in the
wrong place).
The closest EACCES in the strace log is (vastly simplified - I hate
looking at strace for threaded code):
2680 lstat(/usr/share/gdm/greeter/gnome-shell/modes, 0x7faa75efe990) = -1
ENOENT (No such file or directory)
2681 lstat(/usr/local/share/gnome-shell/modes, 0x7faa756fd990) = -1 EACCES
(Permission denied)
2681 openat(AT_FDCWD, /usr/local/share/gnome-shell/modes,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
And the corresponding output in a session that works just has the two
lstats, returning ENOENT and not the openat, so someone thinks the
directory /usr/local/share/gnome-shell/modes exists because it didn't
get an ENOENT when it did an lstat on it, tries to open it and gets all
bent out of shape when the open doesn't work.
But where?
:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730177: I can't really understand whats happening.
On 03/01/14 13:33, John Hughes wrote:
(The log message is slightly different because I tried to add a
try/catch around the error in fileUtils.js but I obviously did it in
the wrong place).
And putting back the original fileUtils.js gets the same behaviour:
gnome-session[2542]: DEBUG(+): GsmAutostartApp: started pid:2599
gnome-session[2542]: DEBUG(+): GsmManager: ending phase APPLICATION
gnome-session[2542]: DEBUG(+): GsmManager: starting phase RUNNING
gnome-session[2542]: DEBUG(+): gsm_xsmp_server_start
gnome-session[2542]: DEBUG(+): GsmPresence: adding idle watch (1) for 300 secs
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient:
obj_path=/org/gnome/SessionManager/Presence
interface=org.freedesktop.DBus.Properties method=GetAll
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient:
obj_path=/org/gnome/SessionManager/Client1
interface=org.freedesktop.DBus.Properties method=GetAll
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmShell: Connected to the shell
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
JS ERROR: !!! Exception was: Gio.IOErrorEnum: Permission denied
JS ERROR: !!! message = 'Permission denied'
JS ERROR: !!! fileName = '/usr/share/gnome-shell/js/misc/fileUtils.js'
JS ERROR: !!! lineNumber = '13'
JS ERROR: !!! stack = '0 anonymous(res = [object GObject_Object],
obj = [object GObject_Object])@/usr/share/gnome-shell/js/misc/fileUtils.js:13
'
gnome-session[2542]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus
interface=org.freedesktop.DBus method=NameOwnerChanged
gnome-session[2542]: DEBUG(+): GsmPresence: setting idle: 1
gnome-session[2542]: DEBUG(+): Updating ConsoleKit idle status: 1
gnome-session[2542]: DEBUG(+): GsmPresence: setting idle: 0
gnome-session[2542]: DEBUG(+): Updating ConsoleKit idle status: 0
gnome-session[2542]: DEBUG(+): GsmPresence: setting non-idle status 0
gnome-session[2542]: DEBUG(+): emitting SessionIsActive
Corresponding strace:
2639 lstat(/usr/local/share/gnome-shell/modes, 0x7f1f898fe990) = -1 EACCES
(Permission denied)
2639 lstat(/usr/share/gnome-shell/modes, 0x7f1f898fe990) = -1 ENOENT (No
such file or directory)
...
2640 openat(AT_FDCWD, /usr/local/share/gnome-shell/modes,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
...
2599 lseek(2, 12814, SEEK_SET) = 12814
2599 write(2, JS ERROR: !!! Exception was: Gio.IOErrorEnum: Permission
denied, 69) = 69
2599 write(2, \n, 1) = 1
2599 fstat(2, {st_mode=S_IFREG|0644, st_size=12884, ...}) = 0
2599 lseek(2, 12884, SEEK_SET) = 12884
2599 write(2, JS ERROR: !!! message = '\Permission denied\', 53) =
53
2599 write(2, \n, 1) = 1
2599 fstat(2, {st_mode=S_IFREG|0644, st_size=12938, ...}) = 0
2599 lseek(2, 12938, SEEK_SET) = 12938
2599 write(2, JS ERROR: !!! fileName =
'\/usr/share/gnome-shell/js/misc/fileUtils.js\', 80) = 80
2599
Bug#730177: The bug is in GLocalFile's query_info_finish, it doesn't throw errors on EACCES.
Via a twisty little list of javascript, all unreadable :-( we arrive at
a call to query_info_async followed by query_info_finish which, when
called to collect the information for a nonexistent file throws an
exception, but when called to collect the information for an
inaccessible file returns a GIName:Gio.Task object.
JS LOG: collectFromDatadirsAsync modes
JS LOG: _collectFromDirectoryAsync [object instance proxy
GType:GLocalFile jsobj@0x7f08f086c438 native@0xa632e0]
JS LOG: _collectFromDirectoryAsync [object instance proxy
GType:GLocalFile jsobj@0x7f08f086c558 native@0xa64fa0]
JS LOG: _collectFromDirectoryAsync [object instance proxy
GType:GLocalFile jsobj@0x7f08f086c5a0 native@0xa64ee0]
JS LOG: try query_info_finish on [object instance proxy GType:GLocalFile
jsobj@0x7f08f086c438 native@0xa632e0]
JS LOG: Caught Error when getting information for file
'/usr/share/gdm/greeter/gnome-shell/modes': No such file or directory
JS LOG: try query_info_finish on [object instance proxy GType:GLocalFile
jsobj@0x7f08f086c558 native@0xa64fa0]
JS LOG: res = [object instance proxy GIName:Gio.Task jsobj@0x7f08f086c990
native@0xa5b900]
JS LOG: listDirAsync [object instance proxy GType:GLocalFile
jsobj@0x7f08f086c558 native@0xa64fa0]
JS LOG: try query_info_finish on [object instance proxy GType:GLocalFile
jsobj@0x7f08f086c5a0 native@0xa64ee0]
JS LOG: Caught Error when getting information for file
'/usr/share/gnome-shell/modes': No such file or directory
JS ERROR: !!! Exception was: Gio.IOErrorEnum: Permission denied
JS ERROR: !!! message = 'Permission denied'
JS ERROR: !!! fileName = '/usr/share/gnome-shell/js/misc/fileUtils.js'
JS ERROR: !!! lineNumber = '14'
JS ERROR: !!! stack = '0 anonymous(res = [object GObject_Object],
obj = [object GObject_Object])@/usr/share/gnome-shell/js/misc/fileUtils.js:14
In /usr/share/gnome-shell/js/misc/fileUtils.js:
function _collectFromDirectoryAsync(dir, loadState) {
function done() {
loadState.numLoading--;
if (loadState.loadedCallback
loadState.numLoading == 0)
loadState.loadedCallback(loadState.data);
}
log (_collectFromDirectoryAsync + dir);
dir.query_info_async('standard::type', Gio.FileQueryInfoFlags.NONE,
GLib.PRIORITY_DEFAULT, null, function(object, res) {
try {
log (try query_info_finish on + object);
object.query_info_finish(res);
log (res = + res);
} catch (e) {
log (Caught + e.message);
if (!e.matches(Gio.IOErrorEnum, Gio.IOErrorEnum.NOT_FOUND))
log(e.message);
done();
return;
}
listDirAsync(dir, Lang.bind(this, function(infos) {
for (let i = 0; i infos.length; i++)
loadState.processFile(dir.get_child(infos[i].get_name()),
infos[i], loadState.data);
done();
}));
});
}
Well, it looks like the error is in gio/glocalfileinfo.c:
GFileInfo *
_g_local_file_info_get (const char *basename,
const char *path,
GFileAttributeMatcher *attribute_matcher,
GFileQueryInfoFlags flags,
GLocalParentFileInfo *parent_info,
GError**error)
{
...
res = g_lstat (path, statbuf);
...
if (res == -1)
{
int errsv = errno;
/* Don't bail out if we get Permission denied (SELinux?) */
if (errsv != EACCES)
{
char *display_name = g_filename_display_name (path);
g_object_unref (info);
g_set_error (error, G_IO_ERROR,
g_io_error_from_errno (errsv),
_(Error when getting information for file '%s': %s),
display_name, g_strerror (errsv));
g_free (display_name);
return NULL;
}
}
Either libglib2 needs to be fixed to not treat EACCES as special or
fileUtils.js in gnome-shell needs to be fixed to understand the strange
return that query_info is returning in this case
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730177: There are two bugs - in glib and gnome-shell
It seems to me that we have a classic situation of two bugs conspiring to ruin our day. 1. For some strange reason glib decides not to tell people about EACCES when they ask for information about a file/directory 2. gnome-shell thinks that just because glib provides it information about a directorty (from an lstat) it can read that directory. We can tickle the second bug by doing something as simple as: # mkdir -p /usr/local/share/gnome-shell/modes # chmod -rx /usr/local/share/gnome-shell/modes Bam! next time gdm3 is started no greeter is displayed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733952: gdm3 doesn't show greeter if started from invoke-rc.d
Package: gdm3 Version: 3.8.4-6 Severity: normal Dear Maintainer, * What led up to the situation? Trying to debug #730177 (gdm3 doesn't show greeter if can't access /usr/local) I did an update-rc.d remove and tried to start gdm3 by invoke-rc.d gdm3 start * What was the outcome of this action? Black screen with arrow cursor * What outcome did you expect instead? Friendly greater screen The greeter log contains *many* lines like: dconf-CRITICAL **: unable to create directory '/run/user/0/dconf': Permission denied. dconf will not work properly. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages gdm3 depends on: ii accountsservice 0.6.34-2 ii adduser 3.113+nmu3 ii dconf-cli0.18.0-1 ii dconf-gsettings-backend 0.18.0-1 ii debconf [debconf-2.0]1.5.52 ii gir1.2-gdm3 3.8.4-6 ii gnome-session [x-session-manager]3.8.4-3 ii gnome-session-bin3.8.4-3 ii gnome-session-flashback [x-session-manager] 3.8.0-1 ii gnome-settings-daemon3.8.5-2 ii gnome-shell 3.8.4-5 ii gnome-terminal [x-terminal-emulator] 3.10.1-1 ii gsettings-desktop-schemas3.8.2-2 ii libaccountsservice0 0.6.34-2 ii libatk1.0-0 2.10.0-2 ii libaudit11:2.3.2-2 ii libc62.17-97 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libgdm1 3.8.4-6 ii libglib2.0-0 2.36.4-1 ii libglib2.0-bin 2.36.4-1 ii libgtk-3-0 3.8.6-1 ii libpam-modules 1.1.3-10 ii libpam-runtime 1.1.3-10 ii libpam-systemd 204-5 ii libpam0g 1.1.3-10 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii librsvg2-common 2.40.0-1 ii libselinux1 2.2.1-1 ii libwrap0 7.6.q-24 ii libx11-6 2:1.6.2-1 ii libxau6 1:1.0.8-1 ii libxdmcp61:1.1.1-1 ii libxrandr2 2:1.4.1-1 ii lsb-base 4.1+Debian12 ii metacity [x-window-manager] 1:2.34.13-1 ii upower 0.9.23-2+b1 ii x11-common 1:7.7+4 ii x11-xserver-utils7.7+1 ii xterm [x-terminal-emulator] 300-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.10.2-1 ii desktop-base 7.0.3 ii gnome-icon-theme 3.10.0-1 ii gnome-icon-theme-symbolic 3.10.1-1 ii x11-xkb-utils 7.7~1 ii xserver-xephyr 2:1.14.5-1 ii xserver-xorg 1:7.7+4 ii zenity 3.8.0-1 Versions of packages gdm3 suggests: pn gnome-orcanone ii libpam-gnome-keyring 3.8.2-2 -- Configuration Files: /etc/gdm3/daemon.conf changed: [daemon] [security] [xdmcp] [greeter] [chooser] [debug] Enable = true -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730177: I can't really understand whats happening.
The only difference I can see between the sessions that work (with
/usr/local unmounted) and those that fail (with /usr/local nfs mounted,
so all accesses get EACCES) is that when things go well I see the message:
gnome-session[2575]: DEBUG(+): Detected that screensaver has appeared on the bus
But when things fail that message is never printed.
The Detected message seems to be printed in response to
[/usr/bin/dbus-launch, --exit-with-session,
/usr/bin/gnome-session, --autostart,
/usr/share/gdm/greeter/autostart, --debug] receiving this message:
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{l\4\1\1-\0\0\0f\0\0\0\211\0\0\0\1\1o\0\25\0\0\0/org/freedesktop/DBus\0\0\0\2\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0\3\1s\0\20\0\0\0NameOwnerChanged\0\0\0\0\0\0\0\0\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0\10\1g\0\3sss\0\0\0\0\0\0\0\0\25\0\0\0org.gnome.ScreenSaver\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0:1.7\0...,
2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 205
This message was sent by a child of gdm3:
sendmsg(12, {msg_name(0)=NULL,
msg_iov(2)=[{l\4\1\1-\0\0\0f\0\0\0\211\0\0\0\1\1o\0\25\0\0\0/org/freedesktop/DBus\0\0\0\2\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0\3\1s\0\20\0\0\0NameOwnerChanged\0\0\0\0\0\0\0\0\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0\10\1g\0\3sss\0\0\0\0\0\0\0\0,
160}, {\25\0\0\0org.gnome.ScreenSaver\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0:1.7\0, 45}],
msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 205
But basically I get lost in a twisty little maze of sendmsgs all alike.
I've tried debugging the problem using fuse, and can replicate it by
simply making /usr/local a fuse filesystem that returns EACCES for all
operations.
Any ideas about how to go forwards?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730177: Well, the problem isn't the home directory, it's /usr/local
On 12/28/2013 12:39 AM, Simon McVittie wrote: Why can't the greeter read files in /usr/local, though? Aren't they 0644/0755? Because the filesystem is mounted with sec=krb5 and the Debian-gdm user doesn't have a kerberos ticket. I guess it's partly a misconfiguration on my part, I'll check whether making the filesystem read-only and using the squash_all parameter on the export fixes the problem. I'll be able to look at this Monday. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730177: It seems to be something to do with nfs4/krb5/autofs
In my attempts to debug this I managed to break my autofs configuration and, bizzarely, gdm3 started working again. When I fixed autofs then I get back to the situation where gdm3 hangs. I'll try to work out the differences between the situation with the home directory unmounted (gdm3 works) and mounted (gdm3 fails). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730177: gdm3 gets very upset when it can't access the home directory
The difference between the two cases seems to be this: 1. when my home directory is *not* mounted: gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/gnome/SessionManager/Presence interface=org.freedesktop.DBus.Properties method=GetAll gnome-session[]: DEBUG(+): Detected that screensaver has appeared on the bus gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged gnome-session[]: DEBUG(+): GsmXsmpServer: accept_ice_connection() gnome-session[]: DEBUG(+): GsmXsmpServer: auth_ice_connection() gnome-session[]: DEBUG(+): GsmXSMPClient: Setting up new connection gnome-session[]: DEBUG(+): GsmXSMPClient: New client '0xaf08b0 []' And the login screen is displayed 2. When my home directory is mounted: gnome-session[]: DEBUG(+): GsmDBusClient: obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameOwnerChanged JS ERROR: !!! Exception was: Gio.IOErrorEnum: Permission denied JS ERROR: !!! message = 'Permission denied' JS ERROR: !!! fileName = '/usr/share/gnome-shell/js/misc/fileUtils.js' JS ERROR: !!! lineNumber = '13' JS ERROR: !!! stack = '0 anonymous(res = [object GObject_Object], obj = [object GObject_Object])@/usr/share/gnome-shell/js/misc/fileUtils.js:13 ' And no login screen is displayed. I'd guess that gdm3 is perplexed that, even though running as root, it can't access files in my home directory. (Spelling checked doesn't like GsmDbusClient, proposes as replacements: Aguascalientes, Masculinity, Musclebound).
Bug#730177: Well, the problem isn't the home directory, it's /usr/local
I ran gdm3 under strace both with and without the network connected. When the network is not connected (so no nfs directories are mounted) gdm3 shows the greeter screen. When the network *is* connected, so the nfs directories are mounted the greeter screen is not showing. I examined the strace output, expecting to see it having problems with my home directory, but no, there were many EACCES errors accessing /usr/local. I'd forgotten that /usr/local was also nfs mounted. I've removed /usr/local/ from the fstab and now the gdm greeter works even when my home directory is nfs mounted. At the moment I can't be sure what is the exact problem (The strace files are insanely large, and I think they don't capture everyting), I'll keep looking.
Bug#731887: systemd: Lid close on laptop doesn't suspend
On 12/10/2013 11:37 PM, Michael Biebl wrote: Please post the output of systemd-inhibit --list before you do such a lid-close. # systemd-inhibit --list Who: john (UID 1000/john, PID 3736/gnome-settings-) What: sleep Why: GNOME needs to lock the screen Mode: delay Who: john (UID 1000/john, PID 3736/gnome-settings-) What: handle-power-key:handle-suspend-key:handle-hibernate-key Why: GNOME handling keypresses Mode: block Who: GNOME Shell (UID 1000/john, PID 3799/gnome-shell) What: sleep Why: GNOME needs to lock the screen Mode: delay Who: Telepathy (UID 1000/john, PID 3857/mission-control) What: shutdown:sleep Why: Disconnecting IM accounts before suspend/shutdown... Mode: delay 4 inhibitors listed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731884: Problem is in detection of partition table after mdadm volume created
What seems to be happening: In the cases where the system boots correctly the mdadm volume is created then a partition table is found. In the cases where the system fails to boot the mdadm volume is created then the kernel says md126: unknown partition table. Running the kernel without the quiet option makes the problem happen less frequently. Some kind of delay needed between creating the volume and checking for the partition table? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731887: systemd: Lid close on laptop doesn't suspend
On 12/11/2013 10:49 AM, Michael Biebl wrote: Have you booted with systemd being your PID 1 or do you still use sysvinit? I'm a stick in the mud. Ok, trying with init=/bin/systemd It slept. It woke up. Log [ 94.784260] ACPI: \_SB_.PCI0: Bus check notify on _handle_hotplug_event_root [ 99.805757] PM: Syncing filesystems ... done. [ 99.832169] PM: Preparing system for mem sleep [ 99.832342] (NULL device *): firmware: agent loaded rtl_nic/rtl8168e-3.fw into memory [ 99.832381] (NULL device *): firmware: agent loaded intel-ucode/06-2a-07 into memory [ 99.832552] (NULL device *): firmware: agent loaded iwlwifi-6000g2b-6.ucode into memory [ 99.832565] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 99.834087] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 99.835218] PM: Entering mem sleep [ 99.835296] Suspending console(s) (use no_console_suspend to debug) [ 99.835472] wlan0: deauthenticating from c4:01:7c:09:c3:dc by local choice (reason=3) [ 99.869076] cfg80211: Calling CRDA to update world regulatory domain [ 99.869133] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 99.869136] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 99.869206] sd 0:0:0:0: [sda] Stopping disk [ 99.869208] sd 1:0:0:0: [sdb] Stopping disk [ 99.871180] option1 ttyUSB2: option_instat_callback: error -2 [ 99.873325] option1 ttyUSB0: option_instat_callback: error -2 [ 100.010881] mei_me :00:16.0: suspend [ 100.190578] PM: suspend of devices complete after 354.688 msecs [ 100.190841] PM: late suspend of devices complete after 0.259 msecs [ 100.206599] xhci_hcd :04:00.0: System wakeup enabled by ACPI [ 100.238715] ehci-pci :00:1d.0: System wakeup enabled by ACPI [ 100.254929] ehci-pci :00:1a.0: System wakeup enabled by ACPI [ 100.286614] PM: noirq suspend of devices complete after 95.654 msecs [ 100.287054] ACPI: Preparing to enter system sleep state S3 [ 100.288342] PM: Saving platform NVS memory [ 100.289285] Disabling non-boot CPUs ... [ 100.291310] smpboot: CPU 1 is now offline [ 100.394701] smpboot: CPU 2 is now offline [ 100.396384] smpboot: CPU 3 is now offline [ 100.397700] ACPI: Low-level resume complete [ 100.397739] PM: Restoring platform NVS memory [ 100.398205] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x29 [ 100.398222] Enabling non-boot CPUs ... [ 100.398290] smpboot: Booting Node 0 Processor 1 APIC 0x1 [ 100.411582] Intel pstate controlling: cpu 1 [ 100.411692] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x14 [ 100.412223] microcode: CPU1 updated to revision 0x29, date = 2013-06-12 [ 100.412226] CPU1 is up [ 100.412279] smpboot: Booting Node 0 Processor 2 APIC 0x2 [ 100.425567] Intel pstate controlling: cpu 2 [ 100.425608] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x14 [ 100.425899] microcode: CPU2 updated to revision 0x29, date = 2013-06-12 [ 100.425901] CPU2 is up [ 100.425957] smpboot: Booting Node 0 Processor 3 APIC 0x3 [ 100.439241] Intel pstate controlling: cpu 3 [ 100.439281] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x29 [ 100.439284] CPU3 is up [ 100.442515] ACPI: Waking up from system sleep state S3 [ 100.953070] ehci-pci :00:1a.0: System wakeup disabled by ACPI [ 100.985093] ehci-pci :00:1d.0: System wakeup disabled by ACPI [ 101.049194] xhci_hcd :04:00.0: System wakeup disabled by ACPI [ 101.065335] PM: noirq resume of devices complete after 160.069 msecs [ 101.065564] PM: early resume of devices complete after 0.182 msecs [ 101.065606] i915 :00:02.0: setting latency timer to 64 [ 101.065659] mei_me :00:16.0: irq 49 for MSI/MSI-X [ 101.065761] ehci-pci :00:1a.0: setting latency timer to 64 [ 101.065822] snd_hda_intel :00:1b.0: irq 51 for MSI/MSI-X [ 101.065898] ahci :00:1f.2: setting latency timer to 64 [ 101.065936] ehci-pci :00:1d.0: setting latency timer to 64 [ 101.085256] [drm] Wrong MCH_SSKPD value: 0x16040307 [ 101.085257] [drm] This can cause pipe underruns and display issues. [ 101.085257] [drm] Please upgrade your BIOS to fix this. [ 101.189316] tpm_tis 00:09: TPM is disabled/deactivated (0x7) [ 101.198926] r8169 :05:00.0 eth0: link down [ 101.389552] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 101.389582] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 101.391259] ata1.00: configured for UDMA/133 [ 101.391329] sd 0:0:0:0: [sda] Starting disk [ 101.391545] ata2.00: configured for UDMA/133 [ 101.391617] sd 1:0:0:0: [sdb] Starting disk [ 101.726840] iwlwifi :02:00.0: L1 Enabled; Disabling L0S [ 101.733758] iwlwifi :02:00.0: Radio type=0x1-0x2-0x0 [ 101.825859] PM: resume of devices complete after 759.365 msecs [ 101.826021] PM: Finishing wakeup. [ 101.826033] Restarting tasks ... done. [ 101.826834] video LNXVIDEO:09: Restoring backlight state [ 101.834875] cfg80211: World regulatory domain updated: [ 101.834879] cfg80211: (start_freq - end_freq @
Bug#731887: systemd: Lid close on laptop doesn't suspend
On 12/11/2013 10:49 AM, Michael Biebl wrote: Have you booted with systemd being your PID 1 or do you still use sysvinit? Ok, with init=/bin/systemd it seems to work reliably. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731884: Problem is order of partitions seen by mdadm
When the system works it builds the devices from sda and sdb. When it fails its because it tries to build a container from sda3 and sdb. To mdadm sda3 looks like it is part of an imsm container, but it's not. It isn't even a partition! sda and sdb contain a imsm raid0 device that is partitioned. Since sda3 extends beyond the end of sda it gets truncated by the kernel, and if mdadm examines it it looks like it is part of the imsm device. My problem can be fixed by adding : DEVICE /dev/sda /dev/sdb containers to the mdadm.conf (and rebuilding the initramfs). I guess the bug report should be reassigned to mdadm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731884: initramfs-tools: randomly /dev/disk/by-uuid doesn't exits, making boot from crypt partition fail
Package: initramfs-tools Version: 0.115 Severity: normal Dear Maintainer, * What led up to the situation? Upgraded * What exactly did you do (or not do) that was effective (or ineffective)? Rebooted * What was the outcome of this action? Fell into busybox shell because couldn't find crypto partition UUID=xxx * What outcome did you expect instead? Prompt for passphrase, boot. Sometimes it works - maybe a timing problem. The configuration is rather complicated, lvm on cryptsetup on a partition on an imsm raid0, but until last update it was working reliably. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 21M Dec 10 21:01 /boot/initrd.img-3.10-3-amd64 -rw-r--r-- 1 root root 23M Dec 10 21:18 /boot/initrd.img-3.11-2-amd64 -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11-2-amd64 root=/dev/mapper/coal-root ro quiet nosplash -- resume RESUME=/dev/mapper/coal-swap -- /proc/filesystems ext3 ext2 ext4 fuseblk -- lsmod Module Size Used by parport_pc 26300 0 ppdev 12686 0 lp 17074 0 parport35749 3 lp,ppdev,parport_pc rfcomm 36903 12 bnep 17431 2 cpufreq_stats 12777 0 cpufreq_powersave 12454 0 cpufreq_userspace 12525 0 cpufreq_conservative14184 0 binfmt_misc16949 1 uinput 17372 1 fuse 78616 1 loop 26609 0 joydev 17063 0 iTCO_wdt 12831 0 iTCO_vendor_support12649 1 iTCO_wdt snd_hda_codec_hdmi 35769 1 snd_hda_codec_realtek41059 1 qmi_wwan 20971 0 x86_pkg_temp_thermal12951 0 uvcvideo 78960 0 coretemp 12854 0 cdc_wdm17383 1 qmi_wwan usbnet 26701 1 qmi_wwan videobuf2_vmalloc 12816 1 uvcvideo kvm_intel 130397 0 videobuf2_memops 12519 1 videobuf2_vmalloc videobuf2_core 35029 1 uvcvideo snd_hda_intel 39672 2 kvm 354353 1 kvm_intel tpm_infineon 16844 0 videodev 105100 2 uvcvideo,videobuf2_core snd_hda_codec 142551 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel qcserial 12500 0 option 41320 0 media 18303 2 uvcvideo,videodev snd_hwdep 13148 1 snd_hda_codec snd_pcm_oss44847 0 arc4 12536 2 usb_wwan 12998 2 qcserial,option usbserial 28098 3 qcserial,option,usb_wwan snd_mixer_oss 22042 1 snd_pcm_oss snd_pcm84096 4 snd_pcm_oss,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel microcode 30309 0 btusb 21440 0 snd_page_alloc 17114 2 snd_pcm,snd_hda_intel bluetooth 215917 22 bnep,btusb,rfcomm snd_seq_midi 12848 0 iwldvm131415 0 psmouse82028 0 snd_seq_midi_event 13316 1 snd_seq_midi i2c_i801 16965 0 rtsx_pci_ms12802 0 snd_rawmidi26805 1 snd_seq_midi serio_raw 12849 0 pcspkr 12595 0 mac80211 416244 1 iwldvm snd_seq48834 2 snd_seq_midi_event,snd_seq_midi memstick 13696 1 rtsx_pci_ms lpc_ich20768 0 snd_seq_device 13132 3 snd_seq,snd_rawmidi,snd_seq_midi snd_timer 26614 2 snd_pcm,snd_seq iwlwifi83801 1 iwldvm snd60869 16 snd_hda_codec_realtek,snd_pcm_oss,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_mixer_oss cfg80211 377915 3 iwlwifi,mac80211,iwldvm soundcore 13026 1 snd sony_laptop44599 0 rfkill 18978 6 cfg80211,sony_laptop,bluetooth battery13101 0 tpm_tis17273 0 evdev 17445 21 tpm22123 2 tpm_tis,tpm_infineon tpm_bios 17465 1 tpm ac 12668 0 mperf 12411 0 processor 28326 0 mei_me 13400 0 mei49890 1 mei_me ext4 457329 3 crc16 12343 2 ext4,bluetooth mbcache13034 1 ext4 jbd2 82560 1 ext4 sha256_generic 16804 2 dm_crypt 22291 1 dm_mod 71812 12 dm_crypt raid0 17001 1 md_mod103700 4 raid0 sg 29971 0 sd_mod 44300 2 crc_t10dif 12348 1 sd_mod rtsx_pci_sdmmc 17169 0 crc32c_intel 21809 0 mmc_core 89874 1 rtsx_pci_sdmmc ghash_clmulni_intel13021 0 aesni_intel50772 3 aes_x86_64
Bug#731887: systemd: Lid close on laptop doesn't suspend
Package: systemd Version: 204-5 Severity: normal Dear Maintainer, * What exactly did you do (or not do) that was effective (or ineffective)? Closed laptop lid * What was the outcome of this action? Nothing * What outcome did you expect instead? Suspend. I see in dmesg: [ 675.056857] ACPI: \_SB_.PCI0: Bus check notify on _handle_hotplug_event_root [ 675.057065] systemd-logind[3255]: Lid closed. [ 675.057209] systemd-logind[3255]: Suspending... [ 675.057380] systemd-logind[3255]: Removed session 1. [ 675.135870] systemd-logind[3255]: New session c1 of user john. [ 676.658958] systemd-logind[3255]: Removed session c1. [ 680.066006] systemd-logind[3255]: Delay lock is active but inhibitor timeout is reached. [ 680.070792] systemd-logind[3255]: Failed to send delayed message: Launch helper exited with unknown return code 1 [ 914.776413] ACPI: \_SB_.PCI0: Bus check notify on _handle_hotplug_event_root [ 914.776644] systemd-logind[3255]: Lid opened. This is on a Sony Vaio Z2 -- Package-specific info: -- systemd-delta: -- 0 overridden configuration files found. -- Contents of /var/lib/systemd/deb-systemd-helper-enabled: -- == /var/lib/systemd/deb-systemd-helper-enabled/pcscd.service.dsh-also == /etc/systemd/system/sockets.target.wants/pcscd.socket == /var/lib/systemd/deb-systemd-helper-enabled/accounts-daemon.service.dsh-also == /etc/systemd/system/graphical.target.wants/accounts-daemon.service == /var/lib/systemd/deb-systemd-helper-enabled/avahi-daemon.service.dsh-also == /etc/systemd/system/multi-user.target.wants/avahi-daemon.service /etc/systemd/system/sockets.target.wants/avahi-daemon.socket /etc/systemd/system/dbus-org.freedesktop.Avahi.service == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/avahi-daemon.service == == /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also == /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service == /var/lib/systemd/deb-systemd-helper-enabled/pcscd.socket.dsh-also == /etc/systemd/system/sockets.target.wants/pcscd.socket == /var/lib/systemd/deb-systemd-helper-enabled/avahi-daemon.socket.dsh-also == /etc/systemd/system/sockets.target.wants/avahi-daemon.socket == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/avahi-daemon.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/pcscd.socket == == /var/lib/systemd/deb-systemd-helper-enabled/syslog.service == == /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.Avahi.service == == /var/lib/systemd/deb-systemd-helper-enabled/graphical.target.wants/accounts-daemon.service == -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii initscripts 2.88dsf-43 ii libacl1 2.2.52-1 ii libaudit11:2.3.2-2 ii libc62.17-97 ii libcap2 1:2.22-1.2 ii libcryptsetup4 2:1.6.1-1 ii libdbus-1-3 1.6.18-2 ii libgcrypt11 1.5.3-2 ii libkmod2 9-3 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.3-10 ii libselinux1 2.2.1-1 ii libsystemd-daemon0 204-5 ii libsystemd-journal0 204-5 ii libsystemd-login0204-5 ii libudev1 204-5 ii libwrap0 7.6.q-24 ii udev 204-5 ii util-linux 2.20.1-5.5 Versions of packages systemd recommends: ii libpam-systemd 204-5 Versions of packages systemd suggests: pn systemd-ui none -- 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#730177: What can I do to help debug this one?
The problem persists. A clue? We use kerberos for login, with nfs4 home directories auto-mounted. Help! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729567: Debian bug #726676: linux-image-3.10-3-amd64: TCP packet loss when using proxy ARP IP addresses
On 11/24/2013 01:52 AM, Ben Hutchings wrote: On Sat, 2013-11-23 at 16:29 -0800, Andris Kalnozols wrote: Package: src:linux Version: 3.10.11-1 Please close bug report #726676 as the observed problem had nothing to do with proxy-arp. The correct diagnosis was provided by John Hughes who filed bug report #729567. [...] This is still a bug, even if you can work around it by disabling GRO. Ben. Yes, but Andris confirms that bug 726676 and bug 729567 should be merged. I'll do it tomorrow. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726676: Debian bug #726676: linux-image-3.10-3-amd64: TCP packet loss when using proxy ARP IP addresses
Hi Andris, I've run across a bug that looks very like the one you reported, but my analysis is rather different. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729567 As far as I can tell the problem I'm seeing is: The LAN NIC on the machine running the OpenVPN server has the generic-receive-offload (GRO) option set, so it combines TCP segments coming from the LAN and destined for one of the OpenVPN clients into one big segment. However this segment is bigger than the MTU on the OpenVPN tunnel, so when it gets routed out to the tunnel it gets split up into smaller segments. But the kernel seems to forget to calculate the TCP checksum for these segments, so when they are received by the OpenVPN client they are discarded, and have to be retransmitted one by one. Do you have GRO set on the LAN interface of your OpenVPN server? Does turning it off make your system work better? -- John Hughes, Atlantic Technologies. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726676: Maybe this has some connection to bug 729567
But my problem seems to have nothing to do with ARP. Do my traces look like yours? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
