Bug#818552: nodejs on armel (v5l) fails with "illegal instruction"
Package: nodejs Version: 4.4.0~dfsg-1 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, * What led up to the situation? Need for a newer NodeJS than available in Debian-stable, in order to install a full Firefox-sync server. * What exactly did you do (or not do) that was effective (or ineffective)? I first tried to apt-get source nodejs from unstable && debbuild on stable. Then I tried to just install nodejs from unstable onto stable (changing sources.list). As all failed, I then debootstraped Debian stretch in a chroot (systemd-nspawn). This last test failed too so I installed the nodejs from unstable into the chroot. * What was the outcome of this action? Newer NodeJS always fail with "illegal instruction". * What outcome did you expect instead? NodeJS and npm working. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: armel (armv5tel) Kernel: Linux 3.16.0-4-kirkwood Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect (that's because of systemd-nspawn; my init system is systemd) Versions of packages nodejs depends on: ii libc62.21-9 ii libgcc1 1:5.3.1-11 ii libicu55 55.1-7 ii libssl1.0.2 1.0.2g-1 ii libstdc++6 5.3.1-11 ii libuv1 1.8.0-1 ii zlib1g 1:1.2.8.dfsg-2+b1 nodejs recommends no packages. nodejs suggests no packages. -- no debconf information
Bug#790938: spamassassin on Jessie fails with /var mounted noexec
Package: spamassassin Version: 3.4.0-6 Tags: jessie Debian version: 8.1 Kernel version: 3.16.0-4-kirkwood #1 Debian 3.16.7-ckt11-1 (2015-05-24) armv5tel GNU/Linux Hi, For years, I've had my server mount /tmp and /var noexec, as a security measure (since I met an attempt to run code uploaded in /var through an exim security bug). However, this causes spamassassin to fail because /var being mounted noexec keeps it from loading this file: /var/lib/spamassassin/compiled/5.020/3.004000/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so The error messages are: juil. 02 08:02:15 myserver spamd[785]: Can't load '/var/lib/spamassassin/compiled/5.020/3.004000/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so' for module Mail::SpamAssassin::CompiledRegexps::body_0: /var/lib/spamassassin/compiled/5.020/3.004000/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so: échec d'adressage (mapping) du segment de l'objet partagé: Opération non permise at /usr/share/perl/5.20/XSLoader.pm line 68. juil. 02 08:02:15 myserver spamd[785]: at /var/lib/spamassassin/compiled/5.020/3.004000/Mail/SpamAssassin/CompiledRegexps/body_0.pm line 378. juil. 02 08:02:15 sphinx2 spamd[785]: Can't load '/var/lib/spamassassin/compiled/5.020/3.004000/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so' for module Mail::SpamAssassin::CompiledRegexps::body_0: /var/lib/spamassassin/compiled/5.020/3.004000/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so: échec d'adressage (mapping) du segment de l'objet partagé: Opération non permise at /usr/share/perl/5.20/XSLoader.pm line 68. juil. 02 08:02:15 myserver spamd[785]: at /var/lib/spamassassin/compiled/5.020/3.004000/Mail/SpamAssassin/CompiledRegexps/body_0.pm line 378. juil. 02 08:02:15 myserver spamd[785]: BEGIN failed--compilation aborted at /var/lib/spamassassin/compiled/5.020/3.004000/Mail/SpamAssassin/CompiledRegexps/body_0.pm line 379. juil. 02 08:02:15 myserver spamd[785]: Compilation failed in require at (eval 947) line 1. The French above seems to be the translation for: failed to map segment from shared object: Permission denied I realize this is not really a software bug, but I consider this a security issue nonetheless (I have to mount -o remount,exec /var to solve the issue). Do shared objects (.so libraries) really belong in /var? What would be a better location? Yves. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788191: Wrong dependencies with rpcbind
Package: rpcbind
Version: 0.2.1-6
Severity: important
Tags: jessie
Debian version: 8.1
Kernel version: 3.16.0-4-kirkwood #1 Debian 3.16.7-ckt11-1 (2015-05-24)
armv5tel GNU/Linux
Possibly related bugs: #665338 #679716
Hi,
There seems to be a problem with rpcbind dependencies in order to run an
NFS server. The server boot went fine up to Debian Wheezy, but not
anymore with Debian Jessie.
The problem does not seem to be on the NFS/rpcbind software side,
because I can make NFS work again by running this command after the
server has finished booting:
# systemctl restart nfs-kernel-server.service
Hence my conclusion that this is a dependencies issue.
Here is my init config:
$ find /{etc,lib}/{init.d,systemd} -iname '*rpc*' -o -iname '*nfs*'
/etc/init.d/rpcbind
/etc/init.d/mountkernfs.sh
/etc/init.d/mountnfs-bootclean.sh
/etc/init.d/umountnfs.sh
/etc/init.d/nfs-common
/etc/init.d/mountnfs.sh
/etc/init.d/nfs-kernel-server
/lib/systemd/system/mountkernfs.service
/lib/systemd/system/mountnfs.service
/lib/systemd/system/mountnfs-bootclean.service
/lib/systemd/system/rpcbind.target
/lib/systemd/system/umountnfs.service
So it seems to me that systemd is used instead of sysvinit, which
should ensure better handling of dependencies.
And yet, my logs show this:
# journalctl -b0 #search: rpc|nfs|dhcp|RPC|NFS|DHCP
juin 08 19:38:42 sphinx2 systemd[1]: Found ordering cycle on
basic.target/start
juin 08 19:38:42 sphinx2 systemd[1]: Found dependency on
sysinit.target/start
juin 08 19:38:42 sphinx2 systemd[1]: Found dependency on
rpcbind.service/start
juin 08 19:38:42 sphinx2 systemd[1]: Found dependency on
network-online.target/start
juin 08 19:38:42 sphinx2 systemd[1]: Found dependency on
network.target/start
juin 08 19:38:42 sphinx2 systemd[1]: Found dependency on
inadyn@henet.service/start
juin 08 19:38:42 sphinx2 systemd[1]: Found dependency on
basic.target/start
juin 08 19:38:42 sphinx2 systemd[1]: Breaking ordering cycle by deleting
job rpcbind.service/start
juin 08 19:38:42 sphinx2 systemd[1]: Job rpcbind.service/start deleted
to break ordering cycle starting with basic.target/start
juin 08 19:38:42 sphinx2 systemd[1]: Starting LSB: NFS support files
common to client and server...
juin 08 19:38:42 sphinx2 nfs-common[137]: Starting NFS common utilities:
statd
juin 08 19:38:42 sphinx2 nfs-common[137]: Not starting: portmapper is
not running ... (warning).
juin 08 19:38:42 sphinx2 systemd[1]: Started LSB: NFS support files
common to client and server.
juin 08 19:38:52 sphinx2 systemd[1]: Starting LSB: Kernel NFS server
support...
juin 08 19:38:52 sphinx2 dhclient[470]: Internet Systems Consortium DHCP
Client 4.3.1
juin 08 19:38:52 sphinx2 dhclient[470]: For info, please visit
https://www.isc.org/software/dhcp/
juin 08 19:38:52 sphinx2 ifup[462]: Internet Systems Consortium DHCP
Client 4.3.1
juin 08 19:38:52 sphinx2 ifup[462]: For info, please visit
https://www.isc.org/software/dhcp/
juin 08 19:38:52 sphinx2 dhclient[470]: DHCPDISCOVER on eth1 to
255.255.255.255 port 67 interval 8
juin 08 19:38:53 sphinx2 dhclient[470]: DHCPREQUEST on eth1 to
255.255.255.255 port 67
juin 08 19:38:53 sphinx2 dhclient[470]: DHCPOFFER from 192.168.1.1
juin 08 19:38:53 sphinx2 dhclient[470]: DHCPACK from 192.168.1.1
juin 08 19:38:54 sphinx2 ifup[462]: DHCPDISCOVER on eth1 to
255.255.255.255 port 67 interval 8
juin 08 19:38:54 sphinx2 ifup[462]: DHCPREQUEST on eth1 to
255.255.255.255 port 67
juin 08 19:38:54 sphinx2 ifup[462]: DHCPOFFER from 192.168.1.1
juin 08 19:38:54 sphinx2 ifup[462]: DHCPACK from 192.168.1.1
juin 08 19:38:54 sphinx2 kernel: RPC: Registered named UNIX socket
transport module.
juin 08 19:38:54 sphinx2 kernel: RPC: Registered udp transport module.
juin 08 19:38:54 sphinx2 kernel: RPC: Registered tcp transport module.
juin 08 19:38:54 sphinx2 kernel: RPC: Registered tcp NFSv4.1 backchannel
transport module.
juin 08 19:38:54 sphinx2 dhclient[470]: bound to 192.168.1.100 --
renewal in 39516 seconds.
juin 08 19:38:55 sphinx2 kernel: Installing knfsd (copyright (C) 1996
o...@monad.swb.de).
juin 08 19:38:55 sphinx2 nfs-kernel-server[486]: Exporting directories
for NFS kernel daemon...
juin 08 19:38:56 sphinx2 nfs-kernel-server[486]: Starting NFS kernel
daemon: nfsd
juin 08 19:38:56 sphinx2 systemd[1]: Started LSB: Kernel NFS server
support.
juin 08 19:38:56 sphinx2 nfs-kernel-server[486]: Not starting:
portmapper is not running ... (warning).
juin 08 21:39:14 sphinx2 systemd[1]: Starting LSB: RPC portmapper
replacement...
juin 08 21:39:15 sphinx2 systemd[1]: Started LSB: RPC portmapper
replacement.
juin 08 21:39:15 sphinx2 rpcbind[1665]: Starting rpcbind daemon
juin 08 21:39:15 sphinx2 systemd[1]: Starting RPC Port Mapper.
juin 08 21:39:15 sphinx2 systemd[1]: Reached target RPC Port Mapper.
Two possible problems stand out:
- there seems to be a dependencies-loop involving rpcbind,
- rpcbind and nfs-kernel-server seem to be started too soon; they should
start After
Bug#788220: No more reverse video in shellinabox
Package: shellinabox Version: 2.14-1 Severity: important Tags: jessie Debian version: 8.1 Kernel version: 3.16.0-4-kirkwood #1 Debian 3.16.7-ckt11-1 (2015-05-24) armv5tel GNU/Linux Hi, Since I upgraded from Wheezy to Jessie, shellinabox does not display some graphics modes correctly. As far as I can see, this would at least cover reverse video, because in alpine the selected item in the menus now looks just like all other items, which makes alpine mostly unusable. It could be more than just reverse video though, because in elinks, many pages have parts of the text (quotes, code sections...) rendered as plain colored rectangles, with no visible text. Thankfully, elinks has the % action, that seems to cycle the coloring algorithm. Needless to say, both alpine and elinks were rendered perfectly (or at least readable, so I did not notice a flaw) before Jessie. On the client, I run latest Firefox, and I saw no difference between all Firefox releases since the server was upgraded to Jessie. Note: I cannot be sure that shellinabox is actually the culprit, and not ncurses for example... However, if it is any indication, I did not spot any difference in the rendering of aptitude. Yves. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708088: shellinabox: cannot input some symbols
Package: shellinabox Version: 2.14-1 Severity: normal Debian version: 8.1 Kernel version: 3.16.0-4-kirkwood #1 Debian 3.16.7-ckt11-1 (2015-05-24) armv5tel GNU/Linux Hi, I also have in Jessie (and have always had, with Lenny then Wheezy) this issue with shellinabox. I use a French keyboard, and the characters that do not work for me are: — symbol: ) FR key: ) Corresponding US key: - — symbol: ° FR key: Shift + ) Corresponding US key: - — symbol: ] FR key: AltGr + ) Corresponding US key: - — symbol: } FR key: = Corresponding US key: = — symbol: $ FR key: $ Corresponding US key: ] — symbol: £ FR key: Shift + $ Corresponding US key: ] — symbol: ¤ FR key: AltGr + $ Corresponding US key: ] — symbol: ù FR key: ù Corresponding US key: ' — symbol: % FR key: Shift + ù Corresponding US key: ' — symbol: * FR key: * Corresponding US key: # — symbol: µ FR key: Shift + * Corresponding US key: # — symbol: FR key: Corresponding US key: \ — symbol: FR key: Shift + Corresponding US key: \ — symbol: : FR key: : Corresponding US key: . — symbol: / FR key: Shift + : Corresponding US key: . — symbol: ! FR key: ! Corresponding US key: / — symbol: § FR key: Shift + ! Corresponding US key: / For some reason, though, sometimes the } becomes available... I let you imagine how frustrating it can be to interact with the shell without * ] } $ : / (thankfully, * an / work on the numeric keypad). And in a general manner, the lack of ) is also a bit distressing :-D The US key correspondence is given to give an indication about the physical location on the keyboard. For this correspondence, I used this reference: http://www.bristol.ac.uk/it-services/learning/documentation/keyboard-1/keyboard-r1-6.gif which is the QWERTY keyboard which is the closest I could find to the physical layout of a typical AZERTY keyboard. Yves. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743998: prosody: bad boot order with respect to SQL server
Package: prosody Version: 0.9.7-2 Severity: important Tags: jessie Debian version: 8.1 Kernel version: 3.16.0-4-kirkwood #1 Debian 3.16.7-ckt11-1 (2015-05-24) armv5tel GNU/Linux A bit of chat on the systemd IRC channel led to this conclusion: Either create a proper prosody systemd unit, with: Wants=xxx.service (for each database that Prosody may use) After=xxx.service (same...) Or adapt the current init.d LSB headers, with: Should-Start: xxx (for each database that Prosody may use) (For the record, in my case, xxx means postgresql) Yves. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
