Bug#1012829: Updates -

[Troy Telford]

I have built a vanilla kernel 5.17.6 to replicate the issue, but before I was 
able to test it (to reproduce it and send a report to kernel.org 
’s bugzilla), I became very ill with COVID-19, which put 
everything on hold for a while.

Now that I’ve largely recovered, I have been able run a system apt upgrade - 
and noticed that the zfs modules have been updated to support kernel 5.18, so I 
am now able to test against `linux-image-5.18.0-2` - it seemed to make sense to 
see if I could reproduce against that first, if only to see if a newer kernel 
resolved the issue.

It appears that was the correct move:

- I’ve been able to boot the Debian 5.18.0-2 linux-image package,
- After about nine days of uptime, I’ve been unable to reproduce the issue.
- There are none of the `DMAR: DRHD: handling fault` messages in the kernel log.

I believe this bug can be closed, as it does not appear to be an issue with the 
current kernels.


signature.asc
Description: Message signed with OpenPGP

Bug#1012829: linux-image-5.17.0-3-amd64: intel_iommu=igfx_off workaround required for graphics card

[Troy Telford]

You are correct.

5.17.3-1 worked fine and 5.17.6-1 (and 5.17.11-1) are broken.

"Issues with Audio out via HDMI” is a *far* better description for the bug 
report. (Facepalm).

Setting intel_iommu=igfx_off is a workaround which addresses the issue for me.

I’ll see if I can find the issue in the list, but I’m not familiar with the 
kernel internals, so it’ll be mostly an adventure with git. I’ll be quite happy 
if I can find the file (or commit) where the change occurred.

> On Jun 15, 2022, at 2:26 AM, Diederik de Haas  wrote:
> 
> Control: tag -1 moreinfo
> 
> On Wednesday, 15 June 2022 03:27:23 CEST Troy Telford wrote:
>>After scouring my logs I've found this started after my
>> first boot of kernel 5.17.6-1 (2022-05-14). I started having issues with
>> audio out via HDMI - especially if the device had its input changed or was
>> turned off.
>> 
>>Kernel 5.17.0-1-amd64 (Debian 5.17.3-1 (2022-04-18) does not
>> have this issue, which should help reduce the Δ somewhat.
> 
> IIUC, kernel 5.17.3-1 was fine and 5.17.6-1 was broken?
> If that's the case, then the issue should be in the following list:
> https://tracker.debian.org/news/1324075/accepted-linux-5176-1-source-into-unstable-unstable/
> 
> And is the issue of this bug report "issues with audio out via HDMI"?
> The title of this bug report looks to describe a (potential) workaround.



signature.asc
Description: Message signed with OpenPGP

Bug#1012829: linux-image-5.17.0-3-amd64: intel_iommu=igfx_off workaround required for graphics card

[Troy Telford]

Package: src:linux
Version: 5.17.11-1
Severity: normal
Tags: upstream

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

After scouring my logs I've found this started after my first 
boot
of kernel 5.17.6-1 (2022-05-14). I started having issues with 
audio
out via HDMI - especially if the device had its input changed or
was turned off.

Kernel 5.17.0-1-amd64 (Debian 5.17.3-1 (2022-04-18) does not 
have
this issue, which should help reduce the Δ somewhat.

The problem remains with linux-image-5.17.0-3-amd64. I am 
currently
unable (unwilling?) to test linux-image-5.18.0, as my root
filesytem uses ZFS, and there are currently no DKMS packages 
that
build on linux-image-5.18. (I don't have an abundance of time to
try to both get an upstream zfs set of packages built as well as
figure out how to get a rootfs booting using that kernel 
module.)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

By plugging my error into Google, I was lead to

https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg478114.html,
which wasn't _quite_ what I was looking for, but it mentioned 
the
intel_iommu driver, and as the device id in my error message 
used
an Intel driver (snd_hda_intel), it seemed a reasonable place to
start looking.

That lead me to
https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt, which
explicitly said:

"If you encounter issues with graphics devices, you can try 
adding
option intel_iommu=igfx_off to turn off the integrated graphics
engine.  If this fixes anything, please ensure you file a bug
reporting the problem."

As the motherboard has an Intel integrated graphics engine, and 
the
rest of the document seemed to describe the error message I was
seeing, it seemed reasonable to try the option 
intel_iommu=igfx_off

   * What was the outcome of this action?

The problems vanished, and the error messages stopped appearing 
in
my kernel log.

I initially thought to add this to the kernel.org bugzilla, but
they had a useful message saying "Please use your distribution's
bug tracking tools" which is reasonable, as I am using a Debian
kernel.

I'm not sure the appropriate way to report the issue upstream 
(if
it is even is an issue upstream). Unfortuantely, I can't test 
the
latest 5.18 kernel yet, as my root filesystem uses ZFS, and 
there
are no working DKMS packages for it yet.

*** End of the template - remove these template lines ***

-- Package-specific info:
** Version:
Linux version 5.17.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 
5.17.11-1 (2022-05-26)

** Command line:
BOOT_IMAGE=/ROOT/debian@/boot/vmlinuz-5.17.0-3-amd64 root=ZFS=rpool/ROOT/debian 
ro apparmor=1 security=apparmor nvidia-drm.modeset=1 delayacct 
intel_iommu=igfx_off

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Jun 14 11:32:14 pilot kernel: [162022.120060] dmar_fault: 82685 callbacks 
suppressed
Jun 14 11:32:14 pilot kernel: [162022.120071] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x6ca224000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:32:14 pilot kernel: [162022.120250] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x6ca224000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:32:14 pilot kernel: [162022.120438] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x6ca224000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:32:19 pilot kernel: [162027.124475] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x558cf6000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:34:03 pilot kernel: [162130.851574] dmar_fault: 114335 callbacks 
suppressed
Jun 14 11:34:03 pilot kernel: [162130.851579] DMAR: DRHD: handling fault status 
reg 2
Jun 14 11:34:03 pilot kernel: [162130.851586] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x50bb59000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:34:03 pilot kernel: [162130.851674] DMAR: DRHD: handling fault status 
reg 3
Jun 14 11:34:03 pilot kernel: [162130.851677] DMAR: [DMA Read NO_PASID] Request 
device [00:1b.0] fault addr 

Bug#1009223: sssd fails on startup: Module [memberof] not found - do you need to set LDB_MODULES_PATH

[Troy Telford]

Package: sssd
Version: 2.6.3-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

After upgrading, sssd wouldn't run - running in interactive/debug mode was 
somewhat helpful: 'sssd -i -d1' would give the message:
(2022-04-09  0:45:09): [sssd] [ldb] (0x0010): WARNING: Module [memberof] not 
found - do you need to set LDB_MODULES_PATH?

This eventually lead to a search for memberof.so, which is in 
/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/memberof.so

As hinted at, setting 
LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb" before running 
'sssd -i -d1' allowed sssd to run.

I was able to apply a workaround by simply modifying the various systemd unit 
files (sssd-autofs.service sssd-nss.service sssd-pam.service sssd-ssh.service 
sssd-ifp.service sssd-pac.service sssd.service sssd-sudo.service in my case) to 
add: 
Environment=LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/"

Then I ran 'systemctl daemon-reload; systemctl start sssd' and I am back up and 
running. I'm pretty sure there's a better way to inform the binaries where the 
LDB_MODULES_PATH is than having to update the environment modules at runtime -- 
I've definitely forgotten it, though. I also wouldn't be surprised if I may 
need to do something similar for the socket unit files for systemd -- but it's 
late & I'm tired...

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sssd depends on:
ii  python3-sss  2.6.3-2
ii  sssd-ad  2.6.3-2
ii  sssd-common  2.6.3-2
ii  sssd-ipa 2.6.3-2
ii  sssd-krb52.6.3-2
ii  sssd-ldap2.6.3-2
ii  sssd-proxy   2.6.3-2

sssd recommends no packages.

sssd suggests no packages.

-- no debconf information

Bug#994825: Me Too

[Troy Telford]

#!/usr/bin/env bash
# It probably does a lot more than it needs to... but I tried re-compiling sssd
# from source just in case that was the issue.
#
# Note that it deletes files in /var/lib/sss/db, and removing cache files will
# also remove all of your cached credentials.
TEMPDIR=$(mktemp -d)
chown _apt:root ${TEMPDIR}
cd ${TEMPDIR}
echo "Download source package for SSSD: "
apt-get source sssd
PACKAGES=($(cat sssd-*/debian/control | grep Package | awk '{print $2}'))
declare -a INSTALLED
declare -a HOLD
for PACKAGE in ${PACKAGES[@]}; do
# Check what's installed vs what the sssd src package would build
if dpkg --get-selections | grep -qE "^$PACKAGE[[:space:]]*(install|hold)$" 
>/dev/null; then
HOLD+=(${PACKAGE})
INSTALLED+=(${PACKAGE}_2.4.1-2_amd64.deb)
if [[ ! -f ${PACKAGE}_2.4.1-2_amd64.deb ]]; then
curl -O 
https://mirrors.xmission.com/debian/pool/main/s/sssd/${PACKAGE}_2.4.1-2_amd64.deb
fi
fi
done
clear
echo "Packages are in ${TEMPDIR}; you will need to clean it up manually."
echo
echo "You will need to remove the old sssd cache by executing:"
echo "# rm /var/lib/sss/db/cache_*"
echo
echo "Once you've done that, you can re-install the old versions using"
echo "# dpkg -i ${INSTALLED[@]}"
echo
echo "Finally, hold the old version using:"
echo "# apt-mark hold ${HOLD[@]}"   

echo 
echo "You will need to 'apt-mark unhold ${HOLD[@]}' once this bug is fixed.

Bug#994825: Me Too

[Troy Telford]

I see the same error

   *  (2021-09-21 13:02:46): [sssd] [sbus_server_socket_listen] (0x0020): 
Unable to start a D-Bus server at 
unix:path=/var/lib/sss/pipes/private/sbus-monitor 
[org.freedesktop.DBus.Error.AccessDenied]: Failed to bind socket 
"/var/lib/sss/pipes/private/sbus-monitor": Permission denied

Bug#986166: systemd: 'systemd --user' not functional. Regardless of user, org.freedesktop.systemd1 exits with status 1

[Troy Telford]

Detail is provided to avoid https://xkcd.com/979/ from happening to anybody in 
the future.

After a chat on IRC, we tested our a few scenarios, and found that _local_ 
users worked fine. The users that didn’t work were the LDAP users, which 
wouldn’t load systemd-user.

I tried adding the one-shot at 
https://src.fedoraproject.org/rpms/nss_nis/blob/rawhide/f/nss_nis.conf to try a 
different restriction for the NSS service and systemd-user would work, however 
other things broke.

We eventually determined that the end problem wasn’t systemd-user, but rather 
the local LDAP configuration, which is _old_, and uses services that probably 
should be replaced with sssd.

That’s exactly what I did, and now sssd gets the users properly, and 
systemd-user starts with no problems.

Of note is https://github.com/systemd/systemd/blob/v248/NEWS, which has a 
warning that:

NOTE: This has a chance of breaking nss-ldap and similar NSS modules
  that embed a network facing module into any process using getpwuid()
  or related cal

Which is exactly what happened.

This issue can be closed.

> On Mar 30, 2021, at 12:22 PM, Michael Biebl  wrote:
> 
> Am 30.03.2021 um 20:14 schrieb Troy Telford:
>> Package: systemd
>> Version: 247.3-3
>> Severity: normal
>> Dear Maintainer,
>>* What led up to the situation?
>> This was probably due to an apt update/upgrade. I haven't been configuring my
>> system, but about two weeks ago, "systemd --user" stopped working entirely -
>> none of the user units start up upon user login. The first thing I noticed is
>> no sound, but it didn't take long to find that systemd wasn't running any 
>> user
>> units.
>>* What exactly did you do (or not do) that was effective (or ineffective)?
>> Initially, I found that XDG_RUNTIME_DIR wasn't being set anymore -- so I 
>> added
>> `export XDG_RUNTIME_DIR=/run/user/$(id -u)` to my .xsessionrc. It didn't fix
>> the issue for login, but I could at least run `systemd --user` and start up 
>> the
>> processes after login. However, even that is broken now: I invariably get
>> "Process org.freedesktop.systemd1 exited with status 1"
>> /var/log/daemon.log has a corresponding message from DBUS about
>> org.freedesktop.systemd1 being activated, but dying:
>> Mar 30 12:08:01 pilot.pariahzero.net dbus-daemon[2025881]: [session uid=1000
>> pid=2025879] Activating service name='org.freedesktop.systemd1' requested by
>> ':1.155' (uid=1000 pid=2433850 comm="systemctl --user --failed ")
>> Mar 30 12:08:01 pilot.pariahzero.net dbus-daemon[2025881]: [session uid=1000
>> pid=2025879] Activated service 'org.freedesktop.systemd1' failed: Process
>> org.freedesktop.systemd1 exited with status 1
>> The problem happens for all users on the system.
>> I'll see if I can get more verbose logging to give any additional details 
>> about
>> why org.freedesktop.systemd1 is exiting. If you know offhand, I'd definitely
>> give it a try.
> 
> What's the output of
> apt-cache policy dbus-user-session
> apt-cache policy dbus-x11

Bug#986166: systemd: 'systemd --user' not functional. Regardless of user, org.freedesktop.systemd1 exits with status 1

[Troy Telford]

> On Mar 30, 2021, at 12:22 PM, Michael Biebl  wrote:
> 
> What's the output of
> apt-cache policy dbus-user-session
> apt-cache policy dbus-x11

# apt-cache policy dbus-user-session

dbus-user-session:
  Installed: 1.12.20-2
  Candidate: 1.12.20-2
  Version table:
 1.13.18-2 1
  1 http://ftp.debian.org/debian experimental/main amd64 Packages
 *** 1.12.20-2 500
500 http://ftp.us.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

# apt-cache policy dbus-x11
dbus-x11:
  Installed: 1.12.20-2
  Candidate: 1.12.20-2
  Version table:
 1.13.18-2 1
  1 http://ftp.debian.org/debian experimental/main amd64 Packages
 *** 1.12.20-2 500
500 http://ftp.us.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

Bug#983593: connman: Missing "conflict" dependency information?

[Troy Telford]

Package: connman
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

I do apologize if this is routed poorly, but I figure I have to start
somewhere.

   * What led up to the situation?

I've had an unstable/sid server system working well for decades - its
configuration has overall been pretty stable.

On 2021-02-23, the unattended-upgrades system installed connman (among others)
on my system. connman was never on my system before. I do not know how/why
unattended-upgrades decided to install the package, and I don't even know
who/where to file that bug. (Suggestions welcome... but not your problem)

But it did expose a problem with the connman package: It doesn't appear to
conflict with other interface configuration systems. Having multiple things
changing the network configuration was deeply confusing and hard to debug.

My system would not boot, and there were many network configuration errors. The
package appears to behave quite poorly with ifupdown:
* Classic /etc/network/interfaces.d/ network configurations were being
  configured twice:
* Ifupdown was told to give an interface a static IPv4 address (as
* expected)
* wide-dhcpv6-client was able to initially configure IPv6 for the
  address, but then couldn't upon fixing the static ipv4 address.
* For whatever reason connman was trying a DHCP, not getting it, and
  re-assigned the interface to the 169.254 automatic private ip
  addresses.
* Because of the dual-configuration "race", the system was rendered
  unbootable and unusable, as the two configuration systems appeared to be
  "fighting" each other.
* I couldn't even login locally as root
* often, the system never even reached a login prompt
* It wasn't easy to diagnose the source of why the system wasn't
  booting, but I eventually found it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
* I removed connman, clearing the conflict, so there was only one thing
  trying to configure my network interfaces.
   * What was the outcome of this action?
* After removing connman, the system started behaving
  normally/correctly.
   * What outcome did you expect instead?
* Ideally, unattended upgrades should not have installed connman. I
  don't have the slightest idea who to ask about that situation,
  though. If you could point me in the right direction, I'd be
grateful.
* I imagine a "conflict" in the connman package for other incompatible
  interface configuration systems would be good in general. Having
  multiple interface configuration systems modifying the same
  interfaces seems like a guaranteed race condition.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
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 not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages connman depends on:
ii  dbus 1.12.20-2
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-9
ii  libdbus-1-3  1.12.20-2
ii  libglib2.0-0 2.66.7-1
ii  libgnutls30  3.7.0-7
ii  libreadline8 8.1-1
ii  libxtables12 1.8.7-1
ii  lsb-base 11.1.0

Versions of packages connman recommends:
ii  bluez  5.55-3
pn  ofono  
ii  wpasupplicant  2:2.9.0-20

Versions of packages connman suggests:
pn  connman-vpn  

Bug#935670: No package in Experimental? My observations.

[Troy Telford]

I'm seeing the issue with 1.5~git20190812-107d469-1.


I don't see a package in Experimental, for what it's worth.


sudo apt-get -t experimental install gamemode

Reading package lists... Done

Building dependency tree

Reading state information... Done

gamemode is already the newest version (1.5~git20190812-107d469-1).


That said, what I do see is this error message in syslog:


gamemoded[27352]: Error accessing /usr/libexec/cpugovctl: No such file or

directory


libgamemode0 has the cpugovctl and gpuclockctl commands in /usr/bin.


The gamemoded binary has hardcoded paths to cpugovctl and gpuclockctl.


$ strings `which gamemoded` | grep -E '(cpugovctl|gpuclockctl)'

/usr/libexec/cpugovctl


/usr/libexec/cpugovctl

...  ...

/usr/libexec/gpuclockctl


Placing cpugovctl and gpuclockctl in the PATH won't help (they're already
in

/usr/bin!) -- they have to match where the binary is hardcoded to expect
them.


Either the packaging needs to change to put the binaries in /usr/libexec,
or

the build needs to change the libexec path to /usr/bin.


I'm less familiar with using meson to do builds, so I'd guess it'd be

something like adding "--libexecdir /usr/bin" to the 'meson build' command.

Bug#917989: Probably can close

[Troy Telford]

I rebuilt my (lxc/sid) container from scratch, and copied in the original 
asterisk config.

Asterisk now works perfectly.

I did a filesystem-wide `diff` between the container that is broken and the one 
that works. There’s no smoking gun, unfortunately.

There are definitely no library differences.

What differences exist are differences are expected:  /etc/passwd & friends, 
the apt/dpkg/debconfig state files, snakeoil-certs. The list is not long.

As I’m not seeing anything at all related to asterisk, this bug can be closed.

Bug#917989: LD_DEBUG messages

[Troy Telford]

Below is the bottom stanza from LD_DEBUG, showing the linker error.  I hope 
it’s helpful.

7105:   
   
  7105: object=/lib64/ld-linux-x86-64.so.2 [0]  
 
  7105:  no scope   
 
  7105:   
  7105:  7105: calling init: /usr/lib/asterisk/modules/app_while.so 
   
  7105: 
 
  7105: opening file=/usr/lib/asterisk/modules/app_while.so [0]; 
direct_opencount=1   
  7105: 
 
  7105: 
 
  7105: file=/usr/lib/asterisk/modules/res_http_post.so [0];  
dynamically loaded by asterisk [0]  
 
  7105: file=/usr/lib/asterisk/modules/res_http_post.so [0];  
generating link map 
  7105:   dynamic: 0x7f70276e2be8  base: 0x7f70276dc000   size: 
0x7110
  7105: entry: 0x7f70276de3c0  phdr: 0x7f70276dc040  phnum: 
 9  7105:   

  7105: 
 
  7105: file=libgmime-3.0.so.0 [0];  needed by 
/usr/lib/asterisk/modules/res_http_post.so 
[0] 
 
  7105: find library=libgmime-3.0.so.0 [0]; searching   
  
  7105:  search cache=/etc/ld.so.cache  
  
  7105:   trying file=/lib/x86_64-linux-gnu/libgmime-3.0.so.0   
  
  7105: 
 
  7105: file=libgmime-3.0.so.0 [0];  generating link map
  
  7105:   dynamic: 0x7f70276c29f0  base: 0x7f7027657000   size: 
0x0007d540
  7105: entry: 0x7f702766f580  phdr: 0x7f7027657040  phnum: 
 9  7105:   

  7105: 
 
  7105: file=libnsl.so.1 [0];  needed by 
/lib/x86_64-linux-gnu/libgmime-3.0.so.0 [0] 
  7105: find library=libnsl.so.1 [0]; searching 
 
  7105:  search cache=/etc/ld.so.cache  
  
  7105:   trying file=/lib/x86_64-linux-gnu/libnsl.so.1 
  
  7105: 
 
  7105: file=libnsl.so.1 [0];  generating link map  
  
  7105:   dynamic: 0x7f7027653d78  base: 0x7f702763e000   size: 
0x00018a58
  7105: entry: 0x7f70276426b0  phdr: 0x7f702763e040  phnum: 
 9  7105:   

  7105: 
 
  7105: file=libgpgme.so.11 [0];  needed by 
/lib/x86_64-linux-gnu/libgmime-3.0.so.0 [0]   
  7105: find library=libgpgme.so.11 [0]; searching  
  
  7105:  search cache=/etc/ld.so.cache  
  
  7105:   trying file=/lib/x86_64-linux-gnu/libgpgme.so.11  
  
  7105: 
 
  7105: file=libgpgme.so.11 [0];  generating link map   
  
Inconsistency detected by ld.so: ../elf/dl-tls.c: 73: _dl_next_tls_modid: 
Assertion `result <= GL(dl_tls_max_dtv_idx) + 1' failed! 

Bug#917989: asterisk: Upgrade of libgnutls30 causes Asterisk to fail to load: linker error

[angela . n . troy . telford]

Package: asterisk
Version: 1:13.23.1~dfsg-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
apt-get upgrade included libgnutls30
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Rolling back the filesystem snapshot allowed me to pinpoint the 
package with the linking error. I'm not sure if the bug should be filed against 
libgnutls30 or against asterisk.
   * What was the outcome of this action?
Upgrading libgnutls30 causes asterisk to fail to load, with 
little in terms of log messages by default.  Turning up verbosity and running 
asterisk in the foreground showed an ld linker error against an encryption 
library (judging from the symbol reported).

I then ran 'apt-mark hold' on libgnutls30, and upgraded again 
-- this time with success.

After this bug is finished getting filed, I'll get the full error message I'm 
seeing.

As I said -- I'm unsure if the problem is with libgnutls30, or if asterisk 
simply requires a recompile.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages asterisk depends on:
ii  adduser  3.118
ii  asterisk-config  1:13.23.1~dfsg-1
ii  asterisk-core-sounds-en  1.6.1-1
ii  asterisk-modules 1:13.23.1~dfsg-1
ii  libc62.28-4
ii  libcap2  1:2.25-1.2
ii  libedit2 3.1-20181209-1
ii  libjansson4  2.12-1
ii  libpopt0 1.16-11
ii  libsqlite3-0 3.26.0+fossilbc891ac6b-1
ii  libssl1.11.1.1a-1
ii  libsystemd0  239-14
ii  liburiparser10.9.0-1
ii  libuuid1 2.33-0.2
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxslt1.1   1.1.32-2
ii  lsb-base 10.2018112800

Versions of packages asterisk recommends:
ii  asterisk-moh-opsound-gsm 2.03-1
ii  asterisk-voicemail [asterisk-voicemail-storage]  1:13.23.1~dfsg-1
ii  sox  14.4.2-3

Versions of packages asterisk suggests:
pn  asterisk-dahdi   
ii  asterisk-dev 1:13.23.1~dfsg-1
ii  asterisk-doc 1:13.23.1~dfsg-1
pn  asterisk-ooh323  
ii  asterisk-opus13.7+20171009-1
pn  asterisk-vpb 

-- no debconf information

Bug#798237: looking at dhcpd.c

[Troy Telford]

From debian/patches/disable-nsupdate.patch 

-#define NSUPDATE
+/* #define NSUPDATE */

In looking at server/dhcpd.c, I see a number of NSUPDATE defines; around line
1035, there’s the syslogmessage we’re all seeing.

#if defined (NSUPDATE)
   (DDNS Code)
#else
/* If we don't have support for updates compiled in tell the user */
if (ddns_update_style != DDNS_UPDATE_STYLE_NONE) {
log_fatal("Support for ddns-update-style not compiled in");
}
#endif

That’s the *exact* error message I’m seeing in 4.3.3-3.

The whole point of NSUPDATE is to update DNS… 

As far as bug 712503 (where NSUPDATE was disabled) goes, it makes sense to me
that dhcp would have to hold a random port open so named can communicate with
it.

My guess (having not read the code) is that its behavior isn’t that different
from how a web browser sends opens and sends data from a random port TO the
server… and the reply comes from the server back to the sending port.  The web
browser has to listen on that port to receive the reply.

In the same way, dhcpd has to open the (random) port, and send the data TO
named for NSUPDATE… and also has to hold the port open to receive a reply
(success/failure/whatever) from named.

I’ll grant I’m **totally ignorant** of what actually happens between dhcpd and
named, but it seems sensible to me...
--
Troy Telford
ttelford.gro...@gmail.com

Bug#798237:

[Troy Telford]

I’m also seeing the issue; I rolled back to the previous verison (4.3.2-1) 
using packages from snapshot.debian.org

I have been using the “interim” style for ages…I tried using the “standard” 
ddns style, but when I tried “standard” my syslog shows "Unable to add forward 
map from ” so I have some configuring to do if standard will work.

When using 4.3.3-3, I couldn’t even get a message about being unable to add a 
forward map in my syslog, and they weren’t being added silently.

I see no evidence it’s defaulting to “standard” if “ddns-update-style” isn’t 
set. It certainly looks like ddns-update-style was never compiled in, just like 
the error message says.
--
Troy Telford
ttelford.gro...@gmail.com

Bug#727177: Upgrade of libnss-ldap to 265-1 causes important binaries to segfault

[Troy Telford]

Package: libnss-ldap
Version: 265-1
Severity: normal

Dear Maintainer,
   * What led up to the situation?
  * I upgraded my system using apt-get.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

  After upgrading to nss-ldap-265-1, a substantial number of critical
  system binaries segfault immediately, including:
  * logins
  * zsh
  * bash
  * sudo
  * ssh
  * resolvconf

   * What was the outcome of this action?

  * My system was placed into a state that was impossible to
adminstrate/fix, as I could not login as root, nor could I sudo to
root. Recovery was only possible by booting to a USB drive, and
recovering the system from there. Many login shells would not work
(bash, zsh).

   * What outcome did you expect instead?
  * A clean upgrade, with overall system functionality intact - maybe a
few bugs (perhaps even serious), but not an entirely unusable system.

  After rolling back to a different BTRFS snapshot, I was able to confirm
  this happens when libnss-ldap is upgraded to 265-1.:
  * I rolled back to a pre-upgrade state
  * Made a start snapshot
  * Mounted the start snapshot
  * mounted (bind) /dev, /dev/pts, /proc, /sys into the chroot.
  * chrooted to the start snapshot
  * apt-get install libnss-ldap

  At this point, sudo, zsh, bash, and other programs segfault
  immediately.

   I then held libnss-ldap to version 264-2.5, and ran an apt-get upgrade,
   which was uneventful. I then proceeded to do a snapshot/chroot test cycle,
   and was able to confirm again that upgrading libnss-ldap (and only
   libnss-ldap) would reproduce this issue for me.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libnss-ldap depends on:
ii  debconf [debconf-2.0]  1.5.51
ii  libc6  2.17-93
ii  libcomerr2 1.42.8-1
ii  libgssapi-krb5-2   1.11.3+dfsg-3
ii  libkrb5-3  1.11.3+dfsg-3
ii  libldap-2.4-2  2.4.31-1+nmu2+b1
ii  libsasl2-2 2.1.25.dfsg1-17
ii  multiarch-support  2.17-93

Versions of packages libnss-ldap recommends:
ii  libpam-ldap  184-8.6
ii  nscd 2.17-93

libnss-ldap suggests no packages.

-- debconf information:
* libnss-ldap/confperm: false
* shared/ldapns/ldap-server: ldap://pilot.pariahzero.net/
* libnss-ldap/rootbinddn: cn=admin,dc=pilot,dc=pariahzero,dc=net
* shared/ldapns/ldap_version: 3
  libnss-ldap/override: true
* libnss-ldap/dbrootlogin: true
  libnss-ldap/binddn: cn=proxyuser,dc=example,dc=net
* libnss-ldap/nsswitch:
* shared/ldapns/base-dn: dc=pilot,dc=pariahzero,dc=net
* libnss-ldap/dblogin: false


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706635: Follow-up: Close

[Troy Telford]

After enough digging, I've found the problem:

The user's UID was below 1000 (501, to be exact).

Fixing that appears to have resolved the problem.

This bug can be closed.
--
Troy Telford
ttelford.gro...@gmail.com


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706635: krb5-kdc: Login Programs that use Kerberos Authentication fail to login, hang, use 100% CPU.

[Troy Telford]

Package: krb5-kdc
Version: 1.10.1+dfsg-5
Severity: normal

Dear Kerberos Maintainer,

I now have two entirely unrelated systems with this behavior. It cropped up
about 3-4 weeks ago.

I doubt it's the KDC; I only know it's kerberos related. I honestly don't know
exactly what is the root cause, but it has something to do with apps that
authenticate using kerberos.

Both use Kerberos  LDAP, but are on entirely different networks (ie. home 
office), which are not connected.

When a user attempts to authenticate, the authenticating program then appears
to freeze, and consumes 100% CPU.

The following login programs have this behavior:
* getty
* KDM
* kinit
* kadmin (or does this just call kinit?)
* passwd (ie. to change password Input Kerberos Password)
* netatalk (AFP Server daemon)

The behavior does not happen when using a user that is not authenticated using
Kerberos.

My home system is running Debian Sid, and its data is attached to this bug
report.

The office system is running Ubuntu 13.04 - it's not a Debian system, but I
believe the projects cooperate somewhat. I was surprised to see the exact same
behavior in Ubuntu.

/var/log/auth log shows something like:
Apr 30 21:02:48 pilot afpd[11401]: pam_krb5(netatalk:auth): (user ttelford)
krb_kuserok for user ttelford failed
Apr 30 21:02:48 pilot afpd[11401]: pam_krb5(netatalk:auth): failed
authorization check; logname=ttelford uid=0 euid=0 tty=afpd ruser=
rhost=sluggo.pariahzero.net

/var/log/kdc log shows:
pr 30 21:02:48 pilot.pariahzero.net krb5kdc[7096](info): AS_REQ (4 etypes {18
17 16 23}) 2001:1938:240:1000::1: NEEDED_PREAUTH: ttelf...@pariahzero.net for
krbtgt/pariahzero@pariahzero.net, Additional pre-authentication required
Apr 30 21:02:48 pilot.pariahzero.net krb5kdc[7096](info): AS_REQ (4 etypes {18
17 16 23}) 2001:1938:240:1000::1: ISSUE: authtime 1367377368, etypes {rep=18
tkt=18 ses=18}, ttelf...@pariahzero.net for
krbtgt/pariahzero@pariahzero.net

While the above log messages are from pam_krb5, unless I'm mistaken, kinit,
kadmin, and maybe the passwd change dialog do not use PAM.

If you have any tips on what I can to to narrow down the actual cause, I'd
appreciate it.

Additional Info:
KDC on 'home' system is a Debian 'Sid' System
KDC on 'office' system is an Ubuntu 12.04 system.  The problem only appeared
after upgrading my desktop (not the KDC) to Ubuntu 13.04.



-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages krb5-kdc depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  krb5-config2.3
ii  krb5-user  1.10.1+dfsg-5
ii  libc6  2.13-38
ii  libcomerr2 1.42.5-1.1
ii  libgssapi-krb5-2   1.10.1+dfsg-5
ii  libgssrpc4 1.10.1+dfsg-5
ii  libk5crypto3   1.10.1+dfsg-5
ii  libkadm5clnt-mit8  1.10.1+dfsg-5
ii  libkadm5srv-mit8   1.10.1+dfsg-5
ii  libkdb5-6  1.10.1+dfsg-5
ii  libkeyutils1   1.5.5-7
ii  libkrb5-3  1.10.1+dfsg-5
ii  libkrb5support01.10.1+dfsg-5
ii  libverto1  0.2.2-1
ii  lsb-base   4.1+Debian9

krb5-kdc recommends no packages.

Versions of packages krb5-kdc suggests:
ii  krb5-admin-server 1.10.1+dfsg-5
ii  krb5-kdc-ldap 1.10.1+dfsg-5
ii  openbsd-inetd [inet-superserver]  0.20091229-2

-- debconf information:
* krb5-kdc/debconf: true
* krb5-kdc/run-krb524: false
* krb5-kdc/krb4-mode: disable
  krb5-kdc/purge_data_too: false


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674730: iproute: 'tc qdisc' unable to show or modify queues

[Troy Telford]

Package: iproute
Version: 20120521-1
Severity: normal

After upgrading from iproute_20120319-1 to 20120521-1, I have been unable to
use tc to manage routing queues.

For example:
tc qdisc ls dev eth1
qdisc pfifo_fast 0: root refcnt 2 [Unknown qdisc, optlen=20]

(Note the unknown qdisc, optlen=20)

Similarly, trying to do anyting useful fails:

# tc qdisc add dev eth1 root handle 1: prio bands 3 priomap 1 2 1 1 2 2 2 2 0 0
0 0 1 1 1 1
Unknown qdisc prio, hence option bands is unparsable

Downgrading to 20120319-1 allows tc to work properly again:

# dpkg -i iproute_20120319-1_amd64.deb
dpkg: warning: downgrading iproute from 20120521-1 to 20120319-1.
(Reading database ... 386973 files and directories currently installed.)
Preparing to replace iproute 20120521-1 (using iproute_20120319-1_amd64.deb)

Unpacking replacement iproute ...
Setting up iproute (20120319-1) ...
Processing triggers for man-db ...

# tc qdisc ls dev eth1
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1
1 1


# tc qdisc add dev eth1 root handle 1: prio bands 3 priomap 1 2 1 1 2 2 2 2 0 0
0 0 1 1 1 1
 (no output, no error)



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages iproute depends on:
ii  libc6 2.13-32
ii  libdb5.1  5.1.29-4

Versions of packages iproute recommends:
ii  libatm1  1:2.5.1-1.3

Versions of packages iproute suggests:
pn  iproute-doc  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#663274: Still broken

[Troy Telford]

After updating to lxc-0.8.0-rc3, the behavior I'm seeing is unchanged: 
containers that are autostarted at boot work fine, but I am unable to start 
commands manually - and the linker can't find liblxc.so.0 after I attempt to 
manually load an lxc container, which makes using any of the lxc-commands 
impossible.

$ ldd `which lxc-start`
linux-vdso.so.1 =  (0x7fffe37ff000)
liblxc.so.0 = /usr/lib/x86_64-linux-gnu/lxc/liblxc.so.0 
(0x7f76a51f3000)
libcap.so.2 = /lib/libcap.so.2 (0x7f76a4fc9000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f76a4c41000)
libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f76a4a3e000)
libattr.so.1 = /lib/x86_64-linux-gnu/libattr.so.1 (0x7f76a483a000)
/lib64/ld-linux-x86-64.so.2 (0x7f76a5422000)

$ sudo lxc-start -n radius
lxc-start: Invalid argument - pivot_root syscall failed
lxc-start: failed to setup pivot root
lxc-start: failed to set rootfs for 'radius'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'radius'

$ ldd `which lxc-start`
linux-vdso.so.1 =  (0x771a5000)
liblxc.so.0 = not found
libcap.so.2 = /lib/libcap.so.2 (0x7f5f9a681000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f5f9a2f9000)
libattr.so.1 = /lib/x86_64-linux-gnu/libattr.so.1 (0x7f5f9a0f5000)
/lib64/ld-linux-x86-64.so.2 (0x7f5f9a8ad000)

Is this something that is packaging related, or should I bring up the issue on 
the lxc mailing list?
--
Troy Telford
ttelford.gro...@gmail.com




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#663274: closed by Daniel Baumann daniel.baum...@progress-technologies.net (Bug#663274: fixed in lxc 0.8.0~rc1-3)

[Troy Telford]

After updating to lxc-0.8.0-rc3, I'm seeing the behavior of lxc is unchanged.

$ dpkg -l | grep lxc
ii  lxc  0.8.0~rc1-3  Linux 
Containers userspace tools
ii  lxc-dbg  0.8.0~rc1-3  Linux 
Containers userspace tools (debug)
ii  lxc-dev  0.8.0~rc1-3  Linux 
Containers userspace tools (development)

# lxc-start -n radius
lxc-start: Invalid argument - pivot_root syscall failed
lxc-start: failed to setup pivot root
lxc-start: failed to set rootfs for 'radius'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'radius'

- lxc tools continue to 'lose' their ability to see liblxc.so.0 after 
attempting to start LXC.

$ ldd `which lxc-console`
linux-vdso.so.1 =  (0x7fff2a7b)
liblxc.so.0 = not found
libcap.so.2 = /lib/libcap.so.2 (0x7fd837daf000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fd837a27000)
libattr.so.1 = /lib/x86_64-linux-gnu/libattr.so.1 (0x7fd837823000)
/lib64/ld-linux-x86-64.so.2 (0x7fd837fdb000)

Yet, containers set to autoload at boot run without problems, and I can use 
lxc-console to connect to their running consoles -- at least, I can do so until 
I try to start a container using 'lxc-start.'

On Mar 10, 2012, at 2:06 AM, Debian Bug Tracking System wrote:

 This is an automatic notification regarding your Bug report
 which was filed against the lxc package:
 
 #663274: lxc: Can't start containers.
 
 It has been closed by Daniel Baumann 
 daniel.baum...@progress-technologies.net.
 
 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact Daniel Baumann 
 daniel.baum...@progress-technologies.net by
 replying to this email.
 
 
 -- 
 663274: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663274
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems
 
 From: Daniel Baumann daniel.baum...@progress-technologies.net
 Subject: Bug#663274: fixed in lxc 0.8.0~rc1-3
 Date: March 10, 2012 2:02:37 AM MST
 To: 663274-cl...@bugs.debian.org
 
 
 Format: 1.8
 Date: Sat, 10 Mar 2012 09:51:28 +0100
 Source: lxc
 Binary: lxc lxc-dbg lxc-dev
 Architecture: source i386
 Version: 0.8.0~rc1-3
 Distribution: unstable
 Urgency: low
 Maintainer: Daniel Baumann daniel.baum...@progress-technologies.net
 Changed-By: Daniel Baumann daniel.baum...@progress-technologies.net
 Description: 
 lxc- Linux Containers userspace tools
 lxc-dbg- Linux Containers userspace tools (debug)
 lxc-dev- Linux Containers userspace tools (development)
 Closes: 663274
 Changes: 
 lxc (0.8.0~rc1-3) unstable; urgency=low
 .
* Adding pre-depends to multiarch-support (Closes: #663274).
* Updating lintian overrides.
 Checksums-Sha1: 
 cadaee224a3cc01f38d6e2100c355f02ff75446c 1260 lxc_0.8.0~rc1-3.dsc
 84f91433f94cbbe22d13369540a4db53d3804fdf 45812 lxc_0.8.0~rc1-3.debian.tar.gz
 36e80787d146aebfee8d4b600ff9dbcd5d94225e 196886 lxc_0.8.0~rc1-3_i386.deb
 85f5e73600df7631cdd072e3042907863a00b6d1 215494 lxc-dbg_0.8.0~rc1-3_i386.deb
 5badfe31b5968b9756aabc06059aae35c1ac4704 19926 lxc-dev_0.8.0~rc1-3_i386.deb
 Checksums-Sha256: 
 4d74bd7b6b92049374518e38245b5535eb8cafb981c556ba843bc989fca0faaa 1260 
 lxc_0.8.0~rc1-3.dsc
 96ee9b7b7318cfc23efec071202b52c4a3fd48642999f95f982b58e35993fe79 45812 
 lxc_0.8.0~rc1-3.debian.tar.gz
 02fc78a5fd0283a709a7bd165c47a7d23f47a09f8c1de8586b0219935034e35e 196886 
 lxc_0.8.0~rc1-3_i386.deb
 b5e5866d318fdeb0a80d2e88e23e2ef6719ef171c127c05de78863dbbb9b1c28 215494 
 lxc-dbg_0.8.0~rc1-3_i386.deb
 ef7d47013c30147345a2db3a5d2fc05aaf450cb4ee91f49366b1c696823d558d 19926 
 lxc-dev_0.8.0~rc1-3_i386.deb
 Files: 
 f45513dd72b0b524bb0ed22a1f39c317 1260 admin optional lxc_0.8.0~rc1-3.dsc
 b10226515f2e09c4ba47d6ca74cd3d03 45812 admin optional 
 lxc_0.8.0~rc1-3.debian.tar.gz
 368b32ddec9f4447c79ecca374c2dd8c 196886 admin optional 
 lxc_0.8.0~rc1-3_i386.deb
 21cfe8462d06e3f757005f7549d0aca2 215494 debug extra 
 lxc-dbg_0.8.0~rc1-3_i386.deb
 ee853cbf48edb9674c71e73bcf89a967 19926 libdevel optional 
 lxc-dev_0.8.0~rc1-3_i386.deb
 
 
 
 
 From: Troy Telford ttelford.gro...@gmail.com
 Subject: lxc: Can't start containers.
 Date: March 9, 2012 5:38:16 PM MST
 To: Debian Bug Tracking System sub...@bugs.debian.org
 
 
 Package: lxc
 Version: 0.8.0~rc1-2
 Severity: important
 
 This is probably related to #663062, possibly a dup.
 
 I haven't rebooted my system in a few months, so I haven't noticed this until
 now:
 
 Prior to the reboot, I was using kernel 3.2.0-1-amd64, post-reboot is
 3.2.0-2-amd64 (I've done several boots since; the kernel version doesn't seem
 to matter)
 
 I run a sid machine, and am using the 'latest' version of LXC available (was
 0.7.5-24 until this afternoon, when

Bug#663274: lxc: Can't start containers.

[Troy Telford]

Package: lxc
Version: 0.8.0~rc1-2
Severity: important

This is probably related to #663062, possibly a dup.

I haven't rebooted my system in a few months, so I haven't noticed this until
now:

Prior to the reboot, I was using kernel 3.2.0-1-amd64, post-reboot is
3.2.0-2-amd64 (I've done several boots since; the kernel version doesn't seem
to matter)

I run a sid machine, and am using the 'latest' version of LXC available (was
0.7.5-24 until this afternoon, when it bumped to 0.8.0~rc1-2, I believe)

I have several known good containers; some auto-launch at boot, others are
manually started.

The auto-launched containers run fine, however I'm entirely unable to load the
containers manually:

With yesterday's lxc package:

$ lxc-start -n radius
lxc-start: Invalid argument - pivot_root syscall failed
lxc-start: failed to setup pivot root
lxc-start: failed to set rootfs for 'radius'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'radius'
lxc-start: Device or resource busy - failed to remove cgroup
'/sys/fs/cgroup//lxc/radius'

And with 0.8.0-rc1-2:
lxc-start -n mumble
lxc-start: Invalid argument - pivot_root syscall failed
lxc-start: failed to setup pivot root
lxc-start: failed to set rootfs for 'mumble'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'mumble'

Interestingly enough, I also have a problem with other LXC tools:
After a fresh reboot, if I use 'lxc-console' on an auto-started (running)
container, it works as expected.

HOWEVER...

After I attempt (and fail) to start a container manually (using lxc-start [-d]
-n name), lxc-console shows:
lxc-console: error while loading shared libraries: liblxc.so.0: cannot open
shared object file: No such file or directory

lxc-console does exist:
/usr/lib/lxc/liblxc.so.0 - /usr/lib/lxc/liblxc.so.0.7.5 (it's a valid symlink;
/usr/ib/lxc/liblxc.so.0.7.5 also exists).

But...
# ldd $(which lxc-console)
linux-vdso.so.1 =  (0x7fffbddff000)
liblxc.so.0 = not found
libcap.so.2 = /lib/libcap.so.2 (0x7fc101132000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fc100daa000)
libattr.so.1 = /lib/x86_64-linux-gnu/libattr.so.1 (0x7fc100ba6000)
/lib64/ld-linux-x86-64.so.2 (0x7fc10135e000)

I have to admit: I'm a bit WTF'd out by the way liblxc 'vanishes' as far as
lxc-console (and other lxc tools). I'm not sure (yet) if I have to reboot, or
reinstall lxc to get liblxc to be located by the linker.



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.41
ii  libc6  2.13-27
ii  libcap21:2.22-1

Versions of packages lxc recommends:
ii  debootstrap  1.0.38
ii  libcap2-bin  1:2.22-1

Versions of packages lxc suggests:
ii  lxctl  0.3.1+debian-1

-- debconf information:
  lxc/directory: /var/lib/lxc
  lxc/title:
  lxc/auto: true
  lxc/shutdown: stop



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#663274: Acknowledgement (lxc: Can't start containers.)

[Troy Telford]

Just a minor follow-up:
- After a reboot, lxc-console is able to find liblxc.so.0.
- This means that the problem doesn't require reinstallation, but does 
require a reboot.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#661974: asterisk: Pass the correct value to ast_timer_set_rate() for IAX2 trunking.

[Troy Telford]

Package: asterisk
Version: 1.8.8.2~dfsg-1
Severity: important

Dear Maintainer,

This may be the same root cause as #481702 - the symptoms are somewhat similar.

For my asterisk system, I was using IAX2 with trunking enabled. The call
quality (outgoing voice only) was bad - skips, sub-second silences inserted,
and what sounded like encoder problems.

I consulted the mailing list, and a few useful things were learned:
   - I was using trunking. By turning trunking off, the problem vanished.
   - A Digium employee (developer?) told me there was a very recently
 discovered/fix bug in the IAX2 code, and that the fix is in the current
 SVN.
   - A cursory look at the Asterisk SVN repository shows r355746 and possibly
 r355793. There are a couple of additional commits around the same time
 that seem to deal with IAX2 trunking (r355458, r355448).
   - So while I know the fix is in SVN, I'm not sure exactly what the full
 patch would consist of.



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#652699: libverto-libev1 makes it work.

[Troy Telford]

I'd like to add that I am seeing this issue as well; have been since Nov 30 or 
so, but haven't gotten around to fixing it until now.

I wasn't able to get my kdc to start (debian+sid+mit kerberos)

After following Josh's advice of adding libverto-libev1, I was able to start 
both my KDC and kadmin server.
--
Troy Telford
troy.telf...@gmail.com




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#646598: A temporary patch

[Troy Telford]

A patch that works for me is the following; I'm basically making it so it 
doesn’t try to use /usr/bin/python (which is Python 2.7), and instead having it 
try /usr/bin/python2.6 first (which works).

First, for /usr/bin/caldavd
--- caldavd 2012-01-20 15:48:11.287759928 -0700
+++ /usr/bin/caldavd2012-01-20 15:45:50.183936151 -0700
@@ -46,7 +46,7 @@
   return 0;
 }
 
-for v in  2.6 2.5; do
+for v in 2.6 2.5; do
   for p in  \
 ${PYTHON:=}   \
 python${v}\


And for the init script:

diff --git a/init.d/calendarserver b/init.d/calendarserver
index b260b33..6b0d95b 100755
--- a/init.d/calendarserver
+++ b/init.d/calendarserver
@@ -57,7 +57,7 @@ case $1 in
   stop)
log_daemon_msg Stopping $DESC $NAME
if start-stop-daemon --oknodo --stop --quiet --pidfile $RUNDIR$NAME.pid 
\
-   --exec /usr/bin/python; then
+   --exec /usr/bin/python2.6; then
log_end_msg 0
RET=0
else
@@ -74,7 +74,7 @@ case $1 in
if check_start_daemon; then
log_daemon_msg Restarting $DESC $NAME
start-stop-daemon --stop --quiet --oknodo  --pidfile \
-   $RUNDIR$NAME.pid --exec /usr/bin/python
+   $RUNDIR$NAME.pid --exec /usr/bin/python2.6
sleep 1
if start-stop-daemon --start --quiet --pidfile \
$RUNDIR$NAME.pid --exec $DAEMON -- $DAEMON_OPTS 
2/dev/null; then


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#646598: Patch that helps

[Troy Telford]

The following patch appears to work for me; all I'm doing is changing the 
script so it looks for the python2.6 binary, then the python2.5 binary.  (the 
default would also check the 'python' binary, which is a link to python2.7 - 
and it's the use of python2.7 that is breaking things.

--- caldavd 2012-01-20 15:48:11.287759928 -0700
+++ /usr/bin/caldavd2012-01-20 15:45:50.183936151 -0700
@@ -46,7 +46,7 @@
   return 0;
 }
 
-for v in  2.6 2.5; do
+for v in 2.6 2.5; do
   for p in  \
 ${PYTHON:=}   \
 python${v} 
--
Troy Telford
ttelf...@me.com




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#649431: asterisk: Segmentation fault in asterisk -r

[Troy Telford]

The new package works for me.  Thanks!
--
Troy Telford
ttelford.gro...@gmail.com

On Nov 25, 2011, at 8:11 AM, Tzafrir Cohen wrote:

 tags 649431 + pending
 thanks
 
 On Fri, Nov 25, 2011 at 02:38:28PM +0200, Tzafrir Cohen wrote:
 Update:
 
 When I rebuild this on my Wheezy development system (not in a chroot),
 all's well.
 
 When I build it in a Sid chroot on that Wheezy system, all's well.
 
 This is not correct. The script to run this was wrong.
 
 It seems that the removal of the libncurses build dependency was
 incorrect. However it has only manifested itself as a run-time error by
 the internal editline.
 
 Re-adding that dependency solved the problem for now. In the long run:
 https://reviewboard.asterisk.org/r/1528/
 
 -- 
   Tzafrir Cohen
 icq#16849755  jabber:tzafrir.co...@xorcom.com
 +972-50-7952406   mailto:tzafrir.co...@xorcom.com
 http://www.xorcom.com  iax:gu...@local.xorcom.com/tzafrir
 
 
 
 -- 
 To unsubscribe, send mail to 649431-unsubscr...@bugs.debian.org.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#649431: segmentation fault in asterisk -r

[Troy Telford]

After running an apt-get dist-upgrade (which upgraded perl, among other things)

I now have discovered new behavior:

With every valid TERM=foo, 'asterisk -r' segfaults.  The list I tried (ie. 
export TERM=foo; asterisk -r) is:
Eterm
ansi
cons25
cons25-debian
cygwin
dumb
hurd
linux
mach
mach-bold
mach-color
pcansi
rxvt
rxvt-basic
rxvt-unicode
screen
screen-256color
screen-256color-bce
screen-bce
screen-s
screen-w
sun
vt100
vt102
vt220
vt52
wsvt25
wsvt25m
xterm
xterm-256color
xterm-color
xterm-debian
xterm-mono
xterm-r5
xterm-r6
xterm-vt220
xterm-xfree86

It appears that TERM must be set to an invalid terminal type (ie. nothing in 
/lib/terminfo) for 'asterisk -r' to work:
export TERM=unknown
Connected to Asterisk 1.8.7.1~dfsg-1 currently running on voip (pid = 
28745) 
No entry for terminal type unknown; 
using dumb terminal settings. 
voip*CLI
export TERM=something_random
Connected to Asterisk 1.8.7.1~dfsg-1 currently running on voip (pid = 
28745)
No entry for terminal type something_random;
using dumb terminal settings.
voip*CLI
export TERM=to_infinity_and_beyond
root@voip:~# asterisk -r
Connected to Asterisk 1.8.7.1~dfsg-1 currently running on voip (pid = 
28745)
No entry for terminal type to_infinity_and_beyond;
using dumb terminal settings.

If TERM doesn't exist, or is a valid terminal type, I get a segfault.
root@voip:~# unset TERM
root@voip:~# asterisk -r
Connected to Asterisk 1.8.7.1~dfsg-1 currently running on voip (pid = 
28745)
[429565.756093] asterisk[30475]: segfault at 801512c0 ip 
0051ed74 sp 7fff80150980 error 4 in asterisk[40+1a3000]
Segmentation fault

root@voip:~# export TERM=linux
root@voip:~# asterisk -r
Connected to Asterisk 1.8.7.1~dfsg-1 currently running on voip (pid = 
28745)
[429601.269320] asterisk[30481]: segfault at 27772270 ip 
0051ed74 sp 7fff27771930 error 4 in asterisk[40+1a3000]
Segmentation fault

I hope this helps nail down the problem.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#649431: segmentation fault in asterisk -r

[Troy Telford]

With asterisk 1:1.8.7.1~dfsg-1, I am also reproducing this error; my core dump 
shows:

root@voip:# gdb `which asterisk` core
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/sbin/asterisk...Reading symbols from 
/usr/lib/debug/usr/sbin/asterisk...done.
done.
[New LWP 21268]
[New LWP 21269]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Core was generated by `rasterisk g -r'.
Program terminated with signal 11, Segmentation fault.
#0  0x0051ed74 in term_alloc (el=0x2203780, t=0x5770c0, cap=0x178552e0 
Address 0x178552e0 out of bounds) at term.c:398
398 term.c: No such file or directory.
in term.c
(gdb)

As far as terminal information, I've reproduced the problem with the following:
- Serial TTY (using GNU screen as the terminal emulator)
- ssh session from KDE (Konsole; TERM=xterm)
- Linux Console (ie. no X11; TERM=linux)
- SSH from OS X Terminal (TERM=xterm-256color)
- Xen serial console (I've also created an entirely clean debian 'sid' virtual 
machine (using xen-tools), installed asterisk, and was able to reproduce the 
error)

And, as is the case with Vincent Smeets, the problem started when I installed 
Asterisk 1.8.7.1~dfsg-1.

However, unlike Vincent, unsetting the TERM environment variable does NOT make 
the problem go away; I still get a segmentation fault with exit status 139, 
every time, from every terminal (local and remote) that I've attempted to use.
--
Troy Telford



--
Troy Telford
ttelford.gro...@gmail.com




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642502: dahdi-source 2.4.1 does not build on Linux 3.x

[Troy Telford]

Package: dahdi-source
Severity: important

Dear Maintainer,
   * What led up to the situation?
I'm installing dahdi on a testing machine, and trying to build using
module-assistant. (m-a a-i dahdi)
   * What was the outcome of this action?
Modules did not build.
   * What outcome did you expect instead?
Kernel modules should build.

I've been able to build the modules for dahdi 2.5.0.1 successfully, and by
disabling the three EXTRA_MODS (and dropping the debian dir on top of the
2.5.0.1 sources), I was able to use module-assistant to build a package with
the kernel modules.

So it looks like an update to a newer release of dahdi for releases that use
kernel 3.x is appropriate.



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#551286: linux-image-2.6.30-2-amd64 doesn't start software raid on boot

[Troy Telford]

Package: linux-image-2.6.30-2-amd64
Version: 2.6.30-8
Severity: normal

This does not happen on 2.6.30-1-amd64, so I simply use the older kernel for 
now; when the older kernel boots, I do see the software raid being detected and 
configured.

My system uses software RAID on all of its drives, including the boot device.

linux-image-2.6.30-2-amd64 refuses to boot for me; it cannot find the root 
filesystem, and it appears the reason is because it can't find any of the 
software raids.  The uuid's for the software raid devices are not present, nor 
are the normal /dev/md? entries.  /proc/mdstat doesn't exist either.

I've taken a full log of the boot (via serial console), and dumped it to a 
file, which I'll include as an attachment.


-- Package-specific info:

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6.30-2-amd64 depends on:
ii  debconf [debconf-2.0] 1.5.27 Debian configuration management sy
ii  initramfs-tools [linux-initra 0.93.4 tools for generating an initramfs
ii  module-init-tools 3.10-3 tools for managing Linux kernel mo

linux-image-2.6.30-2-amd64 recommends no packages.

Versions of packages linux-image-2.6.30-2-amd64 suggests:
pn  grub | lilo   none (no description available)
pn  linux-doc-2.6.30  none (no description available)

-- debconf information:
  linux-image-2.6.30-2-amd64/preinst/bootloader-initrd-2.6.30-2-amd64: true
  linux-image-2.6.30-2-amd64/preinst/initrd-2.6.30-2-amd64:
  linux-image-2.6.30-2-amd64/preinst/lilo-has-ramdisk:
  linux-image-2.6.30-2-amd64/postinst/kimage-is-a-directory:
  linux-image-2.6.30-2-amd64/preinst/abort-install-2.6.30-2-amd64:
  linux-image-2.6.30-2-amd64/postinst/depmod-error-initrd-2.6.30-2-amd64: false
  linux-image-2.6.30-2-amd64/preinst/overwriting-modules-2.6.30-2-amd64: true
  linux-image-2.6.30-2-amd64/postinst/old-dir-initrd-link-2.6.30-2-amd64: true
  linux-image-2.6.30-2-amd64/postinst/old-system-map-link-2.6.30-2-amd64: true
  linux-image-2.6.30-2-amd64/preinst/elilo-initrd-2.6.30-2-amd64: true
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.30-2-amd64/preinst/failed-to-move-modules-2.6.30-2-amd64:
  linux-image-2.6.30-2-amd64/prerm/would-invalidate-boot-loader-2.6.30-2-amd64: 
true
  linux-image-2.6.30-2-amd64/postinst/old-initrd-link-2.6.30-2-amd64: true
  linux-image-2.6.30-2-amd64/postinst/bootloader-error-2.6.30-2-amd64:
  linux-image-2.6.30-2-amd64/prerm/removing-running-kernel-2.6.30-2-amd64: true
  linux-image-2.6.30-2-amd64/postinst/depmod-error-2.6.30-2-amd64: false
  linux-image-2.6.30-2-amd64/preinst/lilo-initrd-2.6.30-2-amd64: true
  linux-image-2.6.30-2-amd64/preinst/abort-overwrite-2.6.30-2-amd64:
  linux-image-2.6.30-2-amd64/postinst/create-kimage-link-2.6.30-2-amd64: true
  linux-image-2.6.30-2-amd64/postinst/bootloader-test-error-2.6.30-2-amd64:
   [Linux-bzImage, setup=0x3000, size=0x21bba0]
   [Initrd, addr=0x37873000, size=0x77c9c5]
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.30-2-amd64 (Debian 2.6.30-8) 
(wa...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-3) ) #1 SMP Fri Sep 25 
22:16:56 UTC 2009
[0.00] Command line: BOOT_IMAGE=/vmlinuz-2.6.30-2-amd64 
root=UUID=e5c87f98-51b3-4073-a043-3fdc532dc611 ro console=ttyS0,115200
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009ac00 (usable)
[0.00]  BIOS-e820: 0009f800 - 000a (reserved)
[0.00]  BIOS-e820: 000f - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 7fee (usable)
[0.00]  BIOS-e820: 7fee - 7fee3000 (ACPI NVS)
[0.00]  BIOS-e820: 7fee3000 - 7fef (ACPI data)
[0.00]  BIOS-e820: 7fef - 7ff0 (reserved)
[0.00]  BIOS-e820: f000 - f400 (reserved)
[0.00]  BIOS-e820: fec0 - 0001 (reserved)
[0.00] DMI 2.4 present.
[0.00] last_pfn = 0x7fee0 max_arch_pfn = 0x1
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] init_memory_mapping: -7fee
[0.00] RAMDISK: 37873000 - 37fef9c5
[0.00] ACPI: RSDP 000f6b40 00014 (v00 GBT   )
[0.00] ACPI: RSDT 7fee3040 0003C (v01 GBTGBTUACPI 42302E31 
GBTU 01010101)
[0.00] ACPI: FACP 7fee30c0 00074 (v01 GBTGBTUACPI 42302E31 
GBTU