Bug#978646: regression: %Y option fails to mark broken symlinks as "N"(nonexistent)
Package: findutils Version: 4.6.0+git+20161106-2 Severity: important Dear Maintainer, This is a regression as it worked in Jessie and works again in Buster, but fails in Stretch: (note: i have a script to remove dangling symlinks that relied on 'find ... -printf %Y' returning 'N' for broken symlinks that doesn't work because of this bug) [Stretch] (INcorrect behavior) $ lsb_release -cs stretch $ mkdir symlink-test $ cd symlink-test $ ln -sf /tmp fronk $ ln -sf /adfasdf blonk $ ln -sf spizzle spizzle $ find . -xdev -mindepth 1 -maxdepth 1 -type l -printf "%Y: %p # ->%l \n" l: ./blonk # ->/adfasdf ** this symlink should be marked (N) Nonexistent, rather than l d: ./fronk # ->/tmp L: ./spizzle # ->spizzle ** yay, 'find' identifies (self-referential) loops correctly [Buster] (correct behavior) $ lsb_release -cs buster $ mkdir symlink-test $ cd symlink-test $ ln -sf /tmp fronk $ ln -sf /adfasdf blonk $ ln -sf spizzle spizzle $ find . -xdev -mindepth 1 -maxdepth 1 -type l -printf "%Y: %p # ->%l \n" L: ./spizzle # ->spizzle d: ./fronk # ->/tmp N: ./blonk # ->/adfasdf ** this symlink is *correctly* marked (N) Nonexistent [Jessie] (correct behavior) $ mkdir symlink-test $ cd symlink-test $ ln -sf /tmp fronk $ ln -sf /adfasdf blonk $ ln -sf spizzle spizzle $ find . -xdev -mindepth 1 -maxdepth 1 -type l -printf "%Y: %p # ->%l \n" L: ./spizzle # ->spizzle N: ./blonk # ->/adfasdf ** this symlink is *correctly* marked (N) Nonexistent d: ./fronk # ->/tmp thanks, --stephen -- System Information: Debian Release: 9.13 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-0.bpo.9-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages findutils depends on: ii libc62.24-11+deb9u4 ii libselinux1 2.6-3+b3 findutils recommends no packages. Versions of packages findutils suggests: ii mlocate 0.26-2 -- debconf-show failed
Bug#977904: nfs-common: start-statd calls 'systemctl start rpc-statd' which can hang dbus-daemon/systemd at boot
Package: nfs-common Version: 1:1.3.4-2.1+deb9u1 Severity: important Dear Maintainer, FYI: /usr/share/bug/nfs-common/script warns of error. in my case: 'cat /etc/fstab|grep nfs >&3' returns 1 due to 'grep' fail (my nfs is all in autofs). should probably '|| true' that. to avoid user confusion in bugreport. same for other grep statements. Note: This is a doozy -- a whole tower of fail (some my fault for implementing an earlier workaround for nfs deadlocks and forgetting it was there). So i'm not sure what package to report it against, but the core trigger is in /usr/sbin/start-statd so starting there. Yes, my system is likely configured in a pretty non-standard way, having an /etc/nfsmount.conf forcing nfsv3 to avoid a deadlock in earlier systems coming back to bite me as a deadlock in the future :-( other subsystems involved: - systemd - dbus-daemon - autofs ultimately, my goal here is to help establish a robust systemd-capable coordination in the various parts here to avoid another similar issue due to these inter-dependencies. I don't know if 'start-statd' being re-written to take systemd state into account is the correct solution, but IMHO, systemd/dbus-daemon are utterly fragile in this situation and extremely difficult to debug (need systemctl to do stuff, but it won't work, and you can't restart dbus-daemon w/o systemctl, and kill -TERM on pid 1 doesn't work ... Summary: - system configured for NFSv3 mounts via /etc/nfsmount.conf note: this was to workaround a bug in NFSv4.[012] that caused deadlocks against NFSv3 servers running Jessie. i do not recall the bug # something changed in a recent Stretch patchlevel as this was working fine up until i patched and rebooted. - systemd unit rpc-statd.service is disabled - automount/autofs -> nfs is called triggering start-statd that makes a 'systemctl start rpc-statd' that takes down dbus-daemon and never completes. - regardless of where the blame lies, it is possible that is wrong to call 'systemctl' from inside 'start-statd' *if* it's being called from a systemd unit itself. If system is configured for NFS v3 mounts via /etc/nfsmount.conf and systemctl unit 'rpc-statd' is disabled, then the automounter creates a chain in boot (at least in our system case) that forcibly tries to run 'systemctl start rpc-statd' via /usr/sbin/start-statd. This results in systemctl call not completing (i don't know if it's because systemctl calls can't be nested or called outside normal startup flow or what), and eventually dbus-daemon stops responding (so it could be a bug that needs to be transferred there). this locks up the entire boot process. systemctl calls all timeout. dbus-daemon is sitting in EAGAIN (resource temporarily unavailable) Additionally, i wasn't able to ssh in (even though systemd had started sshd) because of 'pam_motd' in /etc/pam.d/sshd calling update-motd, which also blocked hard and never completed and was uninterruptable. once i commented 'pam_motd' out, i could ssh in, and C something hanging on nfs to get a shell. (again, tower of fail) once in, if i killed the 'systemctl start rpc-statd', the system would return to responsiveness. (systemctl could again contact dbus-daemon) systemd-cgls showed: +-autofs.service | +-1453 /usr/sbin/automount --pid-file /var/run/autofs.pid | +-1465 /bin/mount -t nfs -s -o intr,nodev,nosuid ral-local-linux:/exports/linux-amd64 /var/autofs/mnt/linux-amd64 | +-1466 /sbin/mount.nfs ral-local-linux:/exports/linux-amd64 /var/autofs/mnt/linux-amd64 -s -o rw,nodev,nosuid,intr | +-1467 /bin/sh /usr/sbin/start-statd | -1470 systemctl start rpc-statd.service this hangs dbus-daemon and brings down the whole systemd kingdom. before it hung, ... puffin:/etc/default/grub.d# systemctl list-jobs TYPE STATE 607 apt-daily.service start running 462 nfs-config.service start running 468 apt-daily-upgrade.service start waiting 460 rpc-statd-notify.service start waiting 453 rpc-statd.service start waiting 464 systemd-tmpfiles-clean.service start running Note: 'ral-local-linux' is our NFS-shared /usr/local. this may have been triggered early due to 'cron' being started and user '@reboot' jobs launching. Note: i have a lot of systemd debug and other captured logs i can provide if needed. here's the /etc/nfsmount.conf that was being used prior: [ NFSMount_Global_Options ] nfsvers=3 Thanks, --stephen -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper
Bug#953066: libpciaccess0: nVidia driver finds no devices, sddm dies with ABRT
Package: libpciaccess0
Version: 0.13.4-1+b2
Severity: important
-- System Information:
Debian Release: 9.12
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-0.bpo.6-amd64 (SMP w/40 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 libpciaccess0 depends on:
ii libc6 2.24-11+deb9u4
ii zlib1g 1:1.2.8.dfsg-5
libpciaccess0 recommends no packages.
Versions of packages libpciaccess0 suggests:
ii pciutils 1:3.5.2-1
-- no debconf information
SUMMARY:
- this is fixed by the libpciaccess0 0.14-1 .so library manually
replacing the distribution library. Appears to be the PCI address
space size issue. (see below bug ref)
- this bug seems pretty major, so is it possible it'll ever get into
the stretch distribution?
- possible that it only effects our systems using UEFI boot as we have
some BIOS boot systems that have similar configurations that don't
have this problem. (not entirely sure the hardware is all similar)
NOTE: some report data below is from another system that was using both the
non-backports kernel as well as the backports kernel (no diff in symptoms)
Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892754
dmesg:
[ 15.915748] systemd[1]: sddm.service: Failed with result 'signal'.
[ 17.214465] systemd[1]: sddm.service: Main process exited, code=killed,
status=6/ABRT
[ 17.216271] systemd[1]: sddm.service: Failed with result 'signal'.
[ 18.447283] systemd[1]: sddm.service: Main process exited, code=killed,
status=6/ABRT
[ 18.449123] systemd[1]: sddm.service: Failed with result 'signal'.
[ 19.700575] systemd[1]: sddm.service: Start request repeated too quickly.
[ 19.701925] systemd[1]: Failed to start Simple Desktop Display Manager.
[ 19.703344] systemd[1]: sddm.service: Failed with result 'signal'.
hostname:.../share/doc/NVIDIA_GLX-1.0# grep NULL /var/log/Xorg.0.log
[13.286] (II) NVIDIA(0): nvCommonPlatformProbe: Device is NULL
[13.286] (II) NVIDIA(0): nvCommonPlatformProbe: Device is NULL
The following may be irrelevant
hostname:/etc/default/grub.d# dmesg | grep BAR\.\*size
[4.401542] pci 1:00:02.0: BAR 13: no space for [io size 0xb000]
[4.401544] pci 1:00:02.0: BAR 13: failed to assign [io size 0xb000]
[4.401546] pci 1:00:03.0: BAR 13: no space for [io size 0xc000]
[4.401547] pci 1:00:03.0: BAR 13: failed to assign [io size 0xc000]
[4.401551] pci 1:00:02.0: BAR 13: no space for [io size 0xb000]
[4.401552] pci 1:00:02.0: BAR 13: failed to assign [io size 0xb000]
[4.401554] pci 1:00:03.0: BAR 13: no space for [io size 0xc000]
[4.401556] pci 1:00:03.0: BAR 13: failed to assign [io size 0xc000]
card is there:
hostname:~# nvidia-smi -L
GPU 0: Quadro P400 (UUID: GPU-10d81f86----cdad)
NOTE: '*' used to sanitize
device info not properly enumerated
hostname:~# cat /proc/driver/nvidia/gpus/*/information
Model: Unknown
IRQ: 81
GPU UUID:GPU-----
Video BIOS: ??.??.??.??.??
Bus Type:PCIe
DMA Size:36 bits
DMA Mask:0xf
Bus Location::65:00.0
Device Minor:0
Blacklisted: No
# NOTE: the '?' above are literal (not sanitization replacements)
I am using the following (flawed) script to "workaround" this problem to get my
desktop systems functional (it fixes the problem and the X11 +sddm
system works as expected) :
dl_file="http://ftp.us.debian.org/debian/pool/main/libp/libpciaccess/libpciaccess0_0.14-1_amd64.deb;
repl_file="/usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1"
cd /
cp "${repl_file}" "${repl_file%/*}/__${repl_file##*/}.DIST"
# (prefix with __ to keep ldconfig from symlinking SONAME of old
# library)
if curl -s "${dl_file}" \
| dpkg-deb --fsys-tarfile - \
| tar xvf - .${repl_file}
then
ldconfig
else
echo "Something bad happened. rc=$?"
exit 1
fi
echo "YOU SHOULD REBOOT NOW"
Thanks,
--stephen
Bug#950894: Acknowledgement (mawk: numeric comparison on 'sub()' resulted ${n} vars does not work properly)
On 2/7/20 2:15 PM, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 950894: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950894. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Boyuan Yang If you wish to submit further information on this problem, please send it to 950...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. Considered this closed. Communication on 'bug-g...@gnu.org' indicates that 'sub()' modifies a 'strnum' to a 'string' for $1, and that it is no longer considered "user input", but a string constant, and thus comparisons will be done as string only. Ref: https://www.gnu.org/software/gawk/manual/html_node/Variable-Typing.html thanks, --stephen
Bug#950894: mawk: numeric comparison on 'sub()' resulted ${n} vars does not work properly
Package: mawk
Version: 1.3.3-17+b3
Severity: normal
Dear Maintainer,
NOTE: this affects both 'mawk' and 'gawk' equally, so i'm not sure if this is
some utterly esoteric behavior i'm just not "getting", but my expectations are
definitely not being met.
(i also am unaware if a bug can be co-assigned to different packages)
Attempting to do a search for filesystems > 90% inode % or size % was giving
anomolous results. (hair-pulling time)
I was using 'sub("%","",$1) to strip the % symbol off the results from:
df --output=ipcent,pcent,target /var /var/log
e.g.:
$ df --output=ipcent,pcent,target -t ext4 | mawk
'NR>1{sub("%","",$1);sub("%","",$2); if (($1>30)||($2>30)) print}'
40 79 /
6 30 /var
1 7 /opt
20 78 /home
1 89 /d1
(clearly /opt doesn't meet the reporting criteria)
I narrowed this down to what appears to be a field-size truncation comparison
issue with the result from the sub() against the comparison numeric on the
right-side of the relop:
# The following all work as expected: (no output)
$ for i in $(seq 20 29); do echo "$i%" | mawk '{if (int($1)>100) print}'; done
$ for i in $(seq 20 29); do echo "$i%" | gawk '{if (int($1)>100) print}'; done
$ for i in $(seq 20 29); do echo "$i%" | mawk '{if (($1+0)>100) print}'; done
$ for i in $(seq 20 29); do echo "$i%" | gawk '{if (($1+0)>100) print}'; done
This does NOT work, though it should: (none of these values should print, they
are all < 100, which is the comparison being made)
$ for i in $(seq 20 29); do echo "$i%" | mawk '{sub("%","",$1);if ($1>100)
printf("[%s][%d]\n",$1,$1)}'; done
[20][20]
[21][21]
[22][22]
[23][23]
[24][24]
[25][25]
[26][26]
[27][27]
[28][28]
[29][29]
The man pages clearly state that a dual-type (numeric) variable SHOULD
be implicitly cast to numeric if a comparison is against a numeric.
I also did this against a single digit input and a two-digit RHS value, and it
shows the same issue, where only the same number of digits of the RHS that the
input value contain are being compared.
$ for i in $(seq 0 20); do echo "$i%" | gawk '{sub("%","",$1);if ($1>40)
printf("[%s][%d]\n",$1,$1)}'; done
[5][5]
[6][6]
[7][7]
[8][8]
[9][9]
Using an RHS of a float also fails:
$ for i in $(seq 0 20); do echo "$i%" | gawk '{sub("%","",$1);if ($1>40.0)
printf("[%s][%d]\n",$1,$1)}'; done
[5][5]
[6][6]
[7][7]
[8][8]
[9][9]
I don't know how if there's a way to evaluate the internal data-type
representation for $1 here, so i printed it with printf both as string and
integer, and they report identical.
Thanks,
--stephen
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-7-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mawk depends on:
ii libc6 2.28-10
mawk recommends no packages.
mawk suggests no packages.
-- no debconf information
Bug#900210: Thunderbird AppArmor config breaks stuff with custom $TMPDIR
On 8/8/18 2:21 PM, Christian Boltz wrote: Helllo, Stephen, while we are discussing this, I'd like to give you an easy workaround: If you need a solution that works for all users (and is a bit less strict because it only enforces that the directory name has to start with a digit) alias /tmp/ -> /run/user/[0-9]*/, After adding the alias, reload all AppArmor profiles. Christian, Somehow i missed this earlier... I had to revisit this, because # grep apparmor /var/log/dpkg.log 2018-11-16 07:21:25 conffile /etc/apparmor.d/usr.bin.thunderbird install re-broke things. (sigh, my workplace daily notices were throwing more apparmor="DENIED" traps and leaving my message-pane blank. (would be nice if there was a tool for the desktop to issue notifications in these cases. maybe there is, but my lack of searching for it has amazingly not revealed it! ;)) Seems that the latest thunderbird update should honor the aa-complain status of my system. Looking at : /var/lib/dpkg/info/thunderbird.postinst I see some logic that looks like i should be using a "disable" link. That seems like it would be different, however, than just setting it to 'complain' mode. (I don't mind having it complaining and logging, but it's a lot more unfriendly to just disable it on my part, or to re-enable enforcing when i am in complain mode) I dunno if i should file a bug report on that :-/ (i see that this bug is still in 'thunderbird', and the apparmor file is dpkg-owned by thunderbird, so maybe just consider this comment a bug report addition) Anyway, i implemented your workaround. I may test it out with aa-enabled again at some point just to make sure it's working. thanks, --stephen
Bug#855632: Info received (Bug#883217: linux: open on NFSv4 exported file on nfs server: "Resource temporarily unavailable" under reproducible conditions when client has granted read delegation on fil
On 12/14/2017 05:54 PM, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 855...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. Salvatore, Sorry i haven't gotten back, but just wanted to let you know that at this point, i haven't seen the "resource temporarily unavailable" issues on this server anymore. It's presently running: gizmo:/var/log# uname -a Linux gizmo 3.16.0-6-amd64 #1 SMP Debian 3.16.56-1+deb8u1 (2018-05-08) x86_64 GNU/Linux so, i think you can close this side of the bug. Thanks for the feedback/follow-through! --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#900210: thunderbird: Thunderbird AppArmor config disables ability to send entirely
Package: thunderbird Version: 1:52.8.0-1~deb9u1 Severity: important Attempting to send e-mail results in a popup: [ Send Message Error ] Sending of the message failed. # aa-status --enabled && echo "AppArmor Enabled" AppArmor Enabled # aa-status | egrep '(profiles|thunderbird)' 54 profiles are loaded. 21 profiles are in enforce mode. thunderbird thunderbird//browser_java thunderbird//browser_openjdk thunderbird//gpg thunderbird//sanitized_helper 33 profiles are in complain mode. 6 processes have profiles defined. thunderbird (32689) dmesg shows the following apparmor DENIED messages: [62711.954571] audit: type=1400 audit(1527437094.186:58): apparmor="DENIED" operation="open" profile="thunderbird" name="/run/user/1000/xauth-1000-_0" pid=32700 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [62711.960341] audit: type=1400 audit(1527437094.194:59): apparmor="DENIED" operation="open" profile="thunderbird" name="/run/user/1000/xauth-1000-_0" pid=32689 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [62711.971343] audit: type=1400 audit(1527437094.202:60): apparmor="DENIED" operation="mkdir" profile="thunderbird" name="/run/user/1000/thunderbird_sdowdy/" pid=32689 comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 [62711.971925] audit: type=1400 audit(1527437094.206:61): apparmor="DENIED" operation="open" profile="thunderbird" name="/run/user/1000/xauth-1000-_0" pid=32689 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [62712.747197] audit: type=1400 audit(1527437094.978:62): apparmor="DENIED" operation="open" profile="thunderbird" name="/run/user/1000/xauth-1000-_0" pid=32689 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [62712.895221] audit: type=1400 audit(1527437095.126:63): apparmor="DENIED" operation="open" profile="thunderbird" name="/etc/xdg/mimeapps.list" pid=32689 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [63310.628483] audit: type=1400 audit(1527437692.863:64): apparmor="DENIED" operation="mknod" profile="thunderbird" name="/run/user/1000/nsemail.eml" pid=32689 comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 [63310.671468] audit: type=1400 audit(1527437692.907:65): apparmor="DENIED" operation="open" profile="thunderbird" name="/run/user/1000/xauth-1000-_0" pid=32689 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 $ env | grep /run/user TMPDIR=/run/user/1000/ GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus XDG_RUNTIME_DIR=/run/user/1000 XAUTHORITY=/run/user/1000/xauth-1000-_0 I suspect because i explicitly set TMPDIR to XDG_RUNTIME_DIR (something that should be pretty normal, even better than using /tmp, IMHO), that AppArmor should allow for this. (i'm not entirely sure that's the issue, but it seems likely) Also, for general purposes... I did choose to allow/use maintainer's version of AppArmor configuration in the recent update, however, i think you should respect the existing enforce/complain/disable state of the user's system, as i'd previously done: aa-complain /etc/apparmor.d/usr.bin.thunderbird (which i am back to now in order to keep working) thanks, --stephen -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thunderbird depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-11+deb9u3 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libhunspell-1.4-0 1.4.1-2+b2 ii libpango-1.0-01.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-0 1.40.5-1 ii libpixman-1-0 0.34.0-1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii
Bug#855632: Bug#883217: linux: open on NFSv4 exported file on nfs server: "Resource temporarily unavailable" under reproducible conditions when client has granted read delegation on file
On 12/14/2017 12:51 PM, Salvatore Bonaccorso wrote: > Hi Stephen, > > On Mon, Dec 04, 2017 at 09:24:55PM +0100, Salvatore Bonaccorso wrote: >> Hi >> >> On Thu, Nov 30, 2017 at 03:35:40PM -0700, Stephen Dowdy wrote: >>> On 11/30/2017 01:39 PM, Salvatore Bonaccorso wrote: >>>> Is this worth trying to be fixed for the jessie kernel? >>> >>> Salvatore, >>> >>> I believe this is likely the reason for my bug report: >>> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855632 >>> >>> as that system has thrown EAGAIN errors since i installed it in April, 2015. >>> It's a 10 NIC NFS server for the department, and often throws the error >>> when i update files that are likely being read/open by client systems. >>> (it doesn't have a huge resource consumption load ever and i get that >>> failure) >>> >>> So, i vote yeah ;) >> >> Okay. > > Did you got a chance to test this as well for your case of #855632? > > Regards, > Salvatore > Salvatore, Sorry i didn't respond. things have been way crazy. Unfortunately, i probably won't be able to test because: - problem is not reproducible easily sometimes - this machine services several hundred systems w/o any upcoming scheduled downtime. I haven't noticed the problem on any other machines we have, though, so don't have any other candidates for testing. I may just take the "upgrade to stretch" solution out of this when i have some scheduled downtime. thanks, --stephen
Bug#883217: linux: open on NFSv4 exported file on nfs server: "Resource temporarily unavailable" under reproducible conditions when client has granted read delegation on file
On 11/30/2017 01:39 PM, Salvatore Bonaccorso wrote: > Is this worth trying to be fixed for the jessie kernel? Salvatore, I believe this is likely the reason for my bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855632 as that system has thrown EAGAIN errors since i installed it in April, 2015. It's a 10 NIC NFS server for the department, and often throws the error when i update files that are likely being read/open by client systems. (it doesn't have a huge resource consumption load ever and i get that failure) So, i vote yeah ;) --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#868658: plasma-desktop: autohide panel fails
On 08/22/2017 10:20 AM, Heinrich Schuchardt wrote: > When thunderbird is opened it displays a dialogue to ask for the email > account password. > > While this popup is shown in thunderbird the panel does not autohide > when changing to another application. Heinrich, i *believe* this is expected behavior. The fun part is when a dialog is open on another virtual screen the plasma panel STILL remains open and obscures things. I haven't found any way to determine WHICH application/window is holding the panel open, though, so i sometimes have to hunt on all of my virtual screens looking for a dialog. I do not know if there's a control that can toggle/disable this behavior, either, but it is common with how MS-Windows does it as well. The idea is that the system "knows better than you" what's important and needs your attention. (if only you could figure out *WHAT* the important thing is immediately. --stephen
Bug#868065: powerdevil-data: Energy Savings KCM config window is too large for screen and has no scrollbars
Package: powerdevil-data Version: 4:5.8.4-1 Severity: normal /usr/bin/kcmshell5 powerdevilprofilesconfig.desktop generates a window which is: $ xwininfo -name 'Energy Saving — System Settings Module' | grep geometry -geometry 719x904+37+29 904 pixels tall. However, my laptop screen is : $ xdpyinfo | grep dimensions dimensions:1600x900 pixels (423x238 millimeters) 900 pixels tall (i.e. shorter) With associated titlebar gadgetry, the [Help] [Reset] [Defaults] [Ok] [Apply] [Cancel] buttons at the bottom are inaccessible because there is no scrollbar on the window. (they are located off the bottom of the viewport of the display) I know i can Move the window to access the buttons, but my users may not be so savvy. This type of UI fail is really unacceptable for general use. thanks, --stephen -- 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= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- debconf-show failed
Bug#862124: systemd: systemctl {stop|start} nis ypbind... errors with "out of memory"
On 05/08/2017 04:17 PM, Michael Biebl wrote:
> This looks like a duplicate of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831894
> which is fixed in newer version of systemd.
Ack, missed that. i usually use something like:
$ apt-listbugs -s all list systemd | grep -i memory
to search for bugs related to what i'm seeing. That bug is "Archived", so i
guess it doesn't show up, and i can't seem to find a way to have that bug
report match :-/ (is there some other CLI command i can use that'd find that?)
(i think that's what 'reportbug' does, and paging through the list visually is
a LOT harder than doing the above CLI grep command)
> Since you are the second person reporting this issue, I wonder whether
> you'd be willing to find out the commit which fixed this issue so we can
> decide whether this commit would be suitable for a backport or not.
Well, i'm gonna pull a Dr. McCoy on ya... ("Damnit, Jim! I'm A Systems
Administrator, Not A Software Developer!")
I guess it's not critical enough to me to invest time hunting it down right now.
Anyway, having a bug report that describes the condition/fix that's searchable
by someone having the problem is "Good Enough For Me(tm)" at this time.
thanks,
--stephen
Bug#857961: Acknowledgement (qemu-system-x86: memory configs > 16GB create bad DMI configs (last slot empty) and wrong mem size)
yeah, i'm beginning to think this is 'seabios' I mistakenly used the memory size reports from my own tool which sums the DIMM slots, rather than getting 'MemTotal' out of '/proc/meminfo', which reports the correct value. So, please re-assign this to 'seabios' (i think) thanks, --stephen
Bug#857961: qemu-system-x86: memory configs > 16GB create bad DMI configs (last slot empty) and wrong mem size
Package: qemu-system-x86
Version: 1:2.1+dfsg-12+deb8u6
Severity: normal
Dear Maintainer,
Qemu-KVM Memory allocations > 16GB don't work right.
I don't know exactly where this bug resides (qemu-system-x86, qemu-kvm,
seabios???)
Any configuration > 16GB lead to an unpopulated final DIMM slot and incorrect
memory count
Asked For Got
- ---
2GB 2GB
4GB 4GB
8GB 8GB
16GB16GB*
32GB16GB
64GB48GB
128GB 112GB
*Special case, asking for 16GB gets 16GB but DMI claims the singular DIMM slot
on the system is EMPTY?!?!?
The QEMU running command in this special case is:
qemu-system-x86 -enable-kvm -name testing -S -machine
pc-q35-2.1,accel=kvm,usb=off -cpu
Broadwell,+invtsc,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
-m 16384 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid
834c942a-e29e-40df-b6eb-e5288cc62e7c -no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/testing.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew
-global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global
PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot
order=c,menu=on,strict=on -device
i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device
pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive
file=/VMDATA/Disk_Images/testing-os.img,if=none,id=drive-virtio-disk0,format=raw
-device virtio-blk-pci,scsi=off!
,bus=pci.2,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0 -netdev
tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fb:d3:c2,bus=pci.2,addr=0x3
-chardev spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
-spice port=5900,addr=127.0.0.1,seamless-migration=on -device
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pcie.0,addr=0x1
-device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x1 -device
pvpanic,ioport=1285 -msg timestamp=on
specifically with '-m 16384'. Other configurations below just alter the '-m'
option (and nothing else)
--
++ specify 2GB (2048MB) current/max and get:
# dmidecode -t memory | grep -e 'Maximum Capacity' -e 'Number Of Devices'
Maximum Capacity: 2 GB
Number Of Devices: 1
# dmidecode -t memory | sed -ne '/Memory Device/,/Part Number/ { /Size:/h;
/^[[:space:]]*Locator:/ {p;x;p}; /Speed:/p}' | paste - - - | tr -s '\t' |
expand -t 1,20,50
Locator: DIMM 0Size: 2048 MB Speed: Unknown
--
++ specify 4GB (4096MB) current/max and get:
ocean:~# dmidecode -t memory | grep -e 'Maximum Capacity' -e 'Number Of Devices'
Maximum Capacity: 4 GB
Number Of Devices: 1
ocean:~# dmidecode -t memory | sed -ne '/Memory Device/,/Part Number/ {
/Size:/h; /^[[:space:]]*Locator:/ {p;x;p}; /Speed:/p}' | paste - - - | tr -s
'\t' | expand -t 1,20,50
Locator: DIMM 0Size: 4096 MB Speed: Unknown
--
++ specify 8GB (8192MB) current/max and get:
ocean:~# dmidecode -t memory | grep -e 'Maximum Capacity' -e 'Number Of Devices'
Maximum Capacity: 8 GB
Number Of Devices: 1
ocean:~# dmidecode -t memory | sed -ne '/Memory Device/,/Part Number/ {
/Size:/h; /^[[:space:]]*Locator:/ {p;x;p}; /Speed:/p}' | paste - - - | tr -s
'\t' | expand -t 1,20,50
Locator: DIMM 0Size: 8192 MB Speed: Unknown
--
++ specify 16GB (16384) current/max and get:
ocean:~# dmidecode -t memory | grep -e 'Maximum Capacity' -e 'Number Of Devices'
Maximum Capacity: 16 GB
Number Of Devices: 1
ocean:~# dmidecode -t memory | sed -ne '/Memory Device/,/Part Number/ {
/Size:/h; /^[[:space:]]*Locator:/ {p;x;p}; /Speed:/p}' | paste - - - | tr -s
'\t' | expand -t 1,20,50
Locator: DIMM 0Size: No Module Installed Speed: Unknown
--
++ specify 32GB (32768MB) current/max and get:
# dmidecode -t memory | grep -e 'Maximum Capacity' -e 'Number Of Devices'
Maximum Capacity: 32 GB
Number Of Devices: 2
# dmidecode -t memory | sed -ne '/Memory Device/,/Part Number/ { /Size:/h;
/^[[:space:]]*Locator:/ {p;x;p}; /Speed:/p}' | paste - - - | tr -s '\t' |
expand -t 1,20,50
Locator: DIMM 0Size: 16384 MBSpeed: Unknown
Locator: DIMM 1Size: No Module Installed Speed: Unknown
--
++ specify 64GB (65536MB) current/max and get:
# dmidecode -t memory | grep -e 'Maximum Capacity' -e 'Number Of Devices'
Maximum Capacity: 64 GB
Number Of Devices: 4
# dmidecode -t memory | sed -ne '/Memory Device/,/Part Number/ { /Size:/h;
/^[[:space:]]*Locator:/ {p;x;p}; /Speed:/p}' | paste - - - |
Bug#857235: [Bash-completion-devel] Bug#857235: bash-completion: /etc/profile.d/bash_completion.sh can't be forcibly re-run
On 03/09/2017 02:48 AM, Ville Skyttä wrote:
> I don't know what the reason for making the variable read only is. But
> I think you could work around it by setting BASH_COMPLETION_COMPAT_DIR
> to a fake value, e.g. /prevent/sourcing in your rc files before the
> profile.d snippet is sourced (thus preventing it from loading
> bash_completion), and then unsetting it before "manually" loading the
> profile.d snippet where you want, and let it do its job unmodified.
Ville,
Problem here is that bash invokes /etc/profile prior to the end-user having
control via .bashrc. All that stuff in /etc/profile.d/bash_completion.sh is
performed outside my control. (i prefer not to mangle up too many
system-provided files, or affect my user's expectations of the environment)
It might be possible to set it via 'pam_env' or something (which *should* take
effect prior to the shell invoking /etc/profile) That's a little messy, and i'd
prefer not to have to bring yet another component into the picture.
But, let's do a proof-of-concept:
# cat ~/.pam_environment
BASH_COMPLETION_COMPAT_DIR="BOGUS"
# cat /root/.bashrc
.
\unset -f unalias ; \unalias -a ; \unset -f command
\unset LD_LIBRARY_PATH LD_PRELOAD SHELLOPTS CDPATH HISTFILE HOSTFILE
INPUTRC 2>/dev/null
confpath="$(command -p getconf PATH 2>/dev/null)"
# Establish baseline path with no NFS components
export PATH="/opt/sbin:/opt/bin:/sbin:/usr/sbin:${confpath:-/bin:/usr/bin}"
\type typeset >/dev/null && \unset -f $(\typeset -f | \grep '()' | \cut -d'
' -f1)
.
is_shell_interactive() { [ "${-%i*}" != "${-}" ] ;}
.
if is_shell_interactive; then
# RELOAD bash-completion
echo "DEBUG:
BASH_COMPLETION_COMPAT_DIR[before]=${BASH_COMPLETION_COMPAT_DIR}" 1>&2
unset BASH_COMPLETION_COMPAT_DIR
. /etc/profile.d/bash_completion.sh
echo "DEBUG:
BASH_COMPLETION_COMPAT_DIR[after]=${BASH_COMPLETION_COMPAT_DIR}" 1>&2
Results in, when i remote 'ssh' login:
DEBUG: BASH_COMPLETION_COMPAT_DIR[before]="BOGUS"
DEBUG: BASH_COMPLETION_COMPAT_DIR[after]=/etc/bash_completion.d
# set | grep longopt\ \(
_longopt ()
_split_longopt ()
So, indeed, that *will* work -- presuming pam_env PAM enabled services (my
ssh+su+login config at least uses it).
Thanks for the idea. That gets me a drop on doing this now (other than what i
was doing, which was just invoking the two command lines that
/etc/profile.d/bash_completion.sh script was doing inside the conditional
block). I think it still would be conceptually better to not have to rely on
pam_env for this to work, and have bash-completion implement some re-sourcable
invocation mechanism.
--stephen
Bug#857235: bash-completion: /etc/profile.d/bash_completion.sh can't be forcibly re-run
Package: bash-completion
Version: 1:2.1-4
Severity: normal
Dear Maintainer,
For my root .bashrc i have the following introduction block that is designed to
help ensure i don't inherit bad/unexpected values from somewhere else (sshd,
/etc/profile.d/, etc...) and the root interactive bash environment is as close
to pristine/expected and built on from there.
\unset -f unalias ; \unalias -a ; \unset -f command
\unset LD_LIBRARY_PATH LD_PRELOAD SHELLOPTS CDPATH HISTFILE HOSTFILE
INPUTRC 2>/dev/null
confpath="$(command -p getconf PATH 2>/dev/null)"
export PATH="/opt/sbin:/opt/bin:/sbin:/usr/sbin:${confpath:-/bin:/usr/bin}"
\type typeset >/dev/null && \unset -f $(\typeset -f | \grep '()' | \cut -d'
' -f1)
However, because the bash completions package defines a bunch of functions
(that i'm removing above), i would like to be able to subsequently re-evaluate
the bash completions later on in the .bashrc after this block.
but, /etc/profile.d/bash_completions.sh has the following conditional:
# Check for interactive bash and that we haven't already been sourced.
if [ -n "$BASH_VERSION" -a -n "$PS1" -a -z "$BASH_COMPLETION_COMPAT_DIR" ];
then
Since
/usr/share/bash-completion/bash_completion
establishes BASH_COMPLETION_COMPAT_DIR as a readonly variable, i can not unset
it in the shell, and thus can not re-source this script.
I presume it's readonly for security reasons (so it couldn't be hijacked to run
random code in another location?)
So, with that in mind, could the conditional be changed instead to something
like:
if [ -n "$BASH_VERSION" -a -n "$PS1" -a \( -z
"$BASH_COMPLETION_COMPAT_DIR" -o \( "$1" = "force" \) \) ]; then
so that it could be forcibly re-evaluated? (this way i don't have to duplicate
its code in my .bashrc and hope it doesn't change on package updates)
Alternative solutions welcome.
thanks,
--stephen
-- System Information:
Debian Release: 8.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bash-completion depends on:
ii bash 4.3-11+deb8u1
ii dpkg 1.17.27
bash-completion recommends no packages.
bash-completion suggests no packages.
-- no debconf information
Bug#857095: apt-file: bad warning message
Package: apt-file Version: 3.1.4 Severity: minor Dear Maintainer, gtgn:~# apt-file search pdfsig E: The cache is empty. You need to run "apt update" first. ^^^ I think that should say "apt-file" and not "apt" thanks, --stephen -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 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 apt-file depends on: ii apt 1.4~rc2 ii libapt-pkg-perl 0.1.30 ii liblist-moreutils-perl 0.416-1+b1 ii libregexp-assemble-perl 0.36-1 pn perl:any apt-file recommends no packages. apt-file suggests no packages. -- Configuration Files: /etc/apt/apt.conf.d/50apt-file.conf changed [not included] -- no debconf information
Bug#849621: libc-bin: 'zdump -c' can't properly handle leap-second insertion at last second of year
Package: libc-bin Version: 2.19-18+deb8u7 Severity: minor Tags: upstream Dear Maintainer, using year limit boundaries of 2016 minimum (inclusive) and 2017 maximum (non-inclusive), then including 2018 maximum, yields: $ zdump -V -c2016,2017 right/America/Denver | grep ':60 ' $ zdump -V -c2016,2018 right/America/Denver | grep ':60 ' right/America/Denver Sat Dec 31 23:59:60 2016 UT = Sat Dec 31 16:59:60 2016 MST isdst=0 gmtoff=-25200 $ zdump -V -c2016,2017 right/Etc/UTC | grep ':60 ' $ zdump -V -c2016,2018 right/Etc/UTC | grep ':60 ' right/Etc/UTC Sat Dec 31 23:59:60 2016 UT = Sat Dec 31 23:59:60 2016 UTC isdst=0 gmtoff=0 that extra leap second is getting ignored as being in 2016. Certainly no big deal, and i added 'upstream' tag, as this is likely something missed in the upstream sources. thanks, --stephen -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libc-bin depends on: ii libc6 2.19-18+deb8u7 libc-bin recommends no packages. libc-bin suggests no packages. -- Configuration Files: /etc/ld.so.conf changed [not included] -- no debconf information
Bug#845387: jessie-pu: package glibc/2.19-18+deb8u7
sorry to butt-in here, but: FYI: typo alert? fqsrt -> fsqrt ?? (transposition of q & s) I know it's just in the e-mail twice and the patch changelog once, but it'd be good if the changelog was typographically correct, esp for searches. --stephen
Bug#831033: libc6: NSS (compat/nis) randomly fails for getent*
Package: libc6 Severity: important -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/64 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) We are having random failures to map UIDs to usernames ** Note: joebob and bigcomputer are fabricated names joebob@bigcomputer:~$ whoami joebob joebob@bigcomputer:~$ whoami whoami: cannot find name for user ID 1234 joebob@bigcomputer:~$ whoami whoami: cannot find name for user ID 1234 joebob@bigcomputer:~$ whoami joebob joebob@bigcomputer:~$ whoami joebob but ypcat passwd.byname | grep joebob consistently works properly. ypcat passwd.byname | wc -l always returns the same value. So, it appears that NIS is correctly functioning itself. (it's a number i expect above 1,000, and definitely not zero ;) ) However, I have no name!@bigcomputer:~$ while getent passwd | wc -l; do sleep 1; done 2462 2462 2462 2462 2462 1377 85 36 36 36 36 36 36 50 So, getent passwd is randomly failing to fully populate /etc/nsswitch.conf contains: passwd: compat group: compat nis * netgroup: nis * this has been in our systems for years due to bug 584914 I have alternatively tried the following unsuccessfully: passwd: compat nis (to see if 584914 is related) passwd: files nis passwd: compat [NOTFOUND=continue] compat [NOTFOUND=continue] compat [NOTFOUND=continue] compat The latter is because libnss_nis appears to return notfound, not unavailable, so i was hoping to do multiple retries, but i'm not sure what i hoped to perform here is even doing what i wanted. Also: getent -s nis passwd joebob getent -s compat passwd joebob both exhibit the random failure/success (so, it's not just libnss_compat here) getent' is returning status code "2" (One or more supplied key could not be found in the database.) So, it seems to me that the common component here is libnss_nis.so. The machine this is running on is a rather beefy server: Dell PowerEdge R820 256GB RAM 4 x Intel(R) Xeon(R) CPU E5-4640 0 @ 2.40GHz This problem presents itself when the system is getting heavily loaded, so this seems like a race-condition somewhere. I may not be able to do much testing as the system is being emergently reconfigured to remove NIS dependency, but let me know if you need any further information/testing. btw, 'nscd' is NOT running, and with bug reports related to these libnss_nis/compat issues i see lots of folks saying 'nscd' made no difference, so i didn't test it. thanks, --stephen
Bug#775158: policykit-1: memory leak in polkit_authority_enumerate_actions_finish DBUS call results handler
On Fri, 16 Oct 2015 09:22:30 +0200 Michael Biebl <bi...@debian.org> wrote: > Hi, > > Am 16.10.2015 um 01:35 schrieb Stephen Dowdy: > > Is this fix going to be released for Jessie? I don't see it in > > jessie-proposed-updates, and it (i presume) is SEVERELY affecting some of > > my users: > > > We should fix this for jessie, yes. > Given the amount of important bug fixes that went into policykit-1 after > 0.105-8, I'm inclined to upload 0.105-12 as is to jessie. This didn't get into 8.4 -- could y'all PLEASE get it into 8.5? My users are being hit catastrophically by this bug (and sometimes by the systemd "looping" bug (789796) caused by OOMs from this bug and other OOM conditions), These bugs and others in Jessie (rpc/nis fails under systemd, etc) are creating a growing lack of confidence in KDE and Debian in general (I am a vocal Debian advocate and work hard to address these types of concerns for my users) In lieu of this bug being fixed, i either have to modify a package owned file, or have all users run a script to put an override version in their HOME kde directory (powerdevil.desktop) (neither is optimal, nor desired, especially on laptops where powerdevil is a more critical component) ( btw, Unfortunately, KDE, as distributed by Debian, maybe in kde.org, doesn't have an /etc/kde4 path for services :-( $ kde4-config --path services /home/sdowdy/.kde/share/kde4/services/:/usr/share/kde4/services/ ) Thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#783212: nfs-kernel-server: exportfs fails to set rw, ro, [no_]root_squash or [no_]squash_all flags in some cases
Can you please escalate fixing this in stable due to the security
implications of presuming an export record like:
/data -rw,... \
trustedhost untrustedhost(ro)
will "Do The Right Thing(tm)".
In Debian Jessie(current stable), without this being fixed, a system
upgrade from wheezy where this worked properly before now allows an
untrusted host to write to a filesystem it should not be allowed to.
same with defaulting "-no_root_squash... untrustedhost(root_squash)".
(we can argue if such an export is the best way to do this, but this bug
does introduce a legitimate security concern)
I don't want to wait several years for this awful bug to percolate back
down to stable on the next release.
My whole reliance on using export records of the form:
/export -{defaults} \
host1 host2 host3({overrides}) ...
Is because it is significantly clearer that you didn't mangle one host's
exports directives (you only have to look at the defaults ONCE), and you
can then create obvious deviations with the '()' form overrides. Breaking
the ability to create these clear and easily visually parsable stanzas
degrades security, IMHO.
Now i have to create multiple exports records with different "-{defaults}",
or put '({options})' on every single host export creating a more complex
exports environment prone to errors.
thanks,
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#775158: policykit-1: memory leak in polkit_authority_enumerate_actions_finish DBUS call results handler
FWIW, for anybody else having this issue, attached is an as-needed restart script for 'kded' that seems to work. (less onerous than the powerdevil disabler script, 'kded' seems to be restartable w/o incident from what i can tell) -- stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ kded-restart.sh Description: Bourne shell script
Bug#775158: policykit-1: memory leak in polkit_authority_enumerate_actions_finish DBUS call results handler
Okay, given that Jessie 8.4 is now coming soon, can we get this fix in, please! I have 20 desktops showing kded4 RAM usage upto 90%, having looked again because a user had an OOM that blew away their desktop over the weekend. (unless we have a better workaround than disabling powerdevil.desktop, which i'm not thrilled with, i'm going to have to globally deploy that, with the negative side-effects) thanks, --stephen On Sun, Dec 13, 2015 at 1:52 PM, Stephen Dowdy <sdo...@ucar.edu> wrote: > Status ping > > Given Jessie 8.3 update coming soon, what's the chance this will be fixed? > > thanks, > --stephen > > > -- > Stephen Dowdy - Systems Administrator - NCAR/RAL > 303.497.2869 - sdo...@ucar.edu- > http://www.ral.ucar.edu/~sdowdy/ > -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#803249: needrestart: Restarts services in debconf noninteractive
I believe the Felix is saying that 'needrestart' appears to be unaware of the common explicit DEBIAN_FRONTEND=noninteractive setting used to indicate that package management should be non-interactive (and if not, then *I* am) I will often use 'pdsh' to run forced package updates like so: $ cut -d: -f1 vulnerable.log | WCOLL=- pdsh -lroot 'aptitude update -q=2; DEBIAN_FRONTEND=noninteractive aptitude -q=2 safe-upgrade --assume-yes -o Dpkg::Options::="--force-confold" http://www.ral.ucar.edu/~sdowdy/
Bug#803249: needrestart: Restarts services in debconf noninteractive
Thomas,
Summary:
- using an auxiliary conf.d file seems to mostly work
- 'needrestart' should, however flag 'systemctl restart' notice with
'skipping' in this case?
- 'needrestart' should not prompt to read on 'consider
rebooting kernel' notification in this case
(hostname)# cat /etc/needrestart/conf.d/debian_frontend_noninteractive.conf
# Switch to list mode if debconf is running noninteractive
# Ref: Bug#803249: needrestart: Restarts services in debconf noninteractive
# Thomas Liske <tho...@fiasko-nw.net>
$nrconf{restart} = ( ($ENV{DEBIAN_FRONTEND} // '') eq 'noninteractive' ?
'l' : 'i');
1;
(changed it a tiny bit)
I ran an update on a system that hasn't been updated for quite some time,
with :
19 DEBIAN_FRONTEND=noninteractive aptitude upgrade 2>&1 | tee
/tmp/aptup.log
20 grep -i -e restart -e systemctl /tmp/aptup.log
and nothing appeared in the log. :-)
(hostname)# DEBIAN_FRONTEND='noninteractive' needrestart
Scanning processes...
Scanning candidates...
Scanning kernel images...
Services to be restarted:
Skipping dbus.service...
Skipping getty@tty1.service...
Skipping kdm.service...
Skipping NetworkManager.service...
Skipping systemd-journald.service...
systemctl restart acpid.service atd.service autofs.service
console-kit-daemon.service cron.service dirmngr.service gpm.service
inetd.service irqbalance.service mcelog.service mdmonitor.service
nfs-common.service nis.service packagekit.service polkitd.service
rpcbind.service sendmail.service smartd.service ssh.service udisks2.service
upower.service user@0.service user@115.service user@3619.service
Looks like it's in list-only mode (still disconcerting to see the
'systemctl restart' line without a "Skipping"/"DEBUG" or other flagging
prefix, but clearly it's not actually issuing restarts:
pomelo2:~# systemctl status acpid.service
* acpid.service - ACPI event daemon
Loaded: loaded (/lib/systemd/system/acpid.service; disabled)
Active: active (running) since Sat 2015-11-28 10:30:26 MST; 1 months 24
days ago
...
(hostname)# needrestart
Scanning processes...
Scanning candidates...
Scanning kernel images...
Graphic (curses) UI comes up, queries if i want to restart various services
(i hit CANCEL)
BUT!
(hostname)# DEBIAN_FRONTEND='noninteractive' needrestart -v
...
Restarting the system to load the new kernel will not be handled
automatically, so you should consider rebooting. [Return]
...
So, it still blocks there on a terminal read -- which it should not do if
we're truly noninteractive (but, it obviously "Does The Right Thing(tm)"if
stdin redirected from /dev/null. Just would be nice if it did NOT prompt
if it's non-interactive (even in verbose mode).
--stephen
On Fri, Jan 22, 2016 at 4:21 PM, Thomas Liske <tho...@fiasko-nw.net> wrote:
> Hi Stephen,
>
> On Fri, Jan 22, 2016 at 11:44:30AM -0700, Stephen Dowdy wrote:
> > I believe the Felix is saying that 'needrestart' appears to be unaware of
> > the common explicit DEBIAN_FRONTEND=noninteractive setting used to
> indicate
> > that package management should be non-interactive (and if not, then *I*
> am)
> >
> > I will often use 'pdsh' to run forced package updates like so:
> >
> > $ cut -d: -f1 vulnerable.log | WCOLL=- pdsh -lroot 'aptitude update -q=2;
> > DEBIAN_FRONTEND=noninteractive aptitude -q=2 safe-upgrade --assume-yes -o
> > Dpkg::Options::="--force-confold" >
> > Unfortunately, 'needrestart's 'isatty' style checks are insufficient for
> my
> > needs here, as STDERR/STDOUT are attached to a pty associated with the
> > 'ssh' hitting all the systems i am updating... I have no way of then
> > telling 'needrestart' to not restart services
> >
> > So, i unexpectedly got a bunch of systemctl restart invocations, and i
> find
> > that often borks things badly.
> >
> > If 'needrestart' could also check ${DEBIAN_FRONTEND}, that would be
> awesome.
> >
> > Otherwise, i suppose i will have to cfengine out a "Default No"
> > needrestart.conf configuration to all my systems.
>
> you could try to put something like
>
> cat < # Switch to list mode if debconf is running noninteractive
> $nrconf{restart} = (exists($ENV{DEBIAN_FRONTEND}) &&
> $ENV{DEBIAN_FRONTEND} eq 'noninteractive' ? 'l' : 'i');
>
> 1;
> EOF
>
> into /etc/needrestart/conf.d/noninteractive.conf. If it works we might
> should add it upstream...
>
>
> > So, indeed 'unattended-upgrades' runs are also triggering needrestart to
> > believe it is running interactively, and thus it restarts things.
> > 'unattended-upgrade' appears to buy into the "DEBIAN_FRONTEND" notion of
> > noninteractivity as well:
> >
> > # grep -i interactive /usr/bin/unattended-upgrade
> > # set debconf to
Bug#775158: policykit-1: memory leak in polkit_authority_enumerate_actions_finish DBUS call results handler
Status ping Given Jessie 8.3 update coming soon, what's the chance this will be fixed? thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#801428: pulseaudio: on stock workstation with normal left/right speakers, bass is stripped, unless using headphones jack
On Mon, Oct 12, 2015 at 10:59 AM, Stephen Dowdy <sdo...@ucar.edu> wrote: > I have not re-installed stock packages, rebooted, and confirmed that the > bass "disappearance" bug reverts. I'll check that later. Felipe, Still didn't get around to backing out to stock, but while i was thinking about it, what is the chance this updated libpulseaudio package might get into the Jessie 8.3 point update coming up in January? (let me know if you want me to backout to stock, to see if the problem recurs, but i suspect it will. I have been running my workstation with the backported libpulseaudio for months now, without problem, but i'm a limited functionality user (listen to music via Amarok through crummy speakers on my desktop at work)) thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#801428: pulseaudio: on stock workstation with normal left/right speakers, bass is stripped, unless using headphones jack
$ apt-cache policy pulseaudio
pulseaudio:
Installed: 7.1-2~bpo8+1
Candidate: 7.1-2~bpo8+1
Version table:
*** 7.1-2~bpo8+1 0
100 http://debian.rap.ucar.edu/ jessie-backports/main amd64 Packages
100 /var/lib/dpkg/status
5.0-13 0
500 http://debian.rap.ucar.edu/ jessie/main amd64 Packages
Ah, didn't notice that the .debs you had me download manually before
got pushed and updated into backports ;)
Btw, i'm also trying to push another memory leak bug with policykit
that causes 'kded' to consume all available physmem in short order.
it appears that they may be pulling in upstream to Jessie on that
(unless i'm reading wrong). OpenSSL is also looking like it's getting
similar treatment. I understand the issues behind stable release
platforms, and the idea behind backports, but the world is really
getting complicated faster and faster, and some of these bugs (esp the
Systemd MegaSAS timeout bug - now fixed) in Jessie are really throwing
some wrenches into our environment (admittedly, having "bass"
frequencies on audio (esp with headphone-jack workaround) is far less
important than being able to boot at all, but my users are definitely
complaining). I fully appreciate all the developers do on a volunteer
basis, so i don't want to sound like i'm demanding or expecting
anything. I really appreciate your prompt responses!
It would have been nice to figure out what was broken in the main
Jessie release version or pulseaudio (Can't believe we're the only
site having the problem.) We moved to pulseaudio, as we were having
different problems on some systems with whatever we were relying on
before (ALSA?), so, i guess we'll have to work out balancing our
corporate security policy ("security support" SLA type stuff) with apt
configurations that target specific packages from the backports repo.
Thanks, again!
--stephen
On Sun, Dec 13, 2015 at 2:11 PM, Felipe Sateler <fsate...@debian.org> wrote:
> Control: fixed -1 7.0-1
> Control: tags -1 - moreinfo
>
> Hi Stephen,
>
> On 13 December 2015 at 18:01, Stephen Dowdy <sdo...@ucar.edu> wrote:
>> On Mon, Oct 12, 2015 at 10:59 AM, Stephen Dowdy <sdo...@ucar.edu> wrote:
>>> I have not re-installed stock packages, rebooted, and confirmed that the
>>> bass "disappearance" bug reverts. I'll check that later.
>>
>>
>> Felipe,
>>
>> Still didn't get around to backing out to stock, but while i was
>> thinking about it, what is the chance this updated libpulseaudio
>> package might get into the Jessie 8.3 point update coming up in
>> January? (let me know if you want me to backout to stock, to see if
>> the problem recurs, but i suspect it will. I have been running my
>> workstation with the backported libpulseaudio for months now, without
>> problem, but i'm a limited functionality user (listen to music via
>> Amarok through crummy speakers on my desktop at work))
>
> Unfortunately, new upstream versions generally do not make it to
> stable updates (which is one reason there are backports). I suggest
> you keep using backports, I will continue to update that when new
> upstream versions are uploaded.
>
>
>
> --
>
> Saludos,
> Felipe Sateler
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#783594: openssh-server: sshd -T does not show actual kexchange and ciphers
Package: openssh-server Version: 1:6.7p1-5 Followup-For: Bug #783594 Dear Maintainer, The bug appears only if the Ciphers directive is missing and implied from program defaults: (i'm guessing that -T runs prior to proper full initialization of 'sshd') $ grep -i ciphers /etc/ssh/sshd_config $ $ sudo /usr/sbin/sshd -T | grep -i ciphers ciphers 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com -or- $ sudo /usr/sbin/sshd -f /dev/null -T | grep -i ciphers ciphers 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com If we explicitly specify the manpage defaults, '-T' functions as expected: $ echo 'Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com' | sudo /usr/sbin/sshd -T -f /dev/stdin | grep ciphers ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii dpkg 1.17.25 ii init-system-helpers1.22 ii libc6 2.19-18+deb8u1 ii libcomerr2 1.42.12-1.1 ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u1 ii libkrb5-3 1.12.1+dfsg-19+deb8u1 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpam0g 1.1.8-3.1 ii libselinux12.3-2 ii libssl1.0.01.0.1k-3+deb8u1 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian13+nmu1 ii openssh-client 1:6.7p1-5 ii openssh-sftp-server1:6.7p1-5 ii procps 2:3.3.9-9 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages openssh-server recommends: ii ncurses-term 5.9+20140913-1 ii xauth 1:1.0.9-1 Versions of packages openssh-server suggests: ii ksshaskpass [ssh-askpass] 0.5.3-1+b1 pn molly-guard pn monkeysphere pn rssh pn ufw -- debconf information excluded
Bug#775158: policykit-1: memory leak in polkit_authority_enumerate_actions_finish DBUS call results handler
Is this fix going to be released for Jessie? I don't see it in jessie-proposed-updates, and it (i presume) is SEVERELY affecting some of my users: System with default setup (80+% of 32GB RAM consumed by 'kded4' process) # ps -o "pid:6,ppid:6,%mem:4,rss:8,size:8=SSZ,sz:8=PSZ,vsize:8,args:20" $(pgrep kded4) PID PPID %MEM RSS SSZ PSZ VSZ COMMAND 1341 1 82.0 27030540 31969276 8150825 32603300 kdeinit4: kded4 [kdeinit] System where i've had user install a powerdevil.desktop service override disable file # ps -o "pid:6,ppid:6,%mem:4,rss:8,size:8=SSZ,sz:8=PSZ,vsize:8,args:20" $(pgrep kded4) PID PPID %MEM RSS SSZ PSZ VSZ COMMAND 1337 1 0.270972 2221556 710202 2840808 kdeinit4: kded4 [kdeinit] FWIW, including disabler script for user override (in lieu of doing at the system level) in case anyone is interested. Dunno if this is the best way for users to disable powerdevil, but "It Works For Me(tm)" thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ disable-powerdevil.sh Description: Bourne shell script
Bug#801428: pulseaudio: on stock workstation with normal left/right speakers, bass is stripped, unless using headphones jack
Felipe, progress :) sdowdy@resonance$ aptitude search --disable-columns -F '%p %v' ~ilibpulse ~ipulseaudio | column -t libpulse-mainloop-glib0 7.0-1~bpo8+1 libpulse07.0-1~bpo8+1 libpulsedsp 7.0-1~bpo8+1 pulseaudio 7.0-1~bpo8+1 pulseaudio-utils 7.0-1~bpo8+1 I installed these and rebooted, and it appears the bass is working with this setup, at least for my aging ears. (i don't have a frequency analyzer, just listening to music through my crummy desktop speakers) If i switch the port to "headphones" in pavucontrol, it continues to play out line-out (where i have the jack for the external speakers), but the volume drops from 68% to 57%. (it was altering the volume a slight amount before, and maybe there's a save volume on a per-port basis that is being recalled?) Anyway, the equalization doesn't appear to be altered, so the bass stays consistent, which is good. In 'veromix', if i add the multi-band EQ plugin, it has no effect on sound, however. I was only playing with that earlier in an effort to determine what was wrong with the bass. probably not something i'll be playing with personally, but thought i'd add that bit. (i don't know if it was working or not in stock pulseaudio). I have not re-installed stock packages, rebooted, and confirmed that the bass "disappearance" bug reverts. I'll check that later. thanks, --stephen On Sat, Oct 10, 2015 at 6:46 PM, Stephen Dowdy <sdo...@ucar.edu> wrote: > > On Sat, Oct 10, 2015 at 9:50 AM, Felipe Sateler <fsate...@debian.org> > wrote: > >> Yes, that's what I'd expect too. I have uploaded a backport of >> pulseaudio 7 (that has changed the mappings a bit, so this may be >> fixed). Unfortunately it has not been accepted yet, but you could >> install manually from here: >> >> >> http://debomatic-amd64.debian.net/distribution#jessie-backports/pulseaudio/7.0-1~bpo8+1 >> >> >> >> Please report if the problem also occurs there. >> > > Felipe, > > Cool, i will give this a try when i get back into the office, Monday. > Thanks for the prompt responses! > > --stephen > > > > -- > Stephen Dowdy - Systems Administrator - NCAR/RAL > 303.497.2869 - sdo...@ucar.edu- > http://www.ral.ucar.edu/~sdowdy/ > > > -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#801428: pulseaudio: on stock workstation with normal left/right speakers, bass is stripped, unless using headphones jack
On Sat, Oct 10, 2015 at 6:42 AM, Felipe Sateler <fsate...@debian.org> wrote: > I don't understand. Do you mean that if you plug into headphone jack > you do not have this problem? And that the problem only reveals itself > after plugging the speakers into the line-out jack and selecting Line > Out / Speakers / Analog Output port[1]? > > [1] This being worse because one of these is selected by default? > Felipe, I have not tried headphones themselves, but if i plug the external speakers into the headphone jack on the workstation, the problem disappears. Also, if i select the headphone "port" in software (pavucontrol) while the external speakers are still plugged into the line-out jack (either front or back jack of my system, a Dell Precision Workstation, the problem goes away, as well. If i move the external speakers from the headphone jack back to the line-out jack, the automatic jack selection code reverts to the "No Bass" situation. (but, again, i can manually "fix" it, by selecting the headphone port in pavucontrol. I'd *expect* that to route the sound through the headphone jack, and i should hear *nothing* at that point, but that's not the case). thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#801428: pulseaudio: on stock workstation with normal left/right speakers, bass is stripped, unless using headphones jack
On Sat, Oct 10, 2015 at 9:50 AM, Felipe Sateler <fsate...@debian.org> wrote: > Yes, that's what I'd expect too. I have uploaded a backport of > pulseaudio 7 (that has changed the mappings a bit, so this may be > fixed). Unfortunately it has not been accepted yet, but you could > install manually from here: > > > http://debomatic-amd64.debian.net/distribution#jessie-backports/pulseaudio/7.0-1~bpo8+1 > > > > Please report if the problem also occurs there. > Felipe, Cool, i will give this a try when i get back into the office, Monday. Thanks for the prompt responses! --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#801428: pulseaudio: on stock workstation with normal left/right speakers, bass is stripped, unless using headphones jack
Package: pulseaudio
Version: 5.0-13
Severity: normal
Dear Maintainer,
I have several systems of users, including my own, where bass is
stripped/subdued/remixed/whatever making it really hard to enjoy listening.
I have discovered that if i plug my external speakers into the headphone jack,
or if it leave it plugged into the rear or front line-out jacks, but select the
port "analog-output-headphones" in pavucontrol "Output Devices" tab under
"Built-in Audio Analog Stereo", Port: selection list, the bass mysteriously
comes back
(even if the speakers are plugged into the "Line Out (plugged in)", and i
select "Headphones (unplugged)" the audio continues to go out Line-Out, but the
bass is restored)
("Line Out", "Speakers", "Analog Output" all produce the same "No Bass" results)
The whole world of linux audio, especially layering on pulseaudio is utter
voodoo to me, so i'm not sure if this is a configuration issue (it's stock
default Jessie) a bug in the pulseaudio system or what.
I have tried playing with changing the daemon.conf 'remix' settings to no avail
(issuing 'pulseaudio --kill' and restarting amarok to reset all players)
enable-remixing = yes
enable-lfe-remixing = no (tried = yes, as well)
as well as forcing:
default-sample-channels = 2
thanks,
--stephen
-- Package-specific info:
File '/etc/default/pulseaudio' does not exist
-- System Information:
Debian Release: 8.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages pulseaudio depends on:
ii adduser 3.113+nmu3
ii libasound21.0.28-1
ii libasound2-plugins1.0.28-1+b1
ii libc6 2.19-18+deb8u1
ii libcap2 1:2.24-8
ii libdbus-1-3 1.8.20-0+deb8u1
ii libfftw3-single3 3.3.4-2
ii libgcc1 1:4.9.2-10
ii libice6 2:1.0.9-1+b1
ii libltdl7 2.4.2-1.11
ii liborc-0.4-0 1:0.4.22-1
ii libpulse0 5.0-13
ii libsamplerate00.1.8-8
ii libsm62:1.2.2-1+b1
ii libsndfile1 1.0.25-9.1
ii libspeexdsp1 1.2~rc1.2-1
ii libstdc++64.9.2-10
ii libsystemd0 215-17+deb8u2
ii libtdb1 1.3.1-1
ii libudev1 215-17+deb8u2
ii libwebrtc-audio-processing-0 0.1-3
ii libx11-6 2:1.6.2-3
ii libx11-xcb1 2:1.6.2-3
ii libxcb1 1.10-3+b1
ii libxtst6 2:1.2.2-1+b1
ii lsb-base 4.1+Debian13+nmu1
ii pulseaudio-utils 5.0-13
ii udev 215-17+deb8u2
Versions of packages pulseaudio recommends:
pn pulseaudio-module-x11
pn rtkit
Versions of packages pulseaudio suggests:
ii paman0.9.4-1
pn paprefs
ii pavucontrol 2.0-3
ii pavumeter0.9.3-4
-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.
## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out. Use either ; or # for
## commenting.
; default-sink =
; default-source =
; default-server =
; default-dbus-server =
; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog
; cookie-file =
; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64
MiB
; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied
Bug#797952: libc6: getpwnam() returns a malformed /etc/passwd entry as valid
Package: libc6 Severity: normal Tags: upstream Dear Maintainer, I'm not quite sure how/where to report this bug, but it certainly seems to apply to upstream as the same symptoms occur on REDHAT 5.x (it also applies to Wheezy, but still exists in Jessie, so reporting here) We had a malformed NIS passwd entry (NIS is not relevant in bug) where the field-separator (:) was missing between homedir and shell fields. E.g: # grep sdowdy2 /etc/passwd sdowdy2:x:8859:1500:Stephen Dowdy:/home/sdowdy/bin/bash --^ (missing : delimiter between homedir and shell) # simply C executable calling getpwnam(argv[1]) and printing struct values jlab-core1:~# ./getpwnam sdowdy2 name = sdowdy2 password = x uid = 8859 gid = 1500 real name = Stephen Dowdy home directory = /home/sdowdy/bin/bash shell program = IMHO, from everything i see, (incl passwd(5)), ':' characters are NOT optional in /etc/passwd, but this record is missing one. I think the best response by getpwnam would be ENOENT, because there exists NO RECORD (no *valid* record) for that user, as the record is, again, malformed. When coupled with 'pam_mkhomedir', this resulted in the user being able to login, with a /bin/sh shell (this is defined behaviour if the shell field is empty, which it technically is NOT, as the shell field does not exist at all), but by creating an incorrect homedir of /home/sdowdy/bin/bash (sigh). It could be argued that coupling with the right set of PAM modules and the right (wrong) set of mistakes in a passwd entry, this could be a significant security issue. (i set status of the bug as normal, but feel free to elevate it) By whittling away, it seems that any passwd file record that contains a minimum of: username:password:uid:gid (note the trailing : is not needed for GID field, but upto and including gid are necessary, or else a NULL pointer is returned with errno set SUCCESS!) is parsed (improperly i might say) and returned with remaining fields blank, making it look as though all the remaining fields and their delimiters are optional. Again, the section 5 manpage for 'passwd' seems pretty clear that ':'s are not optional. (it only mentions that the shell field contents are optional) >From my best guesses 'pwd/fgetpwent_r.c' is where the problem exists in not >validating the record as having a required 6 ':'s separating the 7 fields, and >not apparently scanning the whole record for each one and ensuring each was >found. fwiw, 'pwck' does detect an illegal entry, though it doesn't report a reason: invalid password file entry delete line 'sdowdy2:x:8859:1500:Stephen Dowdy:/home/sdowdy/bin/bash'? No Also, 'passwd(1)' throws an exception on this malformed account: passwd: User not known to underlying authentication module. passwd: password unchanged. thanks, --stephen -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#787191: Bug#776192: Linux null-pointer deref in 3.16.7-ctk2-1
Michael, I grabbed https://people.debian.org/~biebl/udev/test0/libudev1_215-17+deb8u2~test0_amd64.deb https://people.debian.org/%7Ebiebl/udev/test0/libudev1_215-17+deb8u2%7Etest0_amd64.deb https://people.debian.org/~biebl/udev/test0/udev_215-17+deb8u2~test0_amd64.deb https://people.debian.org/%7Ebiebl/udev/test0/udev_215-17+deb8u2%7Etest0_amd64.deb https://people.debian.org/~biebl/udev/test1/libudev1_215-17+deb8u2~test1_amd64.deb https://people.debian.org/%7Ebiebl/udev/test1/libudev1_215-17+deb8u2%7Etest1_amd64.deb https://people.debian.org/~biebl/udev/test1/udev_215-17+deb8u2~test1_amd64.deb https://people.debian.org/%7Ebiebl/udev/test1/udev_215-17+deb8u2%7Etest1_amd64.deb I presume you want me to test these testN pairs independently -- as there are TWO candidate fixes we're testing? I'll start with the 'test1' pair first then. Sorry this took so long. we'd been debugging and broke out the SAS 6i/R setup to do two standalone disks with MD RAID in an attempt to see if the controller would respond sooner if it wasn't HW RAID-1, so i had to put the system back together. Due to lots of issues, this took a lot longer. I discovered, that our FAI server, which i thought was not using systemd-udevd, is in fact using that. But, it is a hit/miss whether the system hits the bug or not, leading to an occasional window where the system can get installed (booting the installed OS is always a no-go, however, so something in the FAI environment is giving us a slight edge). Also, i had to fight with residual turds from the MD RAID install borking my FAI install -- blowing away all the partitions, 'wipefs', etc weren't working, anyway that's all over So in the fai install at the final block before reboot to installed-OS, i did: - root@hammett:/tmp/fai# chroot /target # cd /root # ls hammett-jessie-fai.dpkg README.FAI sfdisk.out tmp udev-fixes # cd udev-fixes # ls getit test0 test1 # cd test1 # ls libudev1_215-17+deb8u2~test1_amd64.deb udev_215-17+deb8u2~test1_amd64.deb X Y # dpkg -i libudev1_215-17+deb8u2~test1_amd64.deb udev_215-17+deb8u2~test1_amd64.deb (Reading database ... 251068 files and directories currently installed.) Preparing to unpack libudev1_215-17+deb8u2~test1_amd64.deb ... Unpacking libudev1:amd64 (215-17+deb8u2~test1) over (215-17+deb8u1) ... Preparing to unpack udev_215-17+deb8u2~test1_amd64.deb ... Unpacking udev (215-17+deb8u2~test1) over (215-17+deb8u1) ... Setting up libudev1:amd64 (215-17+deb8u2~test1) ... Setting up udev (215-17+deb8u2~test1) ... A chroot environment has been detected, udev not started. A chroot environment has been detected, udev not started. update-initramfs: deferring update (trigger activated) Processing triggers for systemd (215-17+deb8u1) ... Processing triggers for man-db (2.7.0.2-5) ... Processing triggers for libc-bin (2.19-18) ... Processing triggers for initramfs-tools (0.120) ... update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64 - The system DOES boot successfully, after a long pause (as expected)... but it DOES boot. I am going to reboot a few more times with this setup (test1) to make sure it's consistent, and then try installing the 'test0' pair of .debs and get back to you, but i wanted to confirm that at least on initial glance, the 'test1' .debs solve my problem. --stephen On Fri, Aug 28, 2015 at 2:26 PM, Michael Biebl bi...@debian.org wrote: Am 28.08.2015 um 21:41 schrieb Stephen Dowdy: I've not built debian source package stuff before, and wasn't quickly able to determine how to even do it on the systemd-215 download, so prebuilt packages for amd64 would help greatly. I'm also not entirely sure if this is happening in the initrd level or in the /lib/systemd/systemd-udevd, so can i simply extract the 'systemd-udevd' from your package and drop onto the target disk directory, or should i 'dpkg -i' on it from the chroot of my FAI install before reboot, or do i need to run a mkinitramfs or some other higher-level debian initrd rebuild binary? Just let me know what i need to do to if it involves something more complex than either a pgk-disk extraction or 'dpkg -i' I've uploaded test packages to https://people.debian.org/~biebl/udev/ The one in the test0 folder have the patch for udev-event.c, the on in test1 have the patch for udevd.c Download the udev and libudev1 deb and install them via dpkg -i. Please let me know, if the test0 or test1 package works. Simply installing the packages via dpkg will be enough for having the initrd regenerated. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ On Fri, Aug 28, 2015 at 2
Bug#787191: Bug#776192: Linux null-pointer deref in 3.16.7-ctk2-1
On Fri, Aug 28, 2015 at 4:52 PM, Stephen Dowdy sdo...@ucar.edu wrote:
The system DOES boot successfully, after a long pause (as expected)...
but it DOES boot. I am going to reboot a few more times with this setup
(test1) to make sure it's consistent, and then try installing the 'test0'
pair of .debs
and get back to you, but i wanted to confirm that at least on initial
glance, the 'test1' .debs solve my problem.
Michael,
'test0' does NOT boot -- same symptoms as stock system. (stacktrace thrown
about 30 seconds from boot)
i rebooted into PXE FAI startup, /target-mounted the system's disks, and
redid the 'dpkg -i' for the 'test1' debs.
I've rebooted successfully into 'test1' eight times now. FWIW, the LSI SAS
6/iR responds at about 32 seconds into the boot (just past the
arbitrary/too-short 30 second default imposed upstream)
[1.687440] ioc0: LSISAS1068E B3: Capabilities={Initiator}
[1.923382] tsc: Refined TSC clocksource calibration: 2666.666 MHz
[2.923839] Switched to clocksource tsc
[4.003537] floppy0: no floppy controllers found
[ 32.500534] scsi6 : ioc0: LSISAS1068E B3, FwRev=00192f00h, Ports=1,
MaxQ=266, IRQ=28
[ 32.536560] mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 8,
phy 0, sas_addr 0x5000cca0091a71e5
[ 32.538335] scsi 6:0:0:0: Direct-Access HITACHI HUS154545VLS300
D590 PQ: 0 ANSI: 5
[ 32.543522] scsi 6:0:0:0: Attached scsi generic sg2 type 0
[ 32.545641] mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1,
phy 1, sas_addr 0x5000cca0091692bd
[ 32.547383] scsi 6:0:1:0: Direct-Access HITACHI HUS154545VLS300
D590 PQ: 0 ANSI: 5
[ 32.552451] scsi 6:0:1:0: Attached scsi generic sg3 type 0
[ 32.554726] mptsas: ioc0: attaching raid volume, channel 1, id 0
[ 32.555715] scsi 6:1:0:0: Direct-Access Dell VIRTUAL DISK
1028 PQ: 0 ANSI: 5
[ 32.563821] scsi 6:1:0:0: Attached scsi generic sg4 type 0
[ 32.612706] sd 6:1:0:0: [sda] 877920256 512-byte logical blocks: (449
GB/418 GiB)
[ 32.613456] sd 6:1:0:0: [sda] Write Protect is off
[ 32.613563] sd 6:1:0:0: [sda] Mode Sense: 03 00 00 08
[ 32.613757] sd 6:1:0:0: [sda] No Caching mode page found
[ 32.613865] sd 6:1:0:0: [sda] Assuming drive cache: write through
[ 32.648782] sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10
Thanks for your assistance here -- i really hope we can get this into
Jessie 8.2!
--
stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#787191: Bug#776192: Linux null-pointer deref in 3.16.7-ctk2-1
On Fri, Aug 28, 2015 at 1:22 PM, Michael Biebl bi...@debian.org wrote: Anyone willing to test this patch? I can provide pre-built packages for i386 and amd64. Note: if we want to get this into 8.2, this should happen quickly. The deadline for 8.2. is this weekend. Yes, more than happy to. I have the non-booting dual-SAS RAID1 SAS 6/iR setup on the workbench right now... (we still believe that all our SATA disk based SAS 5/6 systems are working fine, it appears to just be the SAS disk ones that have the problem, but they are all mostly RAID1 setups) I've not built debian source package stuff before, and wasn't quickly able to determine how to even do it on the systemd-215 download, so prebuilt packages for amd64 would help greatly. I'm also not entirely sure if this is happening in the initrd level or in the /lib/systemd/systemd-udevd, so can i simply extract the 'systemd-udevd' from your package and drop onto the target disk directory, or should i 'dpkg -i' on it from the chroot of my FAI install before reboot, or do i need to run a mkinitramfs or some other higher-level debian initrd rebuild binary? Just let me know what i need to do to if it involves something more complex than either a pgk-disk extraction or 'dpkg -i' thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#787191: Bug#776192: Linux null-pointer deref in 3.16.7-ctk2-1 (was: Bug#776192: upgrade-reports wheezy to jessie boot problem)
Please, oh please, oh, please, can you get this in before 8.2 ?? I'm dealing with this problem yet again today, as another failed Jessie install was done by someone else on an affected system (it's now currently non-booting with no known workaround using stock Jessie). --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#787130: policykit-1: man page for pklocalauthority.8.gz contains 8-bit chars that don't work well with 'man' kioslave
Package: policykit-1
Version: 0.105-8
Severity: minor
Dear Maintainer,
using command line 'man' doesn't show the problem in a normal terminal, but
kman () { kfmclient newTab man:$@ ;}
kman pklocalauthority
shows that the ascii graphic representation of the filesystem hierarchies in
section EVALUATION ORDER contains accented 8-bit characters instead of simple
line drawing characters as the filesystem hierarchies in the section DIRECTORY
STRUCTURE shows.
Please note, i have a debsums failure (below), because i HAND-EDITING my copy
of that man page source so i could get a nice pretty-print from the 'man'
kioslave in konqueror.
e.g:
DIRECTORY STRUCTURE section:
.nf
/etc/polkit\-1/
`\-\- localauthority
|\-\- 10\-vendor\.d
|\-\- 20\-org\.d
|\-\- 30\-site\.d
|\-\- 50\-local\.d
`\-\- 90\-mandatory\.d
EVALUATION ORDER section:
.nf
/var/lib/polkit\-1
â~T~Tâ~T~@â~T~@ localauthority
â~T~\â~T~@â~T~@ 10\-vendor\.d
â~T~B â~T~Tâ~T~@â~T~@ 10\-desktop\-policy\.pkla
â~T~\â~T~@â~T~@ 20\-org\.d
â~T~\â~T~@â~T~@ 30\-site\.d
â~T~\â~T~@â~T~@ 50\-local\.d
â~T~\â~T~@â~T~@ 55\-org\.my\.company\.d
â~T~B â~T~Tâ~T~@â~T~@ 10\-org\.my\.company\.product\.pkla
â~T~Tâ~T~@â~T~@ 90\-mandatory\.d
The above 8-bit characters seem to get normalized to line-draw with command
line 'man', but also appear not to be translatable with 'uni2ascii -B' or
'iconv -c -f utf8 -t ascii'.
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages policykit-1 depends on:
ii dbus 1.8.16-1
ii libc6 2.19-18
ii libglib2.0-0 2.42.1-1
ii libpam-systemd 215-17
ii libpam0g 1.1.8-3.1
ii libpolkit-agent-1-00.105-8
ii libpolkit-backend-1-0 0.105-8
ii libpolkit-gobject-1-0 0.105-8
policykit-1 recommends no packages.
policykit-1 suggests no packages.
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/share/man/man8/pklocalauthority.8.gz (from
policykit-1 package)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785060: kprinter4.desktop file should use 'Exec=kprinter4 --openfiledialog'
Package: kprinter4 Version: 12-1 Severity: normal Dear Maintainer, Because users searching in 'kickoff' for 'print' (hey, what do i use to print my files? Maybe searching for 'print' will tell me) will see 'kprinter4' and attempting to launch it will result in seeing nothing appear but 'bouncy-cursor' (presumption: application doesn't work.) If 'kprinter4' is launched with '--openfiledialog' from 'Exec' statement in .desktop file, it will be much more useful in most circumstances. (as i can see no way the .desktop file is useful in current form, as it doesn't even use %-variable-expansion if a file were passed to it.) I suppose to do this properly might even require two or more desktop files presenting like: 1) kprinter4 (file chooser) [ Exec:kprinter4 --openfiledialog ] 2) kprinter4 (stdin) [ Exec:kprinter4 --stdin ] (i'm still not sure what use such a .desktop would provide) From below: -- debsums errors found: debsums: changed file /usr/share/applications/kde4/kprinter4.desktop (from kprinter4 package) NOTE: Yeah, because i already changed mine. Unfortunately, there's no support in the default KDE setup in Debian for /etc/kde4/... site overrides. (we use /usr/local/ on NFS shared server, but it's not consistent to all of our systems, whereas cfengine to /etc/kde4 would work much better for us) thanks, --stephen -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kprinter4 depends on: ii ghostscript 9.06~dfsg-2 ii kde-runtime 4:4.14.2-2 ii libc62.19-18 ii libgcc1 1:4.9.2-10 ii libkcmutils4 4:4.14.2-5 ii libkdecore5 4:4.14.2-5 ii libkdeui54:4.14.2-5 ii libkemoticons4 4:4.14.2-5 ii libkidletime44:4.14.2-5 ii libkio5 4:4.14.2-5 ii libkprintutils4 4:4.14.2-5 ii libkutils4 4:4.14.2-5 ii libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqt4-svg 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqtgui44:4.8.6+git64-g5dc8b2b+dfsg-3 ii libspectre1 0.2.7-3 ii libstdc++6 4.9.2-10 ii psutils 1.17.dfsg-2 kprinter4 recommends no packages. kprinter4 suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/share/applications/kde4/kprinter4.desktop (from kprinter4 package) *** NOTE: Yeah, because i already changed mine. Unfortunately, there's no support in the default KDE setup in Debian for /etc/kde4/... site overrides. (we use /usr/local/ on NFS shared server, but it's not consistent to all of our systems) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776192: mptsas probe failure and crash, probably related to udev timeout
This reply is purely to assist any other poor souls like myself who have to suffer the fallout from this problem with a possible non-code-hack-related workaround for *SOME* configurations. We have two mptsas desktop systems one of which failed to boot after Jessie FAI install. The other had been running for weeks w/o incident. working system: Dell Precision T5400, SAS 6/iR in RAID1 with 2 Seagate SATA disks (ST3500641AS ST3500418AS) nonworking system: Dell Precision T3500, SAS 6/iR with RAID1 using 2 Fujitsu SAS drives (MBA3147RC) and one pass-thru Hitachi SAS drive (HUS154545VLS300). It was discovered that that working system had the drives connected to the high-port connector (ports 4-7), while the non-working system had them more-obviously connected to the low-port connector (ports 0-3). After moving the cabling to the high-ports on the non-working system, it now boots. It still takes a LONG time to probe the disks (maybe 20+ secs), but it's apparently within limits. The other working system doesn't pause during probe at all, so this may be a SATA vs SAS thing or a drive-vendor/model thing, too.. The only fallout (possibly unrelated) is that a shutdown results in a hang after the final shutdown message requiring a manual power-off (haven't done other tests, could be a fluke). We used to have that issue on Precision 390/490/690 systems and had some success with kernel bootline 'reboot=bios' (IIRC). We haven't installed any other T3500s yet, so maybe this is common? This unfortunately, isn't a solution for the Integrated MPTSAS cards in Dell's 1U 9th gen servers (e.g. PE 1950) while the card guts appear the same (just without the L-bracket) -- those systems' BIOS throw an error if you attach the internal drive cabling to the high-port connector. (it throws something like Invalid Disk Configuration) That seems like some arbitrary BIOS constraint Dell put in. (this is from memory of trying to do this config when i had a too-short lead cable to the drives that it wouldn't reach the low-port connector in the past) It's also probably not a solution for folks who have 4 drives. I'm also not sure if i added another drive if it'd suddenly stop working again. But, for anyone else out there with a similar configuration, this may save you. IMHO -- this problem is going to hit a lot of people -- it affects at least 50 of my machines (i actually have several hundred PowerEdge server systems with SAS 5/6 controllers, but most of those are running RHEL5/6) -- I think it is truly absurd that the systemd devs refuse to provide a bootline option to increase the event timeout or even to increase the hardcode value for a limited time. The decree that 30 seconds is absolute and long-enough reminds me of such lack of insight as noone will ever need more than 640K of RAM. It is simple arrogance to pull a random number and refuse to budge on it knowing full well that changing that number ever so slightly would enable a lot more systems to run, regardless of the bugs in the mptsas code. Then you can revisit the problem after the mptsas code gets fixed (and hopefully that actually happens soon). Really, how often is 30 vs 60 vs 180 seconds going to make over the entire planet anyway? If something is truly really busted, you'll find out about it. having an arbitrary 30 second limitation isn't going to help those people with real busted hardware/kernelmods -- it's just hurting an audience of people stuck with non-optimal drivers/hardware that were working perfectly well (enough) prior to these changes. thanks --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Bug#780738: netfilter-persistent: failure to shortcircuit on ipv6.disabled=1 results in degraded systemd system
Package: netfilter-persistent Version: 1.0.3 Followup-For: Bug #780738 -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages netfilter-persistent depends on: ii init-system-helpers 1.22 ii lsb-base 4.1+Debian13+nmu1 netfilter-persistent recommends no packages. netfilter-persistent suggests no packages. -- no debconf information If IPv6 is disabled, then netfilter-persistent should fail to attempt to load any rules.v6 file, regardless of their existence, because otherwise failures cascade into many other places. (systemd believes it is in a degraded state due to service failure, needrestart fails to run from dpkg failures related...) Please shortcircuit any IPv6 conditionals based upon /proc/sys/net/ipv6 non-existence as recommended by original bug report. sdowdy-jessie-vm:~# cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=797c2b0f-fb63-4857-9b73-f67a9d4eed31 ro ipv6.disable=1 sdowdy-jessie-vm:~# systemctl status netfilter-persistent * netfilter-persistent.service - netfilter persistent configuration Loaded: loaded (/lib/systemd/system/netfilter-persistent.service; enabled) Active: failed (Result: exit-code) since Mon 2015-04-20 16:58:50 MDT; 56s ago Process: 20901 ExecStart=/usr/sbin/netfilter-persistent start (code=exited, status=1/FAILURE) Main PID: 20901 (code=exited, status=1/FAILURE) Apr 20 16:58:50 sdowdy-jessie-vm netfilter-persistent[20901]: run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables start Apr 20 16:58:50 sdowdy-jessie-vm netfilter-persistent[20901]: run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables start Apr 20 16:58:50 sdowdy-jessie-vm netfilter-persistent[20901]: run-parts: /usr/share/netfilter-persistent/plugins.d/25-ip6tables exited with return code 2 Apr 20 16:58:50 sdowdy-jessie-vm systemd[1]: netfilter-persistent.service: main process exited, code=exited, status=1/FAILURE Apr 20 16:58:50 sdowdy-jessie-vm systemd[1]: Failed to start netfilter persistent configuration. Apr 20 16:58:50 sdowdy-jessie-vm systemd[1]: Unit netfilter-persistent.service entered failed state. file /etc/iptables/rules.v6 accidentally created when not thinking in dpkg dialog during package updates by asking to save IPv6 rules. dowdy-jessie-vm:~# cat /etc/iptables/rules.v6 # Generated by ip6tables-save v1.4.21 on Tue Dec 9 20:17:39 2014 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Tue Dec 9 20:17:39 2014 aptitude safe-upgrade with needrestart borks: needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) Failed to perform requested operation on package. Trying to recover: Setting up netfilter-persistent (1.0.3) ... update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults Job for netfilter-persistent.service failed. See 'systemctl status netfilter-persistent.service' and 'journalctl -xn' for details. invoke-rc.d: initscript netfilter-persistent, action start failed. dpkg: error processing package netfilter-persistent (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of iptables-persistent: iptables-persistent depends on netfilter-persistent (= 1.0.3); however: Package netfilter-persistent is not configured yet. dpkg: error processing package iptables-persistent (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: netfilter-persistent iptables-persistent Current status: 39 updates [-552]. sdowdy-jessie-vm:~# systemctl is-system-running degraded sdowdy-jessie-vm:~# systemctl list-units --state=,failed, --no-legend netfilter-persistent.service loaded failed failed netfilter persistent configuration -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782507: libxrender1: i386/amd64 packages not co-installable
Interestingly, 'aptitude upgrade' installs both these packages w/o as much as a warning. (i have unattended-upgrades failing over this. Unfortunately, unattended-upgrades isn't e-mailing me on this failure as i would expect) Does this mean that 'aptitude' is not fully Multi-Arch aware/compliant? sigh. Anyway, 'aptitude upgrade' at least appears to be another temporary workaround to getting past this snafu. $ pdsh -lroot -g unattended-upgrade-desktops pdsh aptitude update -q=2; DEBIAN_FRONTEND=noninteractive aptitude -q=2 safe-upgrade --assume-yes -o Dpkg::Options::=--force-confold /dev/null --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776904: please mark chromium as unsupported in wheezy
(Holger: thanks for submitting bug, i was about to, but realized 'debian-security-support' is not in wheezy base, but in backports) Make that in wheezy-backports, and jessie, too. # lsb_release -cs wheezy # apt-cache policy debian-security-support debian-security-support: Installed: 2014.09.07~bpo70+1 Candidate: 2014.09.07~bpo70+1 Version table: *** 2014.09.07~bpo70+1 0 100 http://MY-REPO-MIRROR/ wheezy-backports/main amd64 Packages 100 /var/lib/dpkg/status # grep -i chromium /usr/share/debian-security-support/* # However, this applies as well to Jessie: # grep -i chromium /usr/share/debian-security-support/* # lsb_release -cs jessie # apt-cache policy debian-security-support debian-security-support: Installed: 2014.12.17 Candidate: 2014.12.17 Version table: *** 2014.12.17 0 500 http://MY-REPO-MIRROR/ jessie/main amd64 Packages 100 /var/lib/dpkg/status # grep -i chromium /usr/share/debian-security-support/* # thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763405: base-files: inclusion of /mnt in package can result in failures for systems where /mnt is ESTALE
I guess the question i have here is... is /mnt being *USED* within the install at all, OTHER than by being an empty sub within the tarchive payload in the .deb ? Does dpkg, etc use /mnt for temporary extraction or as part of the postinstall infrastructure? Because if it doesn't -- making sure it's not in base-files .deb would solve my problem. I don't recall other packages having this blocking issue, but i could not swear to that. Anyway, i appreciate you looking at the issue, but if indeed, /mnt is a core component of debian's installation infrastructure (which i could argue is a security flaw in the design, as that directory hierarchy gets littered with automount garbage), then i will concede on the bug report, and you can close it, and i will re-iterate to my fellow sysadmins to not use it for temporary mounts anymore. (if you could please respond definitively that /mnt is indeed a core component/requirement of Debian's package management, i'd appreciate it) thanks, again, --stephen On Thu, Oct 9, 2014 at 9:00 PM, Guillem Jover guil...@debian.org wrote: Hi! On Thu, 2014-10-09 at 20:55:33 +0200, Santiago Vila wrote: On Mon, 29 Sep 2014, Stephen Dowdy wrote: Package: base-files Version: 7.1wheezy6 Severity: normal Since sysadmins tend to (and are often told to) use /mnt for temporary mounts, and sometimes forget those mounts and they go stale (nfs), a package (in this case 'base-files') that includes /mnt in the files section will result in a complete failure to install. […] Preparing to replace base-files 7.1wheezy2 (using .../base-files_7.1wheezy6_amd64.deb) ... -- Unpacking replacement base-files ... dpkg: error processing /var/cache/apt/archives/base-files_7.1wheezy6_amd64.deb (--unpack): -- unable to stat `./mnt' (which I was about to install): Stale NFS file handle Errors were encountered while processing: /var/cache/apt/archives/base-files_7.1wheezy6_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: SERVER:~# ls /mnt ls: cannot access /mnt: Stale NFS file handle (d'oh sysadmin mounted other server months ago, which is now ESTALE, but should not result in a fatal install failure in base-files) SERVER:X# dpkg --fsys-tarfile - /var/cache/apt/archives/base-files_7.1wheezy6_amd64.deb | tar tvf - | grep /mnt -- drwxr-xr-x root/root 0 2014-06-11 21:07 ./mnt/ I see the problem, and I see how dropping /mnt from base-files.deb (and creating it in the postinst) would make the problem to disappear. I'm not sure it would, if this fails for dpkg, I'm expecting this would fail for mkdir or stat or any other programs run from the maintainer script as well. But I'm not sure that this is a bug in base-files. I don't think it is, neither in dpkg. Could this be fixed in dpkg, or maybe dpkg has good reasons to fail in cases like this one? dpkg needs to know what type of object a pathname is, to be able to decide if it needs to replace it or update its metadata, etc. The ESTALE pathname might be just up in the hierarchy, and dpkg might be trying to access somehting lower, say /usr (ESTALE), and dpkg wants to update «/usr/share/doc/pkg/copyright». dpkg cannot know which paths might be mouned on NFS, because any could be. In the end, this is a just a system administration issue. In the same way that a setup might have RO filesystems, that need to be remounted RW before upgrades, this is something that would need to be checked by the sysadmin, or extending the upgrade script elided above. I'm afraid I don't think there's much else to do than close the report. Thanks, Guillem -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763405: base-files: inclusion of /mnt in package can result in failures for systems where /mnt is ESTALE
Package: base-files
Version: 7.1wheezy6
Severity: normal
Dear Maintainer,
Since sysadmins tend to (and are often told to) use /mnt for
temporary mounts, and sometimes forget those mounts and they go
stale (nfs), a package (in this case 'base-files') that includes
/mnt in the files section will result in a complete failure to
install.
SERVER:~# type aptup
aptup is a function
aptup ()
{
read -p Include any available kernel packages in update? [n]: reply;
test $reply || reply=no;
aptitude update if echo $reply | egrep -iq ^y; then
aptitude full-upgrade;
else
aptitude install $(aptitude search -F %p '~U
!~nlinux-(image|header)');
fi aptitude clean
}
SERVER:~# aptup
Include any available kernel packages in update? [n]: n
The following packages will be upgraded:
a2ps apache2 apache2-mpm-prefork apache2-utils apache2.2-bin
apache2.2-common apt apt-utils base-files bind9-host cups-bsd cups-client
cups-common curl dbus dbus-x11 dnsutils
Preparing to replace base-files 7.1wheezy2 (using
.../base-files_7.1wheezy6_amd64.deb) ...
-- Unpacking replacement base-files ...
dpkg: error processing
/var/cache/apt/archives/base-files_7.1wheezy6_amd64.deb (--unpack):
-- unable to stat `./mnt' (which I was about to install): Stale NFS file
handle
Errors were encountered while processing:
/var/cache/apt/archives/base-files_7.1wheezy6_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
SERVER:~# ls /mnt
ls: cannot access /mnt: Stale NFS file handle
(d'oh sysadmin mounted other server months ago, which is now ESTALE,
but should not result in a fatal install failure in base-files)
SERVER:X# dpkg --fsys-tarfile -
/var/cache/apt/archives/base-files_7.1wheezy6_amd64.deb | tar tvf - | grep /mnt
-- drwxr-xr-x root/root 0 2014-06-11 21:07 ./mnt/
I personally tend to use /{a,b,..} (Solaris background) to do my
temporary mounts, which helps avoid this condition, but still, if
you can modify the packaging script to avoid this (apparently)*
useless directory inclusion, that'd be desired. (this is the second
time in a few years i've run into this issue)
* 'find . -xdev -type f -exec grep -al '/mnt' {} +' on extract .deb
doesn't match anything, so i don't think a postinst/preinst is
using /mnt
-- System Information:
*** NOTE: I'm running bugreport on another system, so the following
*** isn't accurate for the system in question, but it is also
*** irrelevant:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages base-files depends on:
ii gawk [awk] 1:4.0.1+dfsg-2.1
ii mawk [awk] 1.3.3-17
base-files recommends no packages.
base-files suggests no packages.
-- no debconf information
Thanks,
--stephen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760521: (emacs23: opening file by name *.sout* results in readonly buffer)
Please REASSIGN to the package 'ess'. By divide/conquer on /etc/emacs/site-lisp, i believe i have narrowed this down to the following block in /usr/share/emacs23/site-lisp/ess/ess-site.el(c) (if (assoc \\.[rR]\\' auto-mode-alist) nil (setq auto-mode-alist (append '((\\.sp\\' . S-mode) ;; re: Don MacQueen m...@llnl.gov (\\.[qsS]\\' . S-mode) ;; q,s,S [see ess-restore-asm-extns above!] (\\.ssc\\' . S-mode) ;; Splus (= 4.x) script files. (\\.SSC\\' . S-mode) ;; ditto for windoze (\\.[rR]\\'. R-mode) (\\.[rR]nw\\' . Rnw-mode) (\\.[sS]nw\\' . Snw-mode); currently identical to Rnw-mode (\\.[rR]profile\\' . R-mode) (NAMESPACE\\' . R-mode) (\\.omg\\' . omegahat-mode) (\\.hat\\' . omegahat-mode) ;; Duncan's pref'd... (\\.lsp\\' . XLS-mode) (\\.do\\' . STA-mode) (\\.ado\\' . STA-mode) (\\.[Ss][Aa][Ss]\\'. SAS-mode) ;; Many .log/.lst files, not just SAS ;;(\\.log\\' . SAS-log-mode) ;;(\\.[Ll][Ss][Tt]\\' . SAS-listing-mode) (\\.[Ss]t\\' . S-transcript-mode) (\\.[Ss]out. S-transcript-mode) (\\.[Rr]t\\' . R-transcript-mode) (\\.[Rr]out. R-transcript-mode) (\\.Rd\\' . Rd-mode) (\\.[Bb][Uu][Gg]\\' . ess-bugs-mode) (\\.[Bb][Oo][Gg]\\' . ess-bugs-mode) (\\.[Bb][Mm][Dd]\\' . ess-bugs-mode) (\\.[Jj][Aa][Gg]\\' . ess-jags-mode) (\\.[Jj][Oo][Gg]\\' . ess-jags-mode) (\\.[Jj][Mm][Dd]\\' . ess-jags-mode) ) auto-mode-alist))) The match: (\\.[Ss]out. S-transcript-mode) ** no trailing anchor \' !! ** appears to label the input file as being an 'S-transcript-mode' filetype and this function gets triggered: [/usr/share/emacs23/site-lisp/ess/ess-sas-l.el] (defun SAS-log-mode () `ess-transcript-mode' for SAS. (interactive) (SAS-mode) (setq mode-name ESS[LOG]) (ess-transcript-minor-mode 1) (toggle-read-only t)) ;; to protect the buffer. Note that there is no anchor matching for end-of-string with '\'' as there are for many other filetypes listed. I don't know if that was intentional, but it is exceptionally presumptuous to match *.sout* -- which is bound to hit stuff that it should not. (and obviously does for my user with filenames like CIDD.south_foo ...) thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760521: emacs23: opening file by name *.sout* results in readonly buffer
Package: emacs23 Version: 23.4+1-4 Severity: normal Dear Maintainer, reproduce: emacs .sout # minimal string required for bug emacs ARBITRARY.soutARBITRARY result: buffer being unconditionally READONLY (independent of file permissions or existence) I can not find that literal string in any files i *think* are read in by emacs (/etc/emacs, /usr/lib/emacs*, /usr/share/emacs*) and can not find that string in the emacs23 Debian source code package source. We have a user with many file names of the form .south (.north, etc..) and it is aggravating to them to have the buffer always start off readonly. I have tried this on a CentOS machine (albeit emacs 21) and the problem does not exist there. I also tried this on a Debian Jessie box with GNU Emacs 24.3.1, and the problem doesn't exhibit there (must be fixed), either, but it would be nice to have a fix or a workaround or understanding of where the bug/misfeature is triggering (sorry, i'm a 'vim' person, and i can't find any info via search engine for this problem) thanks, --stephen -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages emacs23 depends on: ii emacs23-bin-common 23.4+1-4 ii gconf-service 3.2.5-1+build1 ii libasound2 1.0.25-4 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38+deb7u4 ii libcairo2 1.12.2-3 ii libdbus-1-3 1.6.8-1+deb7u3 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgconf-2-43.2.5-1+build1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libgif4 4.1.6-10 ii libglib2.0-02.33.12+really2.32.4-5 ii libgpm2 1.20.4-6 ii libgtk2.0-0 2.24.10-2 ii libice6 2:1.0.8-2 ii libjpeg88d-1+deb7u1 ii libm17n-0 1.6.3-2 ii libncurses5 5.9-10 ii libotf0 0.9.12-2 ii libpango1.0-0 1.30.0-1 ii libpng12-0 1.2.49-1 ii librsvg2-2 2.36.1-2 ii libsm6 2:1.2.1-2 ii libtiff43.9.6-11 ii libtinfo5 5.9-10 ii libx11-62:1.5.0-1+deb7u1 ii libxft2 2.3.1-1 ii libxpm4 1:3.5.10-1 ii libxrender1 1:0.9.7-1+deb7u1 ii zlib1g 1:1.2.7.dfsg-13 emacs23 recommends no packages. Versions of packages emacs23 suggests: pn emacs23-common-non-dfsg 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#733816: khotkeys launches actions with SIGHUP blocked, leading to unclosable xterms
Anthony DeRobertis wrote, On 12/31/2013 01:02 PM:
Package: kde-workspace-bin
Version: 4:4.11.3-2
Severity: normal
I have a hotkey to launch an xterm. This worked before the most recent
aptitude upgrade to track testing, but now when I launch an xterm that
way, clicking the kwin close button (or picking close from the kwin
menu) does nothing; the xterm sticks around.
After searching for a while, I compared an strace of each, and it seems
that khotkeys is starting xterm with SIGHUP blocked/masked, and that's
causing the issue.
khotkeys probably shouldn't have signals masked when starting commands.
[Note: see also my question about this on Unix.SE
http://unix.stackexchange.com/q/107331/977 ]
Please make sure you are not affected by this recent nVidia driver
signal mask bug. It's been driving me CRAZY (breaking Akonadi/mysqlcheck,
screenblank/lock recovery, etc)
https://devtalk.nvidia.com/default/topic/633706/linux/recent-drivers-cause-applications-to-hang-not-start-at-all-or-compilation-failures/
https://devtalk.nvidia.com/default/topic/638521/linux/gnome-terminal-problems-ctrl-c-and-exit/
for i in /proc/[0-9]*/status; do
if sb=$(grep SigBlk ${i}|sed -e 's/^SigBlk:[ \t]//' | grep -v -e '^' -e
000); then
echo ${sb} $(cat ${i%/*}/cmdline);
fi
done
If you see many X11/KDE spawned apps running with signal masks that look like
pointer addresses, then that's likely it:
e.g.:
01a12000 kdeinit4: kded4 [kdeinit]
7fd601bb6e80
kwin-session107a69611386353118028530_1388190743_313193
7f847f809af8 /usr/bin/plasma-desktop
7f847f809a50 /usr/bin/akonadi_control
7f847f809a50 akonadiserver
7f847f809a10
/usr/bin/akonadi_contacts_resource--identifierakonadi_contacts_resource_0
7f847f809a10
/usr/bin/akonadi_ical_resource--identifierakonadi_ical_resource_0
7f847f809a10
/usr/bin/akonadi_maildir_resource--identifierakonadi_maildir_resource_0
7f847f809a10
/usr/bin/akonadi_maildispatcher_agent--identifierakonadi_maildispatcher_agent
7f88024886d0 /usr/bin/krunner
7f3048d08e80
/usr/bin/kmix-session107a696113675493530070530010_1388190742_119017
7f7e384a86d0
/usr/bin/lancelot-session107a696113878247110164860042_1388190742_87972-nameQt-subapplication
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703005: Additional Info in my environment for kscreenlocker exit delays
FWIW, my issue *appears* to actually be caused by this: nVidia Drivers creating bad signal masks for spawned processes: https://devtalk.nvidia.com/default/topic/633706/linux/recent-drivers-cause-applications-to-hang-not-start-at-all-or-compilation-failures/ https://devtalk.nvidia.com/default/topic/638521/linux/gnome-terminal-problems-ctrl-c-and-exit/ I've run one day with the nVidia 325.15 driver w/o any screen blanker delays. -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733816: khotkeys launches actions with SIGHUP blocked, leading to unclosable xterms
Anthony DeRobertis wrote, On 12/31/2013 02:47 PM:
On Tue, Dec 31, 2013 at 02:10:42PM -0700, Stephen Dowdy wrote:
for i in /proc/[0-9]*/status; do
if sb=$(grep SigBlk ${i}|sed -e 's/^SigBlk:[ \t]//' | grep -v -e '^'
-e 000); then
echo ${sb} $(cat ${i%/*}/cmdline);
fi
done
I suppose it's a lot easier to type:
ps -eo blocked,pid,cmd | grep -v \^
;)
Indeed it appears I might be:
...
I've got nvidia-kernel-dkms 331.20-2 (from experimental), which is one
of the affected versions, apparently.
I've backed out to 325.15, successfully.
(no more 80%-of-the-time random 10 second blank screen delays after unlocking
the screen,
no more random 50% of the time 30 second no cursor/keyboard input after that,
no more akonadiserver crapping out from spawned mysqlcheck zombie, yay)
anthony@Zia:~$ grep SigBlk /proc/3289/status
SigBlk: 0001
so that seems to be sane... except for HUP being ignored. Its parent
kdeinit4: kded4 [kdeinit] has the same.
So I'm unsure if this is really bug 728743 or not :-(
I'm betting it is -- thanks for the pointer to that bug #, as i
had not run across it yet. The nefarious bit of this bug is that
it can create bad behavior in so many things that seem totally
unrelated to the X server/driver, and because the inherited mask
seems somewhat random (memory corruption or failure to dereference
pointer?..), it's just crazy enough to keep you off-track.
(as that bug original started in the 'libgmime' package, was
moved to the Mono package before ending up in 'nvidia' ;} )
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703005: Additional Info in my environment for kscreenlocker exit delays
I'm not sure if this is the same bug... Summary: occasional/random screen remains blank for ~10 seconds after typing unlock password (password dialog disappears, screen is completely blank) (for me, i'd say it happens 90% + of the time) often followed by up to 30 second No-Mouse-Or-Keyboard condition (mouse cursor does not display, keyboard input is not accepted, just have to wait) (this happens perhaps 50-75% of the time) not related to load/#applications/#windows/ amount-of-time-logged-already-logged-in. In my environment several of us have, perhaps within the last 3 or so months started seeing a *random* screenlocker exit delay of about 10 seconds where the screen stays black. It's not clear how many users this affects, as i have only anecdotal info from myself and one other fellow system administrator, and one user who only mentioned it in the course of debugging another issue after upgrading him to Wheezy. (everything's working great, but there's a 10 second delay before i can get to work after unlocking the screen...) (i.e. we may have a number of users who are not reporting the problem, assuming that's just the way things are). We recently (~6 months ago) instituted *advisory* (i wanted mandatory, but we're fighting with management :-( ) screenlocking defaults here. /etc/kde4/kscreensaverrc [ScreenSaver] ActionBottomLeft=0 ActionBottomRight=0 ActionTopLeft=0 ActionTopRight=0 Enabled=true Lock=true LockGrace=6 PlasmaEnabled=false Saver=kblank.desktop Timeout=1800 I do not know if this has any impact on this bug, but it seems unlikely. Additionally, for myself, ocasionally, i am left without a mouse or keyboard for upto 30 seconds after the 10 second blank screen delay and the screen display comes back. I have not heard others report this (yet). FWIW, i have been working on using the kdebugdialog function to send 'kscreenlocker' notifications to a script, so that i could also activate other functions such as locking the ssh-agent, pausing multi-media applications, signalling IM clients to put themselves in away mode. (it'd be awesome if 'kscreenlocker' had a mechanism internal to run user-supplied lock/unlock functions, but at least with the debug dialog functions, i can hack this). I am only doing this on my OWN system, so this should not affect any other user, but it might help explain the 30-second no-mouse-or-keyboard condition i sometimes see. X0rg.0.log and .xsession-errors have nothing that appears relevant. I have re-installed 3 variant releases of the nVidia proprietary drivers to ensure that's not the cause. The screensaver package has not been updated in a while, so this is likely a change made to another X11 package/lib that affects or is triggered by the kscreenlocker application. thanks, --stephen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727706: distro-info: feature request: cmdline options to report columnar field data from csv
Package: distro-info Version: 0.10 Severity: wishlist Dear Maintainer, ISTM that 'debian-distro-info' would greatly benefit from a mode where it prints all/any of the csv fields for a selected codename. e.g. *option* = currently unsupported/desired command line option $ debian-distro-info --stable *--release* 2013-05-04 $ debian-distro-info --oldstable *--eol* 2014-05-04 $ debian-distro-info --oldstable *--version* 6.0 $ debian-distro-info --testing *--version* 8.0 $ debian-distro-info --testing *--release* undefined $ debian-distro-info --stable *--allinfo* version:7.0 codename: Wheezy series: wheezy created:2011-02-06 release:2013-05-04 eol:undefined (note there's also a contradiction here with the new versioning scheme. i.e. Wheezy is listed as version 7.0, but i think it's now supposed to be just 7, as the middle number of a version has been deprecated, that's probably a distro-info-data bug?.) thanks, --stephen -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages distro-info depends on: ii distro-info-data 0.16~deb7u1 ii libc6 2.13-38 distro-info recommends no packages. Versions of packages distro-info suggests: pn shunit2 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#707014: file: 'file' misreports #!/bin/sh as 'data'
Package: file Version: 5.11-2 Severity: normal Dear Maintainer, In some cases, 'file' misreports an explicitly declared '#!/bin/sh' POSIX shell script as 'data'. My best guess is that these large files contain self-extracting binary payload which is being found by 'file', but they are most certainly still shell scripts and IMHO, an explicit '#!' (shebang, magic interpreter) line should NEVER be overriden by any analysis algorithm in 'file', unless it is to provide more details. (and this is new behaviour in 'wheezy') (i.e. it seems that some new algorithm has been given higher precedent than simply reporting the shebang interpreter contents) $ lsb_release -ds Debian GNU/Linux 7.0 (wheezy) $ file --version file-5.11 magic file from /home/sdowdy/.magic:/usr/share/file/magic $ cat /home/sdowdy/.magic cat: /home/sdowdy/.magic: No such file or directory (i.e. no user overrides, and i haven't touched /usr/share/file/magic*) (any of Dell's DUP .BIN kits exhibit this issue, so i provide one as an example) $ wget http://downloads.dell.com/FOLDER00797936M/1/R710_BIOS_VCNMH_LN32_6.3.0.BIN ... 2013-05-06 14:31:23 (1.16 MB/s) - `R710_BIOS_VCNMH_LN32_6.3.0.BIN' saved [5103874/5103874] $ file R710_BIOS_VCNMH_LN32_6.3.0.BIN R710_BIOS_VCNMH_LN32_6.3.0.BIN: data (on 'squeeze', this is not misreported as data, but correctly as POSIX shell script) [squeeze:begin] pick:tmp# lsb_release -ds Debian GNU/Linux 6.0.6 (squeeze) pick:tmp# wget http://downloads.dell.com/FOLDER00797936M/1/R710_BIOS_VCNMH_LN32_6.3.0.BIN 2013-05-06 15:07:21 (1.16 MB/s) - R710_BIOS_VCNMH_LN32_6.3.0.BIN saved [5103874/5103874] pick:tmp# file R710_BIOS_VCNMH_LN32_6.3.0.BIN R710_BIOS_VCNMH_LN32_6.3.0.BIN: POSIX shell script text executable [squeeze:end] $ head -2 R710_BIOS_VCNMH_LN32_6.3.0.BIN #!/bin/sh $ head -10 R710_BIOS_VCNMH_LN32_6.3.0.BIN | file - /dev/stdin: POSIX shell script, ASCII text executable (correctly reported if we strip the binary payload) thanks, --stephen -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages file depends on: ii libc6 2.13-38 ii libmagic1 5.11-2 ii zlib1g 1:1.2.7.dfsg-13 file recommends no packages. file 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#704627: dash: export -p and dot-source inherited from csh via kdm import hack results in logout
Package: dash Version: 0.5.5.1-7.4 Severity: normal I'm not really quite sure exactly how to file this report, as it involves interactions between 'csh', 'kdm', and 'dash', but 'dash' seems the obvious place to initially file the report, as it appears to me that there may be a POSIX compliance issue, or at least an inconsistency in how 'dash' handles 'export'. A description of the immediate problem: - User uses 'tcsh' as login shell. - User has a .cshrc with: setenv 500_FOO 'blather' - User attempts to login using KDE 'kdm'. - /etc/kde4/kdm/Xsession uses the following hackery to attempt to inherit/import a '*csh' user's standard environment into its own shell environment via: $SHELL -c if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c export -p ! $xsess_tmp . $xsess_tmp - However, 'dash' when dot-script sourcing $xsess_tmp finds the statement: export 500_FOO='blather' and immediately aborts dot-script processing (so no subsequent statements are read). In this case, because 'dash' also returns exit status 2 from the dot-script source, 'Xsession' aborts and the user is immediately logged out. So, Xsession could be potentially reworked to ignore the error, or could do: . $xsess_tmp || true (which would not abort the Xsession login, at least, but would still leave the user without a complete standard environment and little indication of what failed) or, possibly, a bunch of undesireable POSIX sanitization could be done on the 'export -p' output file to keep dash from aborting when dot-script sourcing of it... FWIW, 'bash' behaves differently on this error (it also writes BASH-specific 'declare' statements instead of 'export' for 'export -p' (uck)), by continuing to process the remainder of the file and returning exit status = 0. (that's assuredly from other valid statements further down the file, actually, i just hand-edited the file, and '.' returns exit code=1 if that statement is at the end of the dot-script, still different from exit code '2' as 'dash' reports) -- It appears that 'dash' will inherit a POSIX non-compliant env-var into the environment, and is happy to write the value out in an 'export -p' statement to a temp file, but upon doing a dot-script source of the temp file will abort processing of the dot-script and return exit status of 2. I'm not entirely clear on whether this apparent behavioural inconsistency is correct. (seems to me that if dash writes something out with 'export -p' that whatever it wrote out should be invertably parsable w/o error) These seem to be possibly relevant references on expected behaviour: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_14 'export' appears to be a Special Built-In Utility 'dot' appears to be a Special Built-In Utility A syntax error in a special built-in utility may cause a shell executing that utility to abort If a special built-in utility encountering a syntax error does not abort the shell, its exit value shall be non-zero. http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08_01 2.8.1 Consequences of Shell Errors http://pubs.opengroup.org/onlinepubs/009695399/utilities/export.html EXIT STATUS=Zero. CONSEQUENCE OF ERRORS=Default sdowdy$ /bin/bash -c 'export 500_FOO=wompus; echo $?' /bin/bash: line 0: export: `500_FOO=wompus': not a valid identifier 1 sdowdy$ /bin/dash -c 'export 500_FOO=wompus; echo $?' export: 1: 500_FOO: bad variable name # fails to execute the following statement regardless of 'errexit' state sdowdy$ echo $? 2 http://pubs.opengroup.org/onlinepubs/009695399/utilities/dot.html EXIT STATUS=Returns the value of the last command executed, or a zero exit status if no command is executed. CONSEQUENCES OF ERRORS=Default. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08 ...Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2008 consist solely of uppercase letters, digits, and the underscore ( '_' ) from the characters -- defined in Portable Character Set and do not begin with a -- digit. Other characters may be permitted by an implementation; -- applications shall tolerate the presence of such names. Uppercase and lowercase letters shall retain their unique identities and shall not be folded together. The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behavior of the standard utilities (so does tolerate mean that 'dash' should not abort dot-scripts with invalid env-var assignments?) thanks, --stephen -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel:
Bug#704627: dash: export -p and dot-source inherited from csh via kdm import hack results in logout
Jonathan Nieder wrote, On 04/03/2013 12:52 PM: forcemerge 480371 704627 tags 480371 + fixed-upstream quit ... Yeah, this is an unpleasant consequence of bug#480371, which should be fixed by commit 46d3c1a614f11f0d40a7e73376359618ff07abcd Author: Herbert Xu herb...@gondor.apana.org.au Date: Sat Feb 25 15:35:18 2012 +0800 [VAR] Sanitise environment variable names on entry Jonathan, thanks for the very quick response, sorry i didn't see that bug. BUT... the other part of this issue is that 'dot-source' is fatal-aborting on that 'export BAD-VAR=value'. It wasn't clear to me that that is expected behavior. It's certainly not necessarily desireable. thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704627: dash: export -p and dot-source inherited from csh via kdm import hack results in logout
Jonathan Nieder wrote, On 04/03/2013 01:37 PM: The only sane way to fix this is for the shell to sanitize its environment. Even post-processing export -p output is not really feasible because the format varies from shell to shell. Jonathan, great thanks, considering issue resolved. --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624524: specific visualization defect using Inconsolata-10 with colors
I see this issue, but it's not obvious except when using 'Inconsolata'
at 10pt.
If i do:
$ type ls
ls is a function
ls ()
{
command -p ls -ACF $@
}
$ ls
lost+found/ Music/ src/
$ ls --color
lost+found/ Music/ src/
HOWEVER, it *appears* on screen as:
lost+foun/Musi/ sr/
^ 'c' is about 2/3 visible
^ 'c' is about 1/3 visible
^ 'c' is not visible at all
other fontsizes of Inconsolata don't seem to show this, and other fonts
(i've tried) at 10 pt do not exhibit this, either.
I wasn't sure what package to submit this bug under (konsole,
font-inconsolata, {font-render-package}, etc), but
given that i can confirm using 'ls --color', this seems to be the same bug.
thanks,
--stephen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525018: recoll indexer subtasks never completing
FYI: Quickly (given this is a quite old bug report)...
I had a similar issue years ago. Turned out that the 'ghostscript' included
a PostScript file called 'loop.ps'. The PS indexer would run ghostscript
on the file to attempt to generate a text output to index. However,
'loop.ps' by its very name, sends the PS interpreter into a loop,
thus the indexer would never complete.
The 'recoll' author was going to address that with timeout kills on
the indexer child to keep it from consuming resources. I'm pretty sure
that happened.
And to the original poster:
ps -awwl -s ${pid-of-offending-process}
and possible 'lsof' output would be helpful.
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668133: dash:incorrect behaviour for builtin test -w operator on readonly mounts
Jonathan Nieder wrote, On 04/18/2012 01:58 PM: Hi Stephen, Please get strace and ltrace output so we can see what system call or libc call is giving wrong information. Yes, I know I could do that myself. I'm lazy. :) Jonathan, Okay, here ya go: # mount -o remount,ro /d2 # env -i strace -o /tmp/dash-test-w-directory.strace -f -s 128 /bin/dash -c '[ ! -w /d2 ] echo Not Writeable' # env -i strace -o /tmp/dash-test-w-file.strace -f -s 128 /bin/dash -c '[ ! -w /d2/foompy ] echo Not Writeable' Not Writeable # env -i ltrace -o /tmp/dash-test-w-directory.ltrace -f -s 128 /bin/dash -c '[ ! -w /d2 ] echo Not Writeable' # env -i ltrace -o /tmp/dash-test-w-file.ltrace -f -s 128 /bin/dash -c '[ ! -w /d2/foompy ] echo Not Writeable' Not Writeable Let me know if you need the output from doing this with 'bash' for comparison. (I'm not doing it until you ask, 'cause i'm lazy, too ;) ) thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ 2487 __libc_start_main(0x40a9c0, 3, 0x7fffa4e2c4d8, 0x412a50, 0x412a40 unfinished ... 2487 __errno_location() = 0x7f8385cd06a8 2487 _setjmp(0x7fffa4e2c300, 0x7fffa4e2c4d8, 0x7fffa4e2c4f8, 0, 0x7f8385ad2300) = 0 2487 getpid() = 2487 2487 signal(17, NULL) = NULL 2487 geteuid() = 0 2487 getppid() = 2486 2487 vsnprintf(\001\200\255\373\001, 4281483, , 0x0041548b) = 4 2487 malloc(32) = 0x02027010 2487 getcwd(NULL, 0) = /tmp 2487 __ctype_b_loc() = 0x7f8385cd06b0 2487 __ctype_b_loc() = 0x7f8385cd06b0 2487 __ctype_b_loc() = 0x7f8385cd06b0 2487 strchrnul(0x41316e, 61, 80, 0x2027030, 1) = 0x41316e 2487 strlen(/tmp) = 4 2487 malloc(9) = 0x02027060 2487 mempcpy(0x2027060, 0x41316b, 3, 0x2027050, 0x7f8385ad2ea8) = 0x2027063 2487 mempcpy(0x2027064, 0x2027040, 4, 17495, 0x7f8385ad2ea8) = 0x2027068 2487 malloc(32) = 0x02027080 2487 sigaction(2, NULL, 0x7fffa4e2c1e0) = 0 2487 sigfillset(0x7fffa4e2c1e8) = 0 2487 sigaction(2, 0x7fffa4e2c1e0, NULL) = 0 2487 sigaction(3, NULL, 0x7fffa4e2c1e0) = 0 2487 sigfillset(0x7fffa4e2c1e8) = 0 2487 sigaction(3, 0x7fffa4e2c1e0, NULL) = 0 2487 sigaction(15, NULL, 0x7fffa4e2c1f0
Bug#668133: dash:incorrect behaviour for builtin test -w operator on readonly mounts
Package: dash
Version: 0.5.5.1-7.4
Severity: normal
While DASH properly reports that a *file* on a READONLY mount is not
writeable through its builtin 'test' function, it does not properly
detect that a *directory* is not writeable.
(filesystem type is not important, as this is true on NFS and EXT4
at least, and suspect it's fstype agnostic)
### filesystem is currently read-write
BASH:~# awk '$2==/d2{print $0}' /proc/mounts
/dev/sdd2 /d2 ext4
rw,nosuid,nodev,relatime,errors=remount-ro,barrier=1,journal_checksum,nodelalloc,data=journal
0 0
### remount filesystem read-only
BASH:~# mount -o remount,ro /d2
### See that 'bash' performs as expected...
### confirm filesystem is now read-only
BASH:~# awk '$2==/d2{print $0}' /proc/mounts
/dev/sdd2 /d2 ext4
ro,nosuid,nodev,relatime,errors=remount-ro,barrier=1,journal_checksum,nodelalloc,data=journal
0 0
### attempt to touch a file to confirm
BASH:~# touch /d2/foompy
touch: cannot touch `/d2/foompy': Read-only file system
### use our builtin command 'test' (as [) to confirm
### expected behaviour that files and directories are
### not writeable
BASH:~# [ ! -w /d2/foompy ] echo Not Writeable
Not Writeable
BASH:~# [ ! -w /d2 ] echo Not Writeable
Not Writeable
### invoke 'dash' to see the bug
BASH:~# /bin/dash
### use our builtin command 'test' (as [) to confirm
### that files are not writeable as expected
DASH# [ ! -w /d2/foompy ] echo Not Writeable
Not Writeable
### use out builtin command 'test' (as [) to confirm
### that directories are not writeable as expected,
### however, we do NOT get the expected response.
DASH# [ ! -w /d2 ] echo Not Writeable
# [ -w /d2 ] echo Writeable
Writeable
### Not even if the directory is fully declared:
# [ ! -w /d2/. ] echo Not Writeable
#
Unless i'm wrong, the POSIX spec shows nothing for 'test'
that would indicate that behaviour should be different
for file versus directory.
-- System Information:
Debian Release: 6.0.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages dash depends on:
ii debianutils 3.4Miscellaneous utilities specific t
ii dpkg 1.15.8.12 Debian package management system
ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib
dash recommends no packages.
dash suggests no packages.
-- debconf information:
* dash/sh: true
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543815: Establishing a Severity rating
RE: [ Severity set to 'important' from 'critical' Request was from maximilian attems m...@debian.org ] I just wanted to point out that i had difficulty determining HOW to address the severity field in reportbug. Because i *do* have a workaround to the problem, it's not critical to *me* anymore, and wasn't at the point i submitted the bug. But the question that debian reportbug asks is: How would you rate the severity of this problem or report? 1 criticalmakes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. 2 grave makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. 3 serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive); may or may not affect the usability of the package. Note that non-severe policy violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also designate other bugs as 'serious' and thus release-critical; however, end users should not do so.) 4 important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. ... Please select a severity level: [normal] in a generic sense, this *problem* is critical, because it DOES render end-user systems broken. ...makes...(or the whole system) break... (not being able to boot due to kernel panic certainly falls under system breakage) So, given the language from reportbug, i answered honestly that this bug does indeed break the whole system, therefore it is a critical problem. my *specific* problem *report* itself is not critical, because i am operational now that i've determined the nature of the problem. (if i were under a security compliance obligation and was still incapable of booting my system due to this bug, i would consider this problem VERY critical) So, in this reply, i am simply voicing my concern that a better wording in reportbug addressing this type of discrepency be employed. Perhaps a distinction between end-user urgency and problem severity is needed. It's certainly not my intent to distract developers from more important tasks (i can tell from other bug reports i'm not the only one affected by this, but i don't believe the affected end-user base is very large) I only bring this up, because i've also seen other users wonder about how to classify bug report severity as well. thanks, --stephen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543815: initramfs-tools: Having /lib64 in /etc/ld.so.conf results in unusable initrd image
Package: initramfs-tools Version: 0.85i Severity: critical Justification: breaks the whole system -- Summary: This problem is in essence (AFAICT) the same as #337176, #420754 I think the solution is to fix the hook-functions to not just catch a few well known optimized locations, but to also dereference library paths to absolute locations? (or create the initrd with symlinks for found lib directories back to /lib) (sorry, i don't have enough time to really dig into this, myself) -- If /etc/ld.so.conf contains /lib64, update-initramfs will create a filesystem containing /lib64/libcrypt.so.1, but /bin/sh is looking only for /lib/libcrypto.so.1 yielding: -- /bin/sh: error while loading shared libraryes: libcrypt.so.1: cannot open shared object file: No such file or directory Kernel panic - not syncing: Attempted to kill init! -- So /lib64 is default symlink to /lib (on running system): + stat -c %N /lib64 `/lib64' - `/lib' + grep lib64 /etc/ld.so.conf /lib64 Note: you could argue this is a mistake, but the end result is that kernel security updates render the system unbootable. As far as the running system is concerned, since /lib64 is a symlink to /lib, it operates the same. Theoretically, though someone COULD make /lib64 a real directory and have a custom libcrypt.so.1 there and i suspect that update-initramfs would still break. + ldconfig -p + grep libcrypt.so libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.0) = /lib64/libcrypt.so.1 libcrypt.so.1 (libc6, OS ABI: Linux 2.6.0) = /lib32/libcrypt.so.1 libcrypt.so (libc6,x86-64, OS ABI: Linux 2.6.0) = /usr/lib/libcrypt.so note that /lib64 is where libcrypt.so is found in this configuration. If i remove /lib64 from /etc/ld.so.conf and 'ldconfig', we get instead: + ldconfig -p + grep libcrypt.so libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.0) = /lib/libcrypt.so.1 libcrypt.so.1 (libc6, OS ABI: Linux 2.6.0) = /lib32/libcrypt.so.1 libcrypt.so (libc6,x86-64, OS ABI: Linux 2.6.0) = /usr/lib/libcrypt.so (where it's now found in /lib) + gunzip -c /boot/initrd.img-2.6.18-6-amd64.bak + cpio -tiv + grep crypt 28172 blocks -rw-r--r-- 1 root root22656 Jan 4 2009 lib64/libcrypt.so.1 Note: i'm using the .bak since we fixed the system previously by removing /lib64 from /etc/ld.so.conf and i've only put it back in here for the bugreport (so /boot/initrd.img-2.6.18-6-amd64 is fixed as seen here:. + gunzip -c /boot/initrd.img-2.6.18-6-amd64 + cpio -tiv + grep crypt 28172 blocks -rw-r--r-- 1 root root22656 Jan 4 2009 lib/libcrypt.so.1 thanks, --stephen -- Package-specific info: -- /proc/cmdline root=/dev/sda1 ro vga=771 -- /proc/filesystems cramfs ext3 -- lsmod Module Size Used by nfsd 256200 17 exportfs 10368 1 nfsd ipt_MASQUERADE 8320 1 iptable_nat12292 1 ip_nat 24492 2 ipt_MASQUERADE,iptable_nat ip_conntrack 63140 3 ipt_MASQUERADE,iptable_nat,ip_nat nfnetlink 11976 2 ip_nat,ip_conntrack ip_tables 25576 1 iptable_nat x_tables 22024 3 ipt_MASQUERADE,iptable_nat,ip_tables ppdev 14088 0 parport_pc 41640 0 lp 17736 0 parport44684 3 ppdev,parport_pc,lp nfs 236216 1 lockd 67600 3 nfsd,nfs nfs_acl 8320 2 nfsd,nfs sunrpc166984 13 nfsd,nfs,lockd,nfs_acl autofs427912 1 ipv6 286048 38 dm_snapshot20664 0 dm_mirror 25216 0 dm_mod 62800 2 dm_snapshot,dm_mirror serio_raw 12036 0 psmouse44432 0 pcspkr 7808 0 shpchp 42156 0 pci_hotplug20872 1 shpchp evdev 15360 2 tsdev 13056 0 joydev 15360 0 ext3 138512 7 jbd65392 1 ext3 mbcache14216 1 ext3 sd_mod 25856 9 ide_cd 45088 1 cdrom 40488 1 ide_cd usbhid 45088 0 piix 15492 0 [permanent] mptsas 31120 8 mptscsih 29184 1 mptsas generic10500 0 [permanent] mptbase56672 2 mptsas,mptscsih uhci_hcd 28696 0 ide_core 147584 3 ide_cd,piix,generic scsi_transport_sas 36608 1 mptsas ehci_hcd 36104 0 scsi_mod 153008 4 sd_mod,mptsas,mptscsih,scsi_transport_sas bnx2 86640 0 tg3 108292 0 thermal20240 0 processor 38248 1 thermal fan 9864 0 -- kernel-img.conf do_symlinks = Yes do_initrd = Yes
