Bug#933294: Kernel quirks on QNAP TS-109 (Marvell orion)
Le 02/08/2019 à 10:58, Arnaud Patard (Rtp) a écrit : > Hi, > > Martin Michlmayr writes: > >> * Arnaud Patard [2019-07-29 14:45]: >>> As promised, please fix the updated patch. Please note that there are 2 >> Can you submit it upstream for review, or if you have already, send us >> a link. > Sorry for the delay. I was waiting for some feedback before sending and > then got busy with other stuff. I've now sent it: > https://marc.info/?l=linux-netdev=156473570707976=2. > > Arnaud That's awesome, thank you Arnaud :) About the qcontrol-related issues, I have a conjecture you guys might be experienced enough to debunk (or confirm), I also noticed that the TS-109 fails to shutdown properly, either using systemd or sysvinit (After "[ 243.405182] qnap_tsx09_power_off: triggering power-off...", it panic()'s with systemd getting killed, and stalls without powering off, and with sysvinit it simply stalls) After some quick research, it seems that both qcontrol related stuff (buzzer, leds, ...) and shutting down are handled by the NAS PIC, available through proprietary kernel stuff on stock QNAP kernel and through GPIO / ttyS1,19200n8 on vanilla ones. I get some: ---8<--- [ 44.325898] synth uevent: /gpiochip0: failed to send uevent [ 44.325949] gpio gpiochip0: uevent: failed to send synthetic uevent ---8<--- In dmesg during boot, which I suspect means that something is wrong in GPIO / PIC communication. I tried to replicate the way Linux shuts the NAS down (send 'A' over ttyS1,19200n8) and nothing happened, neigher shutdown or line echo. Are there known ways for the PIC access to be broken, is this specific to my NAS (but QTS seems to work fine with it) or maybe a regression specific to TS-X09 ? Thanks for your time. -- Matthieu CERDA
Bug#933298: qcontrold systemd unit possible typo
Package: qcontrol Version: 0.5.6-4~bpo9+1 Severity: important Tags: patch Hello maintainer! There seems to be a small typo, related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781886, in the qcontrold systemd unit. The unit depends on: /dev/input/by-path/platform-gpio_keys-event The actual file to watch for seems to be: /dev/input/by-path/platform-gpio-keys-event Here's a patch: ---8<--- --- a/lib/systemd/system/qcontrold.service 2018-05-27 12:00:11.0 +0200 +++ b/etc/systemd/system/qcontrold.service 2019-07-28 21:22:34.048521392 +0200 @@ -1,7 +1,7 @@ [Unit] Description=qcontrold -Requires=dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device -After=dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device +Requires=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device +After=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device # If the config file is there, we assume qcontrol works on this machine. ConditionPathExists=/etc/qcontrol.conf ---8<--- Thank you! -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: armel (armv5tel) Kernel: Linux 4.19.0-0.bpo.5-marvell Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qcontrol depends on: ii libc62.24-11+deb9u4 ii liblua5.1-0 5.1.5-8.1+b2 ii udev 232-25+deb9u11 qcontrol recommends no packages. qcontrol suggests no packages. -- no debconf information
Bug#933294: qcontrol fails to do anything on QNAP TS-109
Package: qcontrol Version: 0.5.6-4~bpo9+1 Severity: important Greetings, package maintainer! I am running a QNAP TS-109 NAS on Debian, and post installation I noticed that qcontrol seemed not to work properly: the NAS does not beep post-boot, and the status led stays red/green blinking. Trying to use qcontrol directly outputs no error, but does nothing: ---8<--- root@vault:~# qcontrol --direct statusled greenon Register evdev on /dev/input/by-path/platform-gpio-keys-event confdir: loading from /etc/qcontrol.d... (no led change) root@vault:~# qcontrol --direct buzzer short Register evdev on /dev/input/by-path/platform-gpio-keys-event confdir: loading from /etc/qcontrol.d... (no buzzer sound) ---8<--- It looks like it might be a kernel-related problem, as I can see in dmesg: ---8<--- root@vault:~# dmesg|grep gpio [ 21.616406] synth uevent: /gpiochip0: failed to send uevent [ 21.616455] gpio gpiochip0: uevent: failed to send synthetic uevent [ 31.732294] input: gpio-keys as /devices/platform/gpio-keys/input/input0 [ 34.725122] synth uevent: /gpiochip0: failed to send uevent [ 34.725173] gpio gpiochip0: uevent: failed to send synthetic uevent ---8<--- -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: armel (armv5tel) Kernel: Linux 4.19.0-0.bpo.5-marvell Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qcontrol depends on: ii libc62.24-11+deb9u4 ii liblua5.1-0 5.1.5-8.1+b2 ii udev 232-25+deb9u11 qcontrol recommends no packages. qcontrol suggests no packages. -- no debconf information
Bug#747265: openvpn: fails to ask for a password using stdin because systemd is detected,even if not installed
Package: openvpn
Version: 2.3.2-9
Severity: important
Dear Maintainer,
When trying to use OpenVPN in CLI mode, I usually need to provide the
password to unlock my user certificate.
OpenVPN normally asks me for it when initialized:
-- 8 --
Tue May 6 22:36:20 2014 us=600190 OpenVPN 2.3.2 x86_64-pc-linux-gnu
[SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on
Mar 17 2014
Enter Private Key Password:
-- 8 --
But since the 2.3.2 update, trying to start OpenVPN gives this instead:
-- 8 --
Tue May 6 22:30:37 2014 us=712490 OpenVPN 2.3.2 x86_64-pc-linux-gnu
[SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on
Mar 17 2014
Tue May 6 22:30:37 2014 us=713476 ERROR: could not not read Private Key
password from stdin
Tue May 6 22:30:37 2014 us=713512 Exiting due to fatal error
-- 8 --
After a little strace session, I got a clue about what was wrong using
strace:
-- 8 --
lstat(/sys/fs/cgroup, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
lstat(/sys/fs/cgroup/systemd, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
-- 8 --
It seems that due to a change in OpenVPN code, it now tries to detect if
systemd is installed and if yes (/sys/fs/cgroup/systemd is here), it
tries to use /bin/systemd-ask-password to ask for a passphrase.
See https://bugs.archlinux.org/task/33588 for details
I don't have systemd installed (I still use sysvinit), but still,
/sys/fs/cgroup/systemd is mounted on my machine. (Due to systemd-logind
maybe ?), thus breaking my OpenVPN installation.
Also, umounting /sys/fs/cgroup/systemd restores the previous behavior,
which is to ask for the password on stdin.
A fix seems to exist upstream, but has not been committed yet:
https://community.openvpn.net/openvpn/ticket/274
Is it possible to apply it on Debian's package so we prevent situations
like this?
Thanks in advance!
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages openvpn depends on:
ii debconf [debconf-2.0] 1.5.53
ii initscripts2.88dsf-53
ii iproute2 3.14.0-1
ii libc6 2.18-5
ii liblzo2-2 2.06-1.2
ii libpam0g 1.1.8-3
ii libpkcs11-helper1 1.11-1
ii libssl1.0.01.0.1g-3
Versions of packages openvpn recommends:
ii easy-rsa 2.2.2-1
Versions of packages openvpn suggests:
ii openssl 1.0.1g-3
pn resolvconf none
-- debconf information:
openvpn/create_tun: false
--
*Matthieu CERDA*
/System / Network Engineer/
Normation http://www.normation.com
*87, Rue de Turbigo, 75003 Paris, France*
Phone: +33 (0)1 84 16 06 01
signature.asc
Description: OpenPGP digital signature
Bug#258131: openssh: intermittant failure with GSSAPI authentication
Le 05/07/2012 18:54, Russ Allbery a écrit : Matthieu CERDA matthieu.ce...@normation.com writes: Hello, I am having strange SIGSEGV issues with sshd, but good news: it is reproductible. [...] Could you install libkrb5-dbg and libc6-dbg and then get a new backtrace? I'm particularly interested in the call site of that free. Yep, I'll do it right away. Running sshd under valgrind might also help, since this may be heap corruption. It's been a while since I used valgrind but again, no prob. I assume that you're using libpam-krb5 to do the password checking. What version of libpam-krb5 do you have installed? This is version 4.6-1 Thanks for your help. -- Matthieu CERDA (matthieu.ce...@normation.com) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#258131: openssh: intermittant failure with GSSAPI authentication
Le 05/07/2012 18:54, Russ Allbery a écrit : Matthieu CERDA matthieu.ce...@normation.com writes: Hello, I am having strange SIGSEGV issues with sshd, but good news: it is reproductible. [...] Could you install libkrb5-dbg and libc6-dbg and then get a new backtrace? I'm particularly interested in the call site of that free. Here you go: Program received signal SIGSEGV, Segmentation fault. _int_free (av=0x76653e60, p=0x4e455a2e41455a) at malloc.c:4892 4892malloc.c: Aucun fichier ou dossier de ce type. (gdb) thr apply all bt Thread 1 (Thread 0x77fe27c0 (LWP 10254)): #0 _int_free (av=0x76653e60, p=0x4e455a2e41455a) at malloc.c:4892 #1 0x7634b87c in *__GI___libc_free (mem=optimized out) at malloc.c:3738 #2 0x768d182b in default_an_to_ln (context=context@entry=0x557fbda0, aname=aname@entry=0x557fc3b0, lnsize=lnsize@entry=65, lname=lname@entry=0x7fffda30 \200t~UUU) at ../../../../src/lib/krb5/os/an_to_ln.c:632 #3 0x768d2216 in krb5_aname_to_localname (context=context@entry=0x557fbda0, aname=aname@entry=0x557fc3b0, lnsize_in=lnsize_in@entry=65, lname=lname@entry=0x7fffda30 \200t~UUU) at ../../../../src/lib/krb5/os/an_to_ln.c:793 #4 0x768d55eb in an2ln_ok (luser=0x557e7480 mcerda, principal=0x557fc3b0, context=0x557fbda0) at ../../../../src/lib/krb5/os/kuserok.c:168 #5 krb5_kuserok (context=0x557fbda0, principal=0x557fc3b0, luser=0x557e7480 mcerda) at ../../../../src/lib/krb5/os/kuserok.c:181 #6 0x555804ba in ?? () #7 0x5556647b in ?? () #8 0x5557a72a in ?? () #9 0x5557b7ca in ?? () #10 0x5557c5ed in ?? () #11 0x55564103 in main () Looks like sshd tries to free() something that it should not. I'll try to have a peek at the related code. Running sshd under valgrind might also help, since this may be heap corruption. Valgrind does not output anything interesting except some of these while the binary is just being started: ==10666== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==10666== Command: /usr/sbin/sshd -d ==10666== ==10666== Warning: invalid file descriptor 1024 in syscall close() ==10666== Warning: invalid file descriptor 1025 in syscall close() ==10666== Warning: invalid file descriptor 1026 in syscall close() ==10666==Use --log-fd=number to select an alternative log fd. ==10666== Warning: invalid file descriptor 1027 in syscall close() ==10666== Warning: invalid file descriptor 1028 in syscall close() ==10666== Warning: invalid file descriptor 1029 in syscall close() It does not seem related to the issue. -- Matthieu CERDA (matthieu.ce...@normation.com) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#258131: openssh: intermittant failure with GSSAPI authentication
Le 6 juil. 2012 à 18:55, Russ Allbery a écrit : Oh. I knew that looked familiar. This is #512410. I thought that was fixed in unstable already. Oh ! Well thanks a lot anyway, this is a testing / wheezy machine so the package has certainly not been sent to the testing archive yet. Thanks for your help ! -- Matthieu CERDA matthieu.ce...@normation.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#258131: openssh: intermittant failure with GSSAPI authentication
Package: openssh-server Version: 1:6.0p1-2 Followup-For: Bug #258131 Hello, I am having strange SIGSEGV issues with sshd, but good news: it is reproductible. When trying to use both KerberosAuthentication and GSSAPIAuthentication, you get two cases: * If you connect with a client using GSSAPIAuthentication yes, with a valid Kerberos ticket, everything connects fine and you get a valid ticket on the remote host. * If you connect with a client using GSSAPIAuthentication no, ssh exits just after outputing: Connection closed by 192.168.100.10 Here is the Server Debug: ---8--- debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.100.1 port 5 debug1: Client protocol version 2.0; client software version OpenSSH_6.0p1 Debian-2 debug1: match: OpenSSH_6.0p1 Debian-2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-2 debug1: permanently_set_uid: 103/65534 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client-server aes128-ctr hmac-md5 none [preauth] debug1: kex: server-client aes128-ctr hmac-md5 none [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug1: KEX done [preauth] debug1: userauth-request for user mcerda service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug1: PAM: initializing for mcerda debug1: PAM: setting PAM_RHOST to 192.168.100.1 debug1: PAM: setting PAM_TTY to ssh debug1: userauth-request for user mcerda service ssh-connection method publickey [preauth] debug1: attempt 1 failures 0 [preauth] debug1: test whether pkalg/pkblob are acceptable [preauth] debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/mcerda/.ssh/authorized_keys debug1: Could not open authorized keys '/home/mcerda/.ssh/authorized_keys': No such file or directory debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/mcerda/.ssh/authorized_keys2 debug1: Could not open authorized keys '/home/mcerda/.ssh/authorized_keys2': No such file or directory debug1: restore_uid: 0/0 Failed publickey for mcerda from 192.168.100.1 port 5 ssh2 debug1: userauth-request for user mcerda service ssh-connection method password [preauth] debug1: attempt 2 failures 1 [preauth] debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1000/1000 (e=0/0) ---8--- And the client one: ---8--- OpenSSH_6.0p1 Debian-2, OpenSSL 1.0.1c 10 May 2012 debug1: Reading configuration data /home/mcerda/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to dashie.zea.zen [192.168.100.10] port 22. debug1: Connection established. debug1: identity file /home/mcerda/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/mcerda/.ssh/id_rsa-cert type -1 debug1: identity file /home/mcerda/.ssh/id_dsa type -1 debug1: identity file /home/mcerda/.ssh/id_dsa-cert type -1 debug1: identity file /home/mcerda/.ssh/id_ecdsa type -1 debug1: identity file /home/mcerda/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-2 debug1: match: OpenSSH_6.0p1 Debian-2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-ctr hmac-md5 none debug1: kex: client-server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 35:5d:08:41:bf:ac:d2:b3:1c:ce:4b:b4:7b:18:21:d8 debug1: Host 'dashie.zea.zen' is known and matches the ECDSA host key. debug1: Found key in /home/mcerda/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/mcerda/.ssh/id_rsa debug1: Authentications that can continue:
Bug#626076: Firefox crashes, error message: libfile.so: undefined symbol: gnome_vfs_unescape_string
I am also confirming this, on a fresh wheezy (testing) installation the same problem occurs with Firefox 6.0. Using : LD_PRELOAD=/usr/lib/gnome-vfs-2.0/modules/libfile.so Applications/firefox/firefox solves the problem, but this is not a viable solution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
