Bug#883938: Bug #883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51
The provided work-around (setting numa=off) worked here.
Do you need further information about the system in use?
BTW: Thank you for the NUMA advice, it was about 21.00 CET when
I started a search engine and found the bug entry and the suggested
work-around, so, your advice came just in time.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 -
signature.asc
Description: PGP signature
Bug#866110: multipath-tools: mpathpersist segfaults. Newer version is available and fixed!
Package: multipath-tools Version: 0.6.4-5 Severity: grave Justification: renders package unusable Dear Maintainer, the mpathpersist command segfaults. I got it fixed, but discovered, that a similiar fix is already applied upstream. Git commit fef089a6610f94a847541069f3008a5708044015 in the upstream sources fixes this problem! I've added the above mentioned patch manually and installed the package as a NMU and it works. At least the segfaults are gone. I'm not sure if the tool is working properly though. -- Package-specific info: /etc/multipath.conf does not exist. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.11.1 (SMP w/4 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 multipath-tools depends on: ii init-system-helpers 1.48 ii kpartx 0.6.4-5 ii libaio1 0.3.110-3 ii libc62.24-11+deb9u1 ii libdevmapper1.02.1 2:1.02.137-2 ii librados210.2.5-7.2 ii libreadline7 7.0-3 ii libsystemd0 232-25 ii libudev1 232-25 ii liburcu4 0.9.3-1 ii lsb-base 9.20161125 ii sg3-utils-udev 1.42-2 ii udev 232-25 multipath-tools recommends no packages. Versions of packages multipath-tools suggests: pn multipath-tools-boot -- no debconf information
Bug#866101: multipath-tools: build dependency on liburcu-dev and others are missing
Package: multipath-tools Version: 0.6.4-5 Severity: serious Justification: fails to build from source (but built successfully in the past) Dear Maintainer, `apt-source multipath-tools` installs a bunch of packages. But a subsequent `make` in the source directory fails, because urcu.h is mssing. Same for libdevmapper.h from libdevmapper-dev Same for libaio.h from libaio-dev readline/readline.h from mlibreadline-dev Please add these packages to the build dependencies -- Package-specific info: /etc/multipath.conf does not exist. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.11.1 (SMP w/4 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 multipath-tools depends on: ii init-system-helpers 1.48 ii kpartx 0.6.4-5 ii libaio1 0.3.110-3 ii libc62.24-11+deb9u1 ii libdevmapper1.02.1 2:1.02.137-2 ii librados210.2.5-7.2 ii libreadline7 7.0-3 ii libsystemd0 232-25 ii libudev1 232-25 ii liburcu4 0.9.3-1 ii lsb-base 9.20161125 ii sg3-utils-udev 1.42-2 ii udev 232-25 multipath-tools recommends no packages. Versions of packages multipath-tools suggests: pn multipath-tools-boot -- no debconf information
Bug#453309: logtail ignores the -o (offset file) option
Hello, Marc Haber <[EMAIL PROTECTED]> (Di 05 Feb 2008 22:55:16 CET): > On Tue, Feb 05, 2008 at 12:26:22PM +0100, Heiko Schlittermann wrote: > > Marc Haber <[EMAIL PROTECTED]> (Di 05 Feb 2008 11:46:15 CET): > > > On Wed, Nov 28, 2007 at 04:05:53PM +0100, Heiko Schlittermann wrote: > > > > The logtail utility fails in using some alternative offset file ... > > > .. as documented. I think last time I supposed it should work that way > > too: > > > > logtail -o # doesn't work (doesn't fit > > to manpage) > > That does not look like a bug to me then. Is the error message helpful? There was no error message. It just works as w/o "-o ". This I'd consider a bug at least. > > logtail# works (but doesn't fit to > > manpage) > > # but of course, no > > # alternative offset file > > That might be a historically sourced backwards compatibility, which is > not documented on purpose. > > I do not see a bug in the package, the documented call works fine. > Whether the documentation needs to be changed would be Martin's last > call, he will comment in due time. True, not the "binary" is buggy but the docs. But for this reason I still insist on seeing abug in logtail*deb ;) And - enhancing both - the docs and the "binary" shouldn't harm too much. And (at least from my POV) it gives more consistent behaviour of the logtail tool. -- Heiko signature.asc Description: Digital signature
Bug#453309: logtail ignores the -o (offset file) option
Marc Haber <[EMAIL PROTECTED]> (Di 05 Feb 2008 11:46:15 CET):
> On Wed, Nov 28, 2007 at 04:05:53PM +0100, Heiko Schlittermann wrote:
> > The logtail utility fails in using some alternative offset file
> > (passed via the '-o' option).
>
> Please give an example how to reproduce the issue.
Hm. I can't. It seems to work:
logtail -f -o # works (according man page)
.. as documented. I think last time I supposed it should work that way
too:
logtail -o # doesn't work (doesn't fit
to manpage)
logtail# works (but doesn't fit to manpage)
# but of course, no
# alternative offset file
So there is some inconsistency between the tool and the manpage.
Since I believe the last invocation is naturally, the last but one
should work too, shouldn't it? The first invocation is the only valid
(at least according to the man page)
And according to the source following works too:
logtail
I'll attach 2 diffs, both seem(!) to work for me. But I didn't touch the
man page so far.
Best regards from Dresden
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---- internet & unix support -
Heiko Schlittermann HS12-RIPE -
gnupg encrypted messages are welcome - key ID: 48D0359B ---
gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B -
32,42c32,34
< # try to detect plain logtail invocation without switches
< if (!$opts{f} && $#ARGV != 0 && $#ARGV != 1) {
<print STDERR "No logfile to read. Use -f [LOGFILE].\n";
<exit 66;
< } elsif ($#ARGV == 0) {
<$logfile = $ARGV[0];
< } elsif ($#ARGV == 1) {
<($logfile, $offsetfile) = ($ARGV[0], $ARGV[1]);
< } else {
<($logfile, $offsetfile) = ($opts{f}, $opts{o});
< }
---
> ($logfile, $offsetfile) = @ARGV;
> $logfile = $opts{f} if defined $opts{f};
> $offsetfile = $opts{o} if defined $opts{o};
40,41d39
< } else {
<($logfile, $offsetfile) = ($opts{f}, $opts{o});
42a41,42
> $logfile = $opts{f} if defined $opts{f};
> $offsetfile = $opts{o} if defined $opts{o};
signature.asc
Description: Digital signature
Bug#453309: logtail ignores the -o (offset file) option
Package: logtail Version: 1.2.54 Severity: grave Justification: causes non-serious data loss The logtail utility fails in using some alternative offset file (passed via the '-o' option). Please contact me if you want me to send a fix for this issue. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (550, 'stable'), (500, 'proposed-updates'), (200, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages logtail depends on: ii perl5.8.8-7etch1 Larry Wall's Practical Extraction logtail recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361956: nagios2-common: postinstall script uses unconditional chmod/chown, breaking any dpkg-statoverride
Marc Haber <[EMAIL PROTECTED]> (Mi 03 Mai 2006 08:19:23 CEST):
> tags #361956 - patch
> tags #361956 confirmed pending
> thanks
>
> On Tue, Apr 11, 2006 at 02:35:09PM +0200, Heiko Schlittermann wrote:
> > As stated in the subject -- the postinstall uses unconditionally
> > chmod/chown. If the local admin tries to change permissions using
> > dpkg-statoverride, these local changes are not respected.
>
> Thanks for spotting this. I have committed the attached patch to svn.
Thanks.
So somebody decided that it's a good idea to use dpkg-statoverride in
pre/post install scripts? Because I remember that you told me it
should/will be discussed.
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de -------- internet & unix support -
Heiko Schlittermann HS12-RIPE -
gnupg encrypted messages are welcome - key ID: 48D0359B ---
gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B -
signature.asc
Description: Digital signature
Bug#361956: [Pkg-nagios-devel] Bug#361956: nagios2-common: postinstall script uses unconditional chmod/chown, breaking any dpkg-statoverride
Marc Haber <[EMAIL PROTECTED]> (Di 11 Apr 2006 16:16:53 CEST):
> On Tue, Apr 11, 2006 at 02:35:09PM +0200, Heiko Schlittermann wrote:
> > As stated in the subject -- the postinstall uses unconditionally
> > chmod/chown. If the local admin tries to change permissions using
> > dpkg-statoverride, these local changes are not respected.
> > +# useful functions
> > +setperm() {
> > +local user="$1"; shift
> > +local group="$1"; shift
> > +local mode="$1"; shift
> > +local file="$1"; shift
> > +dpkg-statoverride --list "$file" >/dev/null && return 0
> > +dpkg-statoverride --update --add "$user" "$group" "$mode" "$file"
> > +}
>
> The maintainer script adding the statoverride does not seem to be
> policy compliant to me. We are not to touch the dpkg-statoverride
> database.
What about the policy manual 10.9.1?
Given the above, dpkg-statoverride is essentially a tool for system
administrators and would not normally be needed in the maintainer scripts.
There is one type of situation, though, where calls to dpkg-statoverride
would
be needed in the maintainer scripts, and that involves packages which use
dynamically allocated user or group ids. In such a situation, something like
the following idiom can be very helpful in the package's postinst, where
sysuser is a dynamically allocated id:
Of course, both (not touching the statoverride data base - and - using
statoverride for fixing the permissions) have their pro & con.
Pro using statoverride:
o it's clean interface
o admin is able to see all permissions different from
root:root 0755/0644
o easy way to recover lost permissions of packaged files
Contra:
o probably huge data base of statoverrides
o more steps for admin to change the permissions of
statoverridden files (as statoverride only changes
the permissions during '--add', and the files are added
already during package installation)
(May be a new version of statoverride could solve it:
dpkg-statoverride --update --list )
Best regards from Dresden
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann HS12-RIPE -
gnupg encrypted messages are welcome - key ID: 48D0359B ---
gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B -
signature.asc
Description: Digital signature
Bug#361956: nagios2-common: postinstall script uses unconditional chmod/chown, breaking any dpkg-statoverride
Package: nagios2-common
Version: 2.1-1
Severity: serious
Tags: patch
Justification: Policy 10.9.1
As stated in the subject -- the postinstall uses unconditionally
chmod/chown. If the local admin tries to change permissions using
dpkg-statoverride, these local changes are not respected.
-- System Information:
Debian Release: testing/unstable
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.jumper
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
diff -ruN nagios2-2.1/debian/lintian/overrides/nagios2-common
nagios2-2.hs/debian/lintian/overrides/nagios2-common
--- nagios2-2.1/debian/lintian/overrides/nagios2-common 2006-04-11
14:15:11.0 +0200
+++ nagios2-2.hs/debian/lintian/overrides/nagios2-common1970-01-01
01:00:00.0 +0100
@@ -1 +0,0 @@
-non-standard-file-perm etc/nagios2/resource.cfg 0600 != 0644
diff -ruN nagios2-2.1/debian/nagios2-common.install
nagios2-2.hs/debian/nagios2-common.install
--- nagios2-2.1/debian/nagios2-common.install 2006-04-11 14:15:11.0
+0200
+++ nagios2-2.hs/debian/nagios2-common.install 2006-04-11 14:09:30.0
+0200
@@ -5,6 +5,5 @@
sample-config/template-object/README
/usr/share/doc/nagios2-common/examples/template-object
sample-config/template-object/*.cfg
/usr/share/doc/nagios2-common/examples/template-object
debian/httpd.webapps-common /usr/share/nagios2/debian
-debian/lintian/overrides/nagios2-common usr/share/lintian/overrides
debian/gateway.cfg usr/share/nagios2/debian
debian/extcommands.cfg usr/share/nagios2/debian
diff -ruN nagios2-2.1/debian/nagios2-common.postinst
nagios2-2.hs/debian/nagios2-common.postinst
--- nagios2-2.1/debian/nagios2-common.postinst 2006-04-11 14:15:11.0
+0200
+++ nagios2-2.hs/debian/nagios2-common.postinst 2006-04-11 11:48:57.0
+0200
@@ -20,6 +20,16 @@
# location of the default htpasswd authentication file.
htpw=$en/htpasswd.users
+# useful functions
+setperm() {
+local user="$1"; shift
+local group="$1"; shift
+local mode="$1"; shift
+local file="$1"; shift
+dpkg-statoverride --list "$file" >/dev/null && return 0
+dpkg-statoverride --update --add "$user" "$group" "$mode" "$file"
+}
+
case "$1" in
configure)
if ! getent passwd nagios > /dev/null ; then
@@ -76,14 +86,15 @@
# explicitly set permissions on some files that are dependent
# on the uid/gid of the nagios user, which is dynamically created.
- chown root:nagios $en/resource.cfg
- chmod 640 $en/resource.cfg
-install -d -onagios -gadm -m2751 /var/log/nagios2
-install -d -onagios -gnagios -m750 /var/run/nagios2
-install -d -onagios -gnagios -m750 /var/lib/nagios2
- # chown instead of install to preserve permission bits
- chown nagios /var/lib/nagios2/rw
-install -d -onagios -gwww-data -m2750 /var/cache/nagios2
+ # .hs
+ # Do not forget to remove these statoverrides when purging the
+ # package!
+ setperm root nagios 0640 $en/resource.cfg
+ setperm nagios adm 2751 /var/log/nagios2
+ setperm nagios nagios 0750 /var/run/nagios2
+ setperm nagios nagios 0750 /var/lib/nagios2
+ setperm nagios www-data 02750 /var/cache/nagios2
+ setperm nagios www-data 0700 /var/lib/nagios2/rw
# everything went well, so now let's reset the password
db_set nagios2/adminpassword ""
diff -ruN nagios2-2.1/debian/nagios2-common.postrm
nagios2-2.hs/debian/nagios2-common.postrm
--- nagios2-2.1/debian/nagios2-common.postrm2006-04-11 14:15:11.0
+0200
+++ nagios2-2.hs/debian/nagios2-common.postrm 2006-04-11 11:50:02.0
+0200
@@ -13,6 +13,13 @@
ucf --purge /etc/nagios2/apache2.conf
ucf --purge /etc/nagios2/conf.d/host-gateway_nagios2.cfg
#ucf --purge /etc/nagios2/conf.d/extcommands_nagios2.cfg
+
+ dpkg-statoverride --force --remove /etc/nagios2/resource.cfg
+ dpkg-statoverride --force --remove /var/log/nagios2
+ dpkg-statoverride --force --remove /var/run/nagios2
+ dpkg-statoverride --force --remove /var/lib/nagios2
+ dpkg-statoverride --force --remove /var/cache/nagios2
+ dpkg-statoverride --force --remove /var/lib/nagios2/rw
;;
esac
diff -ruN nagios2-2.1/debian/rules nagios2-2.hs/debian/rules
--- nagios2-2.1/debian/rules2006-04-11 14:15:11.0 +0200
+++ nagios2-2.hs/debian/rules 2006-04-11 14:12:23.0 +0200
@@ -137,10 +137,9 @@
# remove empty directory
rmdir --ignore-fail-on-non-empty -p $b/nagios2/var/lib/nagios2/archives
# set up /var/cache/nagios2 for access by www-data
- chgrp www-data ${bnc}/var/cache/nagios2
- chmod g+s ${bnc}/var/cache/nagios2
- chown root:www-data ${bnc}/var/lib/nagios2/rw
- chmod 700 ${bnc}/var/lib/nagios2/rw
+ # Permissions are set in postinstall using dpkg-statoverride
+ # for following parts: /var/cache/nagios2
+ # /var/lib/nagios2/r
Bug#312512: cgiemail: sendmail not found
Package: cgiemail Version: 1.6-26 Severity: grave Justification: renders package unusable Hello, sh: line 1: sendmail not found (the above line is from my memory) If I use `strings /usr/lib/cgi-bin/cgiemail` I cannot find any location for sendmail compiled in. Probably you rely on a proper set PATH? I built cgiemail on my laptop and it seems as if now '/usr/sbin/sendmail' is included in the binary as sendmail path and the package works. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11.11.jumper Locale: LANG=C, [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages cgiemail depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
