Today I had an unexpected reboot and was shocked (but pleased) to see the
current stable (bullseye) named started without problems!
I checked "aa-remove-unknown -n" output (as in my previous update) but this
time there was no mysterious "/usr/sbin/named" profile to be removed, and with
it not
I had my head buried in the sand on this until this week when bullseye got
released and my bind9 package I had pinned to "stable" upgraded and predictably
broke again.
This time, I was able to review Marc's message from 20 February, which was
quite interesting.
I also found two conflicting
I have another data point to contribute, courtesy of DTE - our local power
company - and a power outage that lasted longer than my UPS battery...
First, the problem still exists with bind9 9.16.4-1+b1.
Second (and most interestingly), this version WILL start successfully if you
are upgrading
to retest with tracing, but I'm still trying to get a window where I have
free time and the rest of my household is willing to take the DNS hit.
Thanks,
Scott
-Original Message-
From: Michael Biebl
Sent: Tuesday, May 19, 2020 8:43 AM
To: 958...@bugs.debian.org; Scott Bailey
Subject: Re
Sent: Monday, April 27, 2020 11:43 AM
To: Scott Bailey ; 958...@bugs.debian.org
Subject: Re: Bug#958934: bind9: named fails to start after upgrade to 9.16.2
On 2020-04-27 11:33 a.m., Scott Bailey wrote:
> buzz:~# journalctl -k -b0 | grep -F apparmor
> buzz:~#
>
> So whatever's going on
Thanks, Simon!
buzz:~# journalctl -k -b0 | grep -F apparmor
buzz:~#
So whatever's going on, it doesn't look like AppArmor has anything to do with
it.
Cheers,
Scott
-Original Message-
From: Simon Deziel
Sent: Monday, April 27, 2020 10:10 AM
To: Scott Bailey ; 958...@bugs.debian.org
I can't find anything wrong with /run/named. On the system now:
buzz:~# ls -la /run/named
total 8
drwxrwxr-x 2 root bind 80 Apr 26 17:46 .
drwxr-xr-x 58 root root 1940 Apr 26 16:23 ..
-rw-r--r-- 1 bind bind7 Apr 26 17:46 named.pid
-rw--- 1 bind bind 102 Apr 26 17:46 session.key
Package: bind9
Version: 1:9.16.2-3
Severity: critical
Justification: breaks unrelated software
Dear Maintainer,
Life was good on my DNS server until my recent update to 9.16.2-3.
After upgrading, the exact configuration that was happy now fails to
start. Example:
# named -g -u bind
26-Apr-2020
Package: accountsservice
Version: 0.6.45-1
Followup-For: Bug #908293
Dear Maintainer,
I noticed in passing that the accounts-daemon process is consuming 99%+ of
one
of my processors, on a long-term ongoing basis, and neither restarts (via
systemctl) nor reboots seem to be curbing its enthusiasm.
New version 4.17.0-1-amd64 fixes this problem for me. This report can be marked
as resolved and closed.
Thanks,
Scott
Package: src:linux
Version: 4.16.16-2
Severity: important
Dear Maintainer,
This system hosts several KVM guests and a simh VAX, all of which connect to
the local network using bridge br0:
buzz:~# brctl show br0
bridge name bridge id STP enabled interfaces
br0
on systemd, since it only
occurs
in multi-user (or graphic) runlevels, but ultimately I do not believe that
any
program should trigger a kernel panic in normal operation, and so you get
this
wonderful report. ;-)
Regards,
Scott Bailey <sc...@cartasoft.com>
-- Package-specific info:
** Version:
L
I encountered exactly the same problem. Happily the proposed fix worked
for me too, although I tweaked it slightly to read:
if (m == None or m.group(3) != remote_filename):
Cheers,
Scott
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
.
Thanks,
Scott Bailey
sc...@cartasoft.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: samba4
Version: 4.0.0~beta1+dfsg1-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I recently attempted to install the samba4 package on my system; this fails
persistently with the following output:
Setting up samba4 (4.0.0~beta1+dfsg1-1) ...
Traceback (most
logfiles cluttered with this output. In case this is less generic
than I think, the two specific use cases in my script are:
duplicity --asynchronous-upload local-dir scp://user@host/remote-dir
duplicity remove-older-than interval --force scp://user@host/remote-dir
Thanks,
Scott Bailey
sc
Package: mediatomb
Version: 0.12.1-2
Severity: normal
Tags: upstream
I'm guessing about the upstream part. I happened to notice my system has a
huge /var/log/mediatomb.log.5 file that's still being written.
The /etc/logrotate.d/mediatomb script specifies that a pkill -HUP mediatomb
should be
Package: linux-2.6
Version: 2.6.32-15
Severity: normal
Here is an oops reported by my system against my trusty DE500 card:
Jun 8 09:34:04 buzz kernel: [213252.816043] WARNING: at
Well, this is interesting...
In an attempt to minimize the impact of this problem, I switched my config
to use the DEC tulip-based card I also have in my system. This morning I got
almost exactly the same trace (inline below). This suggests that whatever
the problem is, it isn't specific to just
Package: linux-2.6
Version: 2.6.32-15
Severity: normal
This appears to be the same bug as:
https://bugzilla.kernel.org/show_bug.cgi?id=11663
I have attached kernel output; once the timeout occurs, the interface is
unusable and bounces spastically (without becoming operational) until the
system
Package: linux-image-2.6.30-1-alpha-smp
Version: 2.6.30-2
Severity: important
Well, the firmware loading logic has been flaky on my system for a few
releases now. I previously reported bug 527265 against 2.6.29, where the
qla1040 firmware would not load at all, and that was resolved in a later
Package: linux-image-2.6.29-1-alpha-smp
Version: 2.6.29-3
Severity: important
Yes, I have the firmware on the system. The non-free package
firmware-qlogic (from sid) is installed, /lib/firmware/qlogic/1040.bin
exists and update-initramfs doesn't whine about missing firmware. ;-)
See the
Package: linux-image-2.6.29-1-sparc64
Version: 2.6.29-3
Severity: normal
This kernel fails to boot on my Ultra60. Immediately after loading the initrd
image,
the message Fast Data Access MMU Miss appears and I get dropped back to the
PROM
ok prompt without any additional output.
This appears
Package: duplicity
Version: 0.5.06-2
Severity: wishlist
Tags: patch
I find myself attempting to perform secure backups that must transit a proxy
server to reach their destination. Generally I use PuTTY for these types of
connections, as it understands how to deal with the proxy (unlike OpenSSH).
Package: linux-image-2.6.25-2-amd64
Version: 2.6.25-2
Severity: normal
I see that both linux-image-2.6.25-1-amd64 and
linux-image-2.6.25-2-amd64 no longer include the atp870u SCSI module
(normally selected via CONFIG_SCSI_ACARD). This is a bummer since I have
one of these cards in my system. :-p
Package: initramfs-tools
Version: 0.92a
Severity: important
This seems very similar to reported (old) bugs, but it's a change in
behavior for me so I'm opening this new problem to flag it. I recently
updated to version 0.92 (I believe -- a couple days prior to 0.92a,
which also exhibits the
Package: aboot
Version: 1.0~pre20040408-2
Severity: important
My present kernel (2.6.22-3-alpha-smp) is the last Debian
kernel I have been able to boot successfully. I spent a lot of time
thinking this might be the kernel, but on reflection reading the console
output I blame aboot. :-)
For
Package: linux-image-2.6.24-1-alpha-smp
Version: 2.6.24-2
Severity: normal
I think the subject line says it all; this is on a 3-way AS4100. I am
attaching console output of a boot attempt. As failure occurs prior to
loading the initrd image, I am not sure any further configuration
details are
(bypassing the canonicalize_name()
call) in the event no_ccache is specified. This does not seem right to
me either, but has no direct bearing on the bug that is driving me nuts
at the moment. :-)
Thanks for a sanity-saving library,
Scott Bailey
[EMAIL PROTECTED]
-- System Information:
Debian
-copy_exec /lib/lvm-200/vgchange /sbin
+copy_exec /sbin/lvm /sbin/vgchange
for x in dm_mod dm_snapshot dm_mirror; do
manual_add_modules ${x}
Thanks,
Scott Bailey
[EMAIL PROTECTED]
-- Package-specific info:
-- /proc/cmdline
root=/dev/md0 ro
-- /proc/filesystems
cramfs
Package: bacula-director-pgsql
Version: 1.38.11-6
Severity: minor
I assume this is a bogus dependency that crept in during the build process.
-- System Information:
Debian Release: testing/unstable
Architecture: alpha
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-6+scsi
Locale:
Package: mdadm
Version: 2.5.2-7
Severity: minor
The automatic check on first Sunday of month logic is b0rken. :-) The
specifier used in /etc/cron.d/mdadm is 6 1 1-7 * 7, but the problem is
that man 5 crontab (and unhappy experience) shows that the rule
triggers when minute, hour, month (6, 1,
Package: bacula-sd
Version: 1.38.9-7
Severity: important
I just upgraded from the long-suffering 1.36.3 release and started
tweaking my bacula-sd.conf file to add an Autochanger stanza as required
for the new version. With my old 1.36.3 configuration, everything ran
okay if you overlooked the
, but I am
erring on the side of longer since these errant errors really screw up
my backups and restores.
I have posted to linux-scsi on this but haven't gotten much of a
response. I'll report this there too but figured it would be better to
have more eyes on the problem.
Thanks,
Scott Bailey
Package: nfs-kernel-server
Version: 1:1.0.7-9
Severity: important
The change introduced in this update to check for init_nfsd instead of
nfsd_version caused the server to fail to restart on my system after
this upgrade. I manually edited /etc/init.d/nfs-kernel-server to change
the test back to
on request, they just
seemed a little lengthly to stuff into the initial bug report.
I don't think it is important, but the referenced T0 line from
/etc/inittab is this:
T0:23:respawn:/sbin/getty -L ttyS0 9600 vt102
Thanks,
Scott Bailey
[EMAIL PROTECTED]
-- System Information:
Debian Release
,
Scott Bailey
[EMAIL PROTECTED]
--- drivers/md/md.c.orig2005-02-07 15:44:50.0 -0500
+++ drivers/md/md.c 2005-07-06 10:55:56.0 -0400
@@ -336,8 +336,6 @@
struct completion event;
int ret;
- bio_get(bio);
-
rw |= (1 BIO_RW_SYNC
Package: onak
Version: 0.3.2-1
Severity: important
I don't know if this is an actual bug, or just user stupidity. :-) I
haven't done a lot of playing with onak, but decided to exercise it a
little bit by loading it with the debian keyring:
gpg --export --keyring
Package: bind9
Version: 1:9.3.1-2
Severity: important
Bummer. I just updated and find that /usr/sbin/dnssec-makekeyset is
missing, making it very difficult to generate my signed zone files. :-(
Interestingly, although dpkg -L does not show this file is included in
this package, looking at
Package: bacula-sd
Version: 1.36.2-2
Severity: normal
I noticed this change in behavior when I upgraded my system from kernel
2.4.27 to 2.6.10. Attempting to position to the end of data on a tape in
order to append backups no longer works:
unmount
mount
run something
09-May 16:02 hamster-sd:
40 matches
Mail list logo
