Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Tue, Feb 27, 2024 at 08:50:48AM +, Richard Lewis wrote:
> thanks - agree logcheck should cope with a default rsyslog output. ... i
> just dont know what that default output is: does the below mean the
> subseconds are now always present?
>
> or: what regexp should logcheck use as prefix?
According to RFC 3339 everything from no subseconds to 6 subsecond
digits can be present (which is seven chars including the decimal dot).
So far (in the wild) I've seen only the two variants with no subseconds
or with 6 subsecond digits. But anything between these is possible.
I've already suggested to modify the regex for the timestamp part from
^(\w{3} [ :0-9]{11}|[0-9T:.+-]{32})
to
^(\w{3} [ :0-9]{11}|[0-9T:.+-]{25,32})
That would match the two extremes (with/without sub-seconds) but would
also cope with anything in between (which is legal according to the
RFCs). The first part would continue to match the "traditional" syslog
format. This is also in wide use today.
Thanks
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Thu, Feb 22, 2024 at 07:01:05PM +, Richard Lewis wrote:
> >
> > So I guess that logcheck should be prepared to receive both kinds of
> > timestamps, the 32-byte version and the 25-byte version (without the
> > subseconds timestamp).
>
> what is the default, and does logcheck cope with that? there's a limit to
> how much to suport out of the box - especially as rsyslog is no longer the
> default.
The current default of Debians rsyslog (after a long time where it was
the 'traditional' format) it is now RFC 3339 timestamps. This comes in
two variants, with or without the sub-seconds part. Logcheck only
supports the variant *with* sub-seconds.
By default, logcheck supports the 'traditional' format and the 32-byte
header, the pattern in most logcheck rules is
^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32})
The first alternative matched by this is something like
Feb 18 00:01:36
while the second is
2024-02-16T20:59:34.218904+01:00
The short form also produced by rsyslog is
2024-02-16T22:06:02+01:00
The third (short) form with no sub-seconds part is currently not matched
by logcheck.
You might want to simply set the match pattern to
^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{25,32})
Although rsyslog would probably never produce it, RFC 3339 allows the
sub-seconds part to be short (min 1 digit). There is no maximum in RFC
3339 but RFC 5424 prohibits more than 6 digits:
https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.3.1
For RFC 3339 see p.7 section 5.6 in
https://www.rfc-editor.org/rfc/rfc3339#section-5.6
So it makes sense to match a range of lengths.
> if you configure a logger to produce a certain format it's not unreasonable
> to also have to edit logcheck rules accordingly
I'm talking about the new Debian rsyslog package's default.
And, yes, but that would mean to edit logcheck rules for each installed
package? And the new default of the rsyslog package is the two variants
of RFC 3339. Unfortunately the default for remote logging does *not*
transmit the sub-seconds part. So you end up with two timestamp formats
in the same logfile. Which is fine according to the syslog standard in
RFC 5424.
> But a longer-term solution is perhaps to allow easier customisation of
> rules via "macros"/variables --- a proof-of-concept for this is in
> progress, but not.yet ready for testing
Nice!
Thanks
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064385: rsyslog: New default log format is different for local and remote log
On Thu, Feb 22, 2024 at 12:17:58PM +0100, Michael Biebl wrote: > > Reading through the upstream bug report, they basically agree that this is a > logcheck issue which should handle RFC 3339 timestamps more robustly. > Do you plan to raise this issue with the logcheck maintainers? > As I'm not a logcheck user, I don't plan to do that myself. Yes, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064395 Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote: > > I forgot to mention: > There is an upstream (rsyslog) bug-report at > https://github.com/rsyslog/rsyslog/issues/5332 Upstream has decided that it is not a bug and that both timestamp formats are valid RFC 3339 (I've checked, the grammar explicitly defines the sub-seconds part of the timestamp as optional). See link above. They also think, logcheck should cope with both formats. So I guess that logcheck should be prepared to receive both kinds of timestamps, the 32-byte version and the 25-byte version (without the subseconds timestamp). In the downstream bug-report of rsylogd (which I suppose will be closed soon) I've mentioned how to configure remote clients to send a timestamp *with* sub-seconds part. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064385 But there may be other clients out there (which may not be rsyslogd) which still send the traditional format and thus will be logged without a subseconds part. So logcheck should be prepared to receive both formats. Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064385: rsyslog: New default log format is different for local and remote log
Upstream has decided that it is not a bug and that the RFC 3339 timestamps can in fact freely mix timestamps with or without the sub-seconds part (I've checked, the RFC explicitly has the subseconds part defined as optional in the grammar). For people coming here to look: I've successfully modified my remote client rsyslog configuration to send *long* timestamps to the remote syslog. The default configuration seems to use RSYSLOG_TraditionalForwardFormat (I didn't find much info about which template formats are built into rsyslog and what they do, I've used 'strings' and 'grep' to find out). The RSYSLOG_ForwardFormat formats forwarded messages *with* sub-seconds part. So instead of, e.g., *.*;auth,authpriv.none@syslog:514 you specify a format: auth,authpriv.* @syslog:514;RSYSLOG_ForwardFormat which transmits the sub-seconds part to the receiving rsyslog. So I think we can close this. Thanks, Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Wed, Feb 21, 2024 at 02:24:03PM +0100, Ralf Schlatterbeck wrote: > > Local log lines include the sub-seconds part like: > 2024-02-16T22:05:52.315463+01:00 tux [...] > > while remote logs (in that case from virtual machines on the same host) do not > include the sub-seconds part: > 2024-02-16T22:06:02+01:00 tux1 [...] > > Logcheck currently deals only with the first format. This results in no > logcheck pattern matching for remote host log entries. I forgot to mention: There is an upstream (rsyslog) bug-report at https://github.com/rsyslog/rsyslog/issues/5332 And a debian bug report for rsyslog at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064385 Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
Package: logcheck Version: 1.4.2 Severity: normal Dear Maintainer, rsyslogd currently produces two different timestamp formats at the start of a log line with the default (now also Debian default) rfc3339 format. Local log lines include the sub-seconds part like: 2024-02-16T22:05:52.315463+01:00 tux [...] while remote logs (in that case from virtual machines on the same host) do not include the sub-seconds part: 2024-02-16T22:06:02+01:00 tux1 [...] Logcheck currently deals only with the first format. This results in no logcheck pattern matching for remote host log entries. Fortunately logcheck also still supports the 'traditional' format which I've reverted to. I would expect rsyslog to only use a single format, but failing that I think that logcheck should not drop support for the old 'traditional' timestamp format until the issue in rsyslogd is resolved. Logcheck *may* want to support both rfc3339 formats (the sub-seconds part *is* optional in the RFC). -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages logcheck depends on: ii adduser 3.134 ii cron [cron-daemon] 3.0pl1-162 ii lockfile-progs 0.1.19 ii logtail 1.4.2 ii mime-construct 1.12+really1.11-1 ii postfix [mail-transport-agent] 3.7.10-0+deb12u1 Versions of packages logcheck recommends: ii logcheck-database 1.4.2 Versions of packages logcheck suggests: ii rsyslog [system-log-daemon] 8.2302.0-1 -- Configuration Files: /etc/logcheck/logcheck.logfiles changed [not included] -- no debconf information
Bug#1064385: rsyslog: New default log format is different for local and remote log
Hi Michael, Thanks for the quick answers! On Wed, Feb 21, 2024 at 01:30:50PM +0100, Michael Biebl wrote: > The Debian package does not ship any patches in that regard. > It's thus best if you raise this issue directly upstream at > https://github.com/rsyslog/rsyslog/issues I've made an upstream bug-report on the issue at https://github.com/rsyslog/rsyslog/issues/5332 On Wed, Feb 21, 2024 at 01:40:21PM +0100, Michael Biebl wrote: > Am 21.02.24 um 12:09 schrieb Ralf Schlatterbeck: > > Unfortunately this causes logcheck to completely ignore all the remote logs > > because it matches on a 32-byte timestamp (and the timestamp of the remote > > machine only has 25 byte). > > This is a bug in the logcheck rules, I'd say. It should deal with timestamps > having no subseconds resolution. > > https://www.rsyslog.com/doc/configuration/properties.html > I suppose that for remote messages it uses "timereported", which typically > uses a resolution in seconds I still think that rsyslog should not mix two different timestamp formats in the same logfile with the same template configuration. And yes, maybe logcheck should recognize both formats with/without subseconds part. Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064385: rsyslog: New default log format is different for local and remote log
Package: rsyslog Version: 8.2302.0-1 Severity: important Dear Maintainer, I'm using rsyslog to log local events and remote events to the same log. For this I've enabled UDP receiving. The main machine is the host, while the other machines logging via UDP are virtual machines running on that host. The network carrying the syslog traffic is not visible outside the host machine. The version of rsyslog in Debian stable now uses the new international timestamp format by default. Unfortunately this format differs for local and remote logs. The local machine by default logs in the following format: 2024-02-16T22:05:52.315463+01:00 tux [...] while a machine logging via UDP appears like this: 2024-02-16T22:06:02+01:00 tux1 [...] Please observe that the sub-seconds part of the timestamp is not included in the remote logs. Unfortunately this causes logcheck to completely ignore all the remote logs because it matches on a 32-byte timestamp (and the timestamp of the remote machine only has 25 byte). I had to revert to the old 'traditional' log format (which was the default in previous versions of syslog shipped by Debian) with the following config line: $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat You will have to remove that line from the appended config file for reproducing the issue. Fortunately the old 'traditional' format is still supported by logcheck. Expected behavior: The timestamp format logcheck produces with the default configuration should be made the same for local and remote logs. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rsyslog depends on: ii libc6 2.36-9+deb12u4 ii libestr0 0.1.11-1 ii libfastjson4 1.2304.0-1 ii liblognorm5 2.0.6-4 ii libsystemd0 252.22-1~deb12u1 ii libuuid1 2.38.1-5+b1 ii libzstd1 1.5.4+dfsg2-5 ii zlib1g1:1.2.13.dfsg-1 Versions of packages rsyslog recommends: ii logrotate 3.21.0-1 Versions of packages rsyslog suggests: pn rsyslog-doc pn rsyslog-gssapi pn rsyslog-mongodb pn rsyslog-mysql | rsyslog-pgsql pn rsyslog-openssl | rsyslog-gnutls pn rsyslog-relp -- Configuration Files: /etc/rsyslog.conf changed: module(load="imuxsock") # provides support for local system logging module(load="imklog") # provides kernel logging support module(load="imudp") input(type="imudp" port="514") $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $WorkDirectory /var/spool/rsyslog $IncludeConfig /etc/rsyslog.d/*.conf *.*;auth,authpriv.none -/var/log/syslog auth,authpriv.* /var/log/auth.log cron.* -/var/log/cron.log kern.* -/var/log/kern.log mail.* -/var/log/mail.log user.* -/var/log/user.log -- no debconf information
Bug#1043443: libgtk-3-0: Missing print backend for lpr
Package: libgtk-3-0 Version: 3.24.37-2 Severity: important libgtk-3-0 used to ship the following print backends in debian buster and debian bullseye: libprintbackend-cloudprint.so libprintbackend-cups.so libprintbackend-file.so libprintbackend-lpr.so libprintbackend-test.so By default only cups and file were enabled. Debian bookworm only ships libprintbackend-cups.so libprintbackend-file.so probably due to the bug-report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025271 Please re-enable the other print backends in the next build. If some undesired backends are available by default, this can be configured in the file /etc/gtk-3.0/settings.ini The stanza there should look like (for previous debian defaults): [Settings] gtk-print-backends=file,cups So the correct fix for #1025271 is to leave all print backends enabled and add a debian-provided config-file with the enabled backends unless there is another way to set a default config in recent gtk. The current state of affairs makes debian bookworm unuseable for people with other print backends like lpr. This is needed, e.g., for the debian-provided lprng package. It is also needed for printers that support the lpr protocol natively. Note: I've searched if the other backends are available in another package now, this does not seem to be the case. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgtk-3-0 depends on: ii adwaita-icon-theme 43-1 ii hicolor-icon-theme 0.17-2 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-0 2.46.0-5 ii libc62.36-9+deb12u1 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libcolord2 1.4.6-2.2 ii libcups2 2.4.2-3+deb12u1 ii libepoxy01.5.10-1 ii libfontconfig1 2.14.1-4 ii libfribidi0 1.0.8-2.1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-common 3.24.37-2 ii libharfbuzz0b6.0.0+dfsg-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpangoft2-1.0-01.50.12+ds-1 ii libwayland-client0 1.21.0-1 ii libwayland-cursor0 1.21.0-1 ii libwayland-egl1 1.21.0-1 ii libx11-6 2:1.8.4-2+deb12u1 ii libxcomposite1 1:0.4.5-1 ii libxcursor1 1:1.2.1-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii libxkbcommon01.5.0-1 ii libxrandr2 2:1.5.2-2+b1 ii shared-mime-info 2.2-1 Versions of packages libgtk-3-0 recommends: ii libgtk-3-bin 3.24.37-2 ii librsvg2-common 2.54.5+dfsg-1 Versions of packages libgtk-3-0 suggests: ii gvfs 1.50.3-1 Versions of packages libgtk-3-0 is related to: pn appmenu-gtk3-module pn fcitx-frontend-gtk3 pn gcin-gtk3-immodule pn gtk-vector-screenshot pn gtk3-engines-xfce pn gtk3-im-libthai pn hime-gtk3-immodule pn ibus-gtk3 pn imhangul-gtk3 ii libcanberra-gtk3-module 0.30-10 pn libcaribou-gtk3-module pn libgtk3-nocsd0 pn maliit-inputcontext-gtk3 pn packagekit-gtk3-module pn scim-gtk-immodule pn topmenu-gtk3 pn uim-gtk3 pn uim-gtk3-immodule -- no debconf information
Bug#906077: Still present in bookworm
This bug is still present in Debian bookworm. Package python3-plotly version 5.4.1+dfsg-1 Debian *does* ship the un-minimized javascript and I was able to fix it by sudo ln -s /usr/share/python3-plotly/plotly.js /usr/lib/python3/dist-packages/plotly/package_data/plotly.min.js after creating the package_data directory. I don't care currently if the javascript is minimized or not. But Debian should really be shipping the minimized Javascript at the correct location. My use-case is exporting html from plotly and specifying that the javascript is not part of the exported html. Thanks Ralf Schlatterbeck -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1014133: asterisk: Asterisk fails to build from source
On Fri, Jul 01, 2022 at 01:14:28PM +0200, Bernhard Schmidt wrote:
> As Jonas already wrote, please use something like sbuild/cowbuilder. The
> packages for Bullseye have been built from source by the buildd, so
> generally they should work just fine.
I can confirm that the package builds with sbuild.
I was bitten by #725434 #576425 #823651 #856434
my solution was to symlink /tmp to /tmp/user/{1,1000} in the chroot (I
don't have pbuilder installed in the chroot, is probably installed
during build and later removed again).
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1014410: xnecview: No longer correctly displays antenna geometry
Package: xnecview Version: 1.37-1 Severity: normal xnecview can - Display the antenna geometry if given a .nec file as input - Display the antenna pattern and other graphs if given the output of nec2c The latter still works. The display of the antenna geometry no longer works, I'm including an example .nec file and the corresponding output as well as the expected output. This is a regression from Debian Buster. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xnecview depends on: ii libc6 2.31-13+deb11u3 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.33-2 ii libpng16-16 1.6.37-3 xnecview recommends no packages. xnecview suggests no packages. -- no debconf information CM -r 0.0291 -d 0.0424 -l 0.1712 -4 0.1174 CM FRQ: 430.00 fw: 6.85 bw: -2.58 CM FRQ: 435.00 fw: 6.62 bw: -4.50 CM FRQ: 440.00 fw: 6.35 bw: -5.41 CM SWR: 1.79 1.11 1.81 CE GA 1 17 0.0291 -90 90 0.00075 GM 0 0 0 0 0 0.1174 0 0 1 GA 2 17 0.0291 90 270 0.00075 GM 0 0 0 0 0 -0.1174 0 0 2 GW 3 19 0 0 0.0291 -0.1174 0 0.0291 0.00075 GW 4 19 0 0 -0.0291 -0.1174 0 -0.0291 0.00075 GW 5 19 0 0 0.0291 0.1174 0 0.0291 0.00075 GW 6 19 0 0 -0.0291 0.1174 0 -0.0291 0.00075 GW 7 5 0 0 0.0291 0 0 -0.0291 0.00075 GW 8 5 0 0 -0.0291 0 0 -0.0715 0.00075 GW 9 57 0.1712 0 -0.0715 0 0 -0.0715 0.00075 GW 10 57 -0.1712 0 -0.0715 0 0 -0.0715 0.00075 GM 0 0 0 270 0 0 0 0.1712 0 GE 0 EK 1 LD 5 0 0 0 3.77358e+07 0 0 EX 0 6 1 0 1 0 0 0 0 0 FR 0 21 0 0 430 0.5 RP 0 37 73 0 0 0 5 5 0 0 EN
Bug#1014133: asterisk: Asterisk fails to build from source
On Thu, Jun 30, 2022 at 08:28:19PM +0200, Jonas Smedegaard wrote: > I am not very familiar with asterisk as packaged for Bullseye - only > know that it was pretty unusually done. > > Maybe try build in a pristine build-environment. What do you mean by this? > Maybe try get directly in touch with Bernhard Schmidt who prepared the > work for Bullseye but possibly doesn't follow these bugs nowadays. I'll try! Can you give me a hint how to find his mail address? Thanks for your *very* quick answer! Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1014133: asterisk: Asterisk fails to build from source
Package: asterisk Version: 1:16.16.1~dfsg-1+deb11u1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, I'm trying to build asterisk from source (bullseye) using: dpkg-buildpackage -rfakeroot Looks like the verification of the needed pjproject sub-project fails. The last relevant lines from configure: configure:9241: checking for embedded pjproject (may have to download) configure:9243: result: configuring configure:9310: result: failed configure:9312: Unable to configure third-party/pjproject configure:9314: error: Re-run the ./configure command with 'NOISY_BUILD=yes' appended to see error details. If I re-run this, it tries to download the pjproject tarball and fails to verify the checksum. If I clean (debian/rules clean) and configure by hand it seems to be able to verify (but fails later with a different error). Let me know if I'm missing some trick here and if you need additional information. My plan (why I'm trying to re-build) is to include a simple patch to res/res_pjsip_messaging.c to allow content-types other than text/plain. But I'm failing on the unmodified Debian sources. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-15-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages asterisk depends on: ii adduser 3.118 ii asterisk-config 1:16.16.1~dfsg-1+deb11u1 ii asterisk-core-sounds-en 1.6.1-1 ii asterisk-modules 1:16.16.1~dfsg-1+deb11u1 ii libc62.31-13+deb11u3 ii libcap2 1:2.44-1 ii libcrypt11:4.4.18-4 ii libedit2 3.1-20191231-2+b1 ii libjansson4 2.13.1-1.1 ii libpopt0 1.18-2 ii libsqlite3-0 3.34.1-3 ii libssl1.11.1.1n-0+deb11u3 ii libsystemd0 247.3-7 ii liburiparser10.9.4+dfsg-1+deb11u1 ii libuuid1 2.36.1-8+deb11u1 ii libxml2 2.9.10+dfsg-6.7+deb11u2 ii libxslt1.1 1.1.34-4 ii lsb-base 11.1.0 Versions of packages asterisk recommends: ii asterisk-moh-opsound-gsm 2.03-1.1 ii asterisk-voicemail [asterisk-voicemail-storage] 1:16.16.1~dfsg-1+deb11u1 ii sox 14.4.2+git20190427-2 Versions of packages asterisk suggests: pn asterisk-dahdi ii asterisk-dev 1:16.16.1~dfsg-1+deb11u1 pn asterisk-doc pn asterisk-ooh323 pn asterisk-opus pn asterisk-vpb -- no debconf information
Bug#1000446: liblam4: Running parallel program yields "Unix errno: 14 Bad address"
Package: liblam4 Version: 7.1.4-6.1 Severity: important I'm trying to run a parallel program built with lam4-dev. The pre-flight check with recon ~/.mpi-lam-machinefile works (and reports "Woo hoo! [...]") The machinefile: opi9 cpu=4 opi2 cpu=4 opi3 cpu=4 opi4 cpu=4 opi5 cpu=4 Starting the cluster works, too: % lamboot ~/.mpi-lam-machinefile LAM 7.1.4/MPI 2 C++/ROMIO - Indiana University I'm running the program with either: mpiexec C /usr/local/bin/folded_antenna -r 28 optimize or with an explicit number of processes: mpiexec -c 2 /usr/local/bin/folded_antenna -r 28 optimize I'm getting multiple message of the form: - It seems that some error has occurred during MPI_INIT. This will cause your process to abort. These kinds of errors are usually system-related, such as running out of disk space, running out of memory, or something more serious such as data not being passed between processes properly. That is, you should not be seeing this error message; if you are, something is likely Very Wrong with your system. :-( Perhaps this Unix error message will help: Unix errno: 14 Bad address - My hope is that this is a simple usage error ... Note that the same program works fine when compiled & linked with mpich from debian. -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 5.14.12+ (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages liblam4 depends on: ii libc6 2.31-13+deb11u2 ii libgcc-s1 10.2.1-6 ii libltdl72.4.6-15 ii libstdc++6 10.2.1-6 Versions of packages liblam4 recommends: ii lam-runtime 7.1.4-6.1 liblam4 suggests no packages. -- no debconf information -- Ralf Schlatterbeck email: r...@zoo.priv.at
Bug#996901: ifupdown: When booting a thin client over the network (NFS-Root) ifup fails
I've finally found it. I was at the point where I had two (different hardware) embedded systems. Both with the *same* kernel and mounting the *same* root NFS filesystem. Even exchanging the IP-Addresses didn't change the behaviour, the Orange-Pi issues a DHCPDECLINE, the other system works fine. The cause is that on the non-working system the root NFS was mounted read-only. Note that I mount a (writeable) tmpfs on /var/lib/dhcp where apparently dhclient puts its leases. So there is another undocumented location that apparently needs to be writeable. It would be *very* nice to document which directories dhclient needs to be writeable and under what circumstances it issues a DHCPDECLINE. Note that the DHCPDECLINE has an optional message where the client could tell the server the reason for the decline. It's left empty, I've checked with tcpdump. For the record: The message "RTNETLINK answers: File exists" was a red herring: It is always issued, also in the successful case. I think we can close this issue unless you want to keep it open as a reminder that the causes for DHCPDECLINE should be documented. Oh and dhclient probably should not retry when it detects that something is unwriteable and effectively perform a denial-of-service attack on the dhcp server. Instead it should terminate with an error message that is clearly visible (not just in a log that may not exist at that stage of booting). Working example: root@sun7i:~# mount -oremount,rw 10.23.5.5:/data/project/project/rootfs/A20-OLinuXino_MICRO root@sun7i:~# ifup eth0 Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0/02:42:b3:f0:2d:3e Sending on LPF/eth0/02:42:b3:f0:2d:3e Sending on Socket/fallback Created duid "\000\001\000\001#\367\373\266\002B\263\360->". DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 DHCPOFFER of 10.23.5.173 from 10.23.5.254 DHCPREQUEST for 10.23.5.173 on eth0 to 255.255.255.255 port 67 DHCPACK of 10.23.5.173 from 10.23.5.254 RTNETLINK answers: File exists bound to 10.23.5.173 -- renewal in 1396 seconds. root@sun7i:~# Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#996901: ifupdown: When booting a thin client over the network (NFS-Root) ifup fails
I wrote: > I'll try to boot the system with debian buster but with the same new > kernel and report back. Followup: I've tested this with a debian buster root filesystem with the same new 5.14.12 kernel: The behaviour is identical to the one with bullseye. So at this time I believe that this is not a regression in the debian ifupdown mechanisms. Can we leave this open for some time until I've verified what the problem is? I currently see two possibilities: - I've done something differently for my other root-NFS setups - There is a difference in newer kernels that causes this The message "RTNETLINK answers: File exists" typically occurs if there already is a route that some program is trying to set up. I've verified that it is not the default route: If I remove the default route and *then* try ifup I'm still getting the same behaviour: root@sun7i:~# ip route ls default via 10.23.5.254 dev eth0 10.23.5.0/24 dev eth0 proto kernel scope link src 10.23.5.173 root@sun7i:~# ip route del default root@sun7i:~# ip route ls 10.23.5.0/24 dev eth0 proto kernel scope link src 10.23.5.173 root@sun7i:~# ifup eth0 Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0/02:42:b3:f0:2d:3e Sending on LPF/eth0/02:42:b3:f0:2d:3e Sending on Socket/fallback Created duid "\000\001\000\001#\367\373\240\002B\263\360->". DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 DHCPOFFER of 10.23.5.173 from 10.23.5.254 DHCPREQUEST for 10.23.5.173 on eth0 to 255.255.255.255 port 67 DHCPACK of 10.23.5.173 from 10.23.5.254 RTNETLINK answers: File exists DHCPDECLINE of 10.23.5.173 on eth0 to 255.255.255.255 port 67 [...] Of course I cannot remove the kernel link-scope route to the local network with NFS-root. So I couldn't check if that route causes the RTNETLINK message. All the experiments in this email were with a debian buster rootfs, they're identical to the behaviour with bullseye. Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#996901: ifupdown: When booting a thin client over the network (NFS-Root) ifup fails
Hey Santiago, thanks for the quick reaction! On Wed, Oct 20, 2021 at 05:32:53PM +0200, Santiago Ruano Rincón wrote: > > El 20/10/21 a las 15:31, Ralf Schlatterbeck escribió: > > > > I'm trying to network-boot a thin client (orange-pi zero) with debian > > bullseye and a custom kernel. NFS mount works fine but ifup fails > > spectacularly. This works fine on debian buster (but may be kernel > > specific, the debian buster setup has an older 5.9 kernel). > > What are you network mount points? The root filesystem is on NFS. So the mount-point is basically '/'. > > Listening on LPF/eth0/02:42:b3:f0:2d:3e > > Sending on LPF/eth0/02:42:b3:f0:2d:3e > > Sending on Socket/fallback > > Created duid "\000\001\000\001)\002\266\310\002B\263\360->". > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 > > DHCPOFFER of 10.23.5.173 from 10.23.5.254 > > DHCPREQUEST for 10.23.5.173 on eth0 to 255.255.255.255 port 67 > > DHCPACK of 10.23.5.173 from 10.23.5.254 > > RTNETLINK answers: File exists > > DHCPDECLINE of 10.23.5.173 on eth0 to 255.255.255.255 port 67 > > Your dhclient is declining all of the offered IPs… > Are you sure they are available? Yes they're all available, the dhcp server would not offer them if not. I *think* this is done by the kernel: It will decline all attempts to set an IP-Address different from the one where the root-filesystem is mounted because that would kill the system. Note that the very-first IP-Address offered above is the one the system already has, in fact it is configured as a static IP for this MAC address in the DHCP server. It should accept that even though the interface is already up with that IP. So the error "RTNETLINK answers: File exists" is probably the cause of all this. It did not occur on earlier Debian version such as Buster (or it did occur and was ignored by dhclient?). It has worked for me as far back as Debian lenny. I'll try to boot the system with debian buster but with the same new kernel and report back. Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#996901: ifupdown: When booting a thin client over the network (NFS-Root) ifup fails
0.23.5.213/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 2985sec preferred_lft 2985sec inet 10.23.5.215/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 2999sec preferred_lft 2999sec inet 10.23.5.216/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 3022sec preferred_lft 3022sec inet 10.23.5.217/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 3035sec preferred_lft 3035sec inet 10.23.5.218/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 3049sec preferred_lft 3049sec inet 10.23.5.219/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 3062sec preferred_lft 3062sec inet 10.23.5.220/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 3075sec preferred_lft 3075sec inet 10.23.5.200/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 3088sec preferred_lft 3088sec inet 10.23.5.201/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 3102sec preferred_lft 3102sec inet 10.23.5.202/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 3115sec preferred_lft 3115sec inet 10.23.5.204/24 brd 10.23.5.255 scope global secondary dynamic eth0 valid_lft 3129sec preferred_lft 3129sec inet6 fe80::42:b3ff:fef0:2d3e/64 scope link valid_lft forever preferred_lft forever On first glance this looks like all dynamic IPs from my network were reserverd, but looking at the leases file from my dhcp server only one address is reserved. But it looks like these addresses were somehow retained. Note that I'm getting the same output from 'ip addr ls' when I issue that command after a boot with 'auto eth0' enabled in /etc/network/interfaces (see above). -- Package-specific info: --- /etc/network/interfaces: # interfaces(5) file used by ifup(8) and ifdown(8) # Include files from /etc/network/interfaces.d: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp --- up and down scripts installed: /etc/network/if-down.d: total 0 /etc/network/if-post-down.d: total 4 -rwxr-xr-x 1 root root 1433 Feb 4 2019 vlan /etc/network/if-pre-up.d: total 8 -rwxr-xr-x 1 root root 4224 Feb 21 2019 vlan /etc/network/if-up.d: total 4 -rwxr-xr-x 1 root root 677 Feb 4 2019 ip -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 5.14.12+ (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u2 ii lsb-base 11.1.0 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2.3 Versions of packages ifupdown suggests: pn ppp pn rdnssd -- no debconf information -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#802036: isc-dhcp-client: ipv6 with alias interface: 'no link-local IPv6 address for eth0:1'
Package: isc-dhcp-client Version: 4.3.1-6 Severity: important Tags: ipv6 Dear Maintainer, I'm using the following config in /etc/network/interfaces: auto eth0:1 iface eth0:1 inet6 dhcp accept_ra 2 The command ifup --verbose eth0:1 shows: run-parts --exit-on-error --verbose /etc/network/if-pre-up.d modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure. sysctl -q -e -w net.ipv6.conf.eth0:1.accept_ra=2 ip link set dev eth0:1 up dhclient -6 -pf /run/dhclient6.eth0:1.pid -lf /var/lib/dhcp/dhclient6.eth0:1.leases eth0:1 Failed to bring up eth0:1. dhclient logs: Oct 17 09:26:57 tux14 dhclient: no link-local IPv6 address for eth0:1 Oct 17 09:26:57 tux14 dhclient: Oct 17 09:26:57 tux14 dhclient: If you think you have received this message due to a bug rather Oct 17 09:26:57 tux14 dhclient: than a configuration issue please read the section on submitting Oct 17 09:26:57 tux14 dhclient: bugs on either our web page at www.isc.org or in the README file Oct 17 09:26:57 tux14 dhclient: before submitting a bug. These pages explain the proper Oct 17 09:26:57 tux14 dhclient: process and the information we find helpful for debugging.. Oct 17 09:26:57 tux14 dhclient: Oct 17 09:26:57 tux14 dhclient: exiting. Indeed the alias interface eth0:1 doesn't have a link local address. But the main interface eth0 of course *does* have an IPv6 link-local address. So maybe this is a bug in ifup/ifdown and the ifup logic should use eth0 instead. Note that the same configuration works fine with debian wheezy it doesn't work in current jessie. On a wheezy machine the alias interface doesn't have an IPv6 Link-local address either. And the ifup issues (almost, see below) the same commands on wheezy. So my guess is that the check for an existing link-local address is new in dhclient and breaks things. The command ifup --verbose eth0:1 on a comparable wheezy machine works: run-parts --verbose /etc/network/if-pre-up.d modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure. sysctl -q -e -w net.ipv6.conf.eth0:1.accept_ra=2 ip link set dev eth0:1 up dhclient -6 -pf /run/dhclient6.eth0:1.pid -lf /var/lib/dhcp/dhclient6.eth0:1.leases eth0:1 run-parts --verbose /etc/network/if-up.d ... ifconfig eth0 shows (I have an IPv4 configuration that works) (note that this is a KVM virtual machine, therefore the peculiar mac address): root@tux14:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 52:54:08:15:01:14 inet addr:10.33.33.14 Bcast:10.33.33.255 Mask:255.255.255.0 inet6 addr: fe80::5054:8ff:fe15:114/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5860441 errors:0 dropped:0 overruns:0 frame:0 TX packets:5609388 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:982792433 (937.2 MiB) TX bytes:1043229289 (994.9 MiB) root@tux14:~# ifconfig eth0:1 eth0:1Link encap:Ethernet HWaddr 52:54:08:15:01:14 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages isc-dhcp-client depends on: ii debianutils 4.4+b1 ii iproute2 3.16.0-2 ii isc-dhcp-common 4.3.1-6 ii libc6 2.19-18+deb8u1 ii libdns-export100 1:9.9.5.dfsg-9+deb8u3 ii libirs-export91 1:9.9.5.dfsg-9+deb8u3 ii libisc-export95 1:9.9.5.dfsg-9+deb8u3 isc-dhcp-client recommends no packages. Versions of packages isc-dhcp-client suggests: pn avahi-autoipd pn resolvconf -- no debconf information
Bug#792880: openvpn does not start
Package: openvpn Version: 2.3.4-5 Severity: important Dear Maintainer, I'm trying to start openvpn on a new install (with known good config files) and the program is never started -- I'm not getting any log entries from Openvpn so I asume systemd is never starting it. My openvpn config-file is named server.conf in /etc/openvpn. The following actions were executed in order: root@tux14:/etc/openvpn# systemctl start openvpn.service root@tux14:/etc/openvpn# ps auxwww | grep openvpn root 11768 0.0 0.5 15156 2112 pts/0S+ 18:04 0:00 grep openvpn root@tux14:/etc/openvpn# systemctl status openvpn.service ● openvpn.service - OpenVPN service Loaded: loaded (/lib/systemd/system/openvpn.service; enabled) Active: active (exited) since Sun 2015-07-19 18:04:43 CEST; 20s ago Process: 11765 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 11765 (code=exited, status=0/SUCCESS) root@tux14:/etc/openvpn# systemctl stop openvpn.service root@tux14:/etc/openvpn# systemctl status openvpn.service ● openvpn.service - OpenVPN service Loaded: loaded (/lib/systemd/system/openvpn.service; enabled) Active: inactive (dead) since Sun 2015-07-19 18:05:12 CEST; 5s ago Process: 11765 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 11765 (code=exited, status=0/SUCCESS) I'd expect that systemd starts openvpn or issues an error message. Looks like the service was never started, no logs from openvpn in syslog. The config-file is named server.conf in /etc/openvpn. Same when I start via /etc/init.d script: root@tux14:~# /etc/init.d/openvpn start [ ok ] Starting openvpn (via systemctl): openvpn.service. root@tux14:~# ps auxwww | grep openvpn root 11893 0.0 0.5 15156 2044 pts/1S+ 18:18 0:00 grep openvpn root@tux14:~# systemctl status openvpn.service ● openvpn.service - OpenVPN service Loaded: loaded (/lib/systemd/system/openvpn.service; enabled) Active: active (exited) since Sun 2015-07-19 18:17:56 CEST; 1min 17s ago Process: 11873 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 11873 (code=exited, status=0/SUCCESS) And the old method of starting a *specific* OpenVPN instance via the config-file name also doesn't work: root@tux14:~# /etc/init.d/openvpn start server [ ok ] Starting openvpn (via systemctl): openvpn.service. root@tux14:~# systemctl status openvpn.service ● openvpn.service - OpenVPN service Loaded: loaded (/lib/systemd/system/openvpn.service; enabled) Active: active (exited) since Sun 2015-07-19 18:17:56 CEST; 2min 18s ago Process: 11873 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 11873 (code=exited, status=0/SUCCESS) root@tux14:~# ps auxwww | grep openvpn root 11924 0.0 0.5 15156 2048 pts/1S+ 18:20 0:00 grep openvpn Finally: Skipping systemd and starting directly via the old method works fine: root@tux14:~# _SYSTEMCTL_SKIP_REDIRECT=1 /etc/init.d/openvpn start [ ok ] Starting virtual private network daemon: server. root@tux14:~# ps auxwww | grep openvpn nobody 11977 0.0 0.6 30660 2364 ?Ss 18:22 0:00 /usr/sbin/openvpn --writepid /run/openvpn/server.pid --daemon ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf root 11996 0.0 0.5 15156 2164 pts/1S+ 18:22 0:00 grep openvpn systemd still displays the old status: root@tux14:~# systemctl status openvpn.service ● openvpn.service - OpenVPN service Loaded: loaded (/lib/systemd/system/openvpn.service; enabled) Active: active (exited) since Sun 2015-07-19 18:17:56 CEST; 6min ago Process: 11873 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 11873 (code=exited, status=0/SUCCESS) And systemd obviously doesn't know anything about openvpn: root@tux14:~# systemctl stop openvpn root@tux14:~# ps auxwww | grep openvpn nobody 11977 0.0 0.6 30660 2364 ?Ss 18:22 0:00 /usr/sbin/openvpn --writepid /run/openvpn/server.pid --daemon ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf root 12002 0.0 0.5 15156 2144 pts/1S+ 18:25 0:00 grep openvpn -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openvpn depends on: ii debconf [debconf-2.0] 1.5.56 ii init-system-helpers1.22 ii initscripts2.88dsf-59 ii iproute2 3.16.0-2 ii libc6 2.19-18 ii liblzo2-2 2.08-1.2 ii libpam0g 1.1.8-3.1 ii libpkcs11-helper1 1.11-2 ii libssl1.0.01.0.1k-3+deb8u1 Versions of packages openvpn recommends: ii easy-rsa 2.2.2-1 Versions of packages openvpn suggests: ii openssl 1.0.1k-3+deb8u1 pn resolvconf none
Bug#737825: another hang of systemd-tty-ask-password-agent
On Wed, Feb 11, 2015 at 08:55:37AM +0100, Ralf Schlatterbeck wrote: Hmm, looking closer: Is there a process systemd supposed to run? OK, looks like it is running as init with pid 1. But it seems that it isn't really working. From syslog I get: Feb 11 09:05:54 cob systemd[1]: Looping too fast. Throttling execution a little. Feb 11 09:05:56 cob systemd[1]: Looping too fast. Throttling execution a little. Feb 11 09:05:57 cob systemd[1]: Looping too fast. Throttling execution a little. Feb 11 09:05:59 cob systemd[1]: Looping too fast. Throttling execution a little. Feb 11 09:06:01 cob systemd[1]: Looping too fast. Throttling execution a little. Feb 11 09:06:03 cob systemd[1]: Looping too fast. Throttling execution a little. Feb 11 09:06:05 cob systemd[1]: Looping too fast. Throttling execution a little. Feb 11 09:06:06 cob systemd[1]: Looping too fast. Throttling execution a little. Feb 11 09:06:08 cob systemd[1]: Looping too fast. Throttling execution a little. Feb 11 09:06:10 cob systemd[1]: Looping too fast. Throttling execution a little. ps shows me it is really consuming much cpu: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1 23.8 0.5 55636 23260 ?Ss Feb10 333:33 /sbin/init Any idea how to further debug this? Ralf -- Ralf Schlatterbeck email: r...@zoo.priv.at -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737825: another hang of systemd-tty-ask-password-agent
On Wed, Feb 11, 2015 at 11:24:02AM +0100, Michael Biebl wrote: ... Feb 11 09:06:10 cob systemd[1]: Looping too fast. Throttling execution a little. Can you provide the journalctl -alb output somewhere? No, sorry, I've since rebooted, it seems to work now. I had completed the broken upgrade (except for network manager and two packages depending on it) and rebooted. Looks like something systemd depends on broke due to the failed upgrade. I've tried to enable systemd debugging, I'll notify you if this comes up again. But I've since manually configured my network interface, looks like network-manager spoiled the upgrade by taking down the network interface during the upgrade -- bad if you upgrade remotely via ssh. So non-working systemd might have been a secondary effect of a half-upgraded system. Ralf -- Ralf Schlatterbeck email: r...@zoo.priv.at -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737825: another hang of systemd-tty-ask-password-agent
I've recently tried to upgrade a running debian testing system. It hung on upgrade of network-manager. Now if I manually start dpkg --pending --configure network manager fails to start and the process hanges. To confirm it is waiting on systemd-tty-ask-password-agent see the following output of ps auxwww --forest on the machine, note that another process is also hanging waiting for /bin/systemd-tty-ask-password-agent USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND ... root 4597 0.0 0.1 25824 5292 tty1 S17:53 0:01 \_ -bash root 9657 0.0 0.1 24124 7436 tty1 T18:50 0:00 \_ dpkg --pending --configure root 9658 0.0 0.0 4328 756 tty1 T18:50 0:00 | \_ /bin/sh /var/lib/dpkg/info/network-manager.postinst configure root 9661 0.0 0.0 4328 1456 tty1 T18:50 0:00 | \_ /bin/sh /usr/sbin/invoke-rc.d dbus force-reload root 9692 0.0 0.0 24904 2640 tty1 T18:50 0:00 | \_ systemctl reload dbus.service root 9693 0.0 0.0 13168 1532 tty1 T18:50 0:00 | \_ /bin/systemd-tty-ask-password-agent --watch root 9703 0.0 0.0 21680 2524 tty1 R+ 18:58 0:00 \_ ps auxwww --forest root 9191 0.0 0.0 4328 1332 ?S18:34 0:00 /bin/sh /usr/sbin/invoke-rc.d dbus force-reload root 9222 0.0 0.0 24904 2656 ?S18:34 0:00 \_ systemctl reload dbus.service root 9223 0.0 0.0 13168 1684 ?S18:34 0:00 \_ /bin/systemd-tty-ask-password-agent --watch Note that I'm logged in as root on the first tty. No need to ask me for a password here. Then I tried to replace /bin/systemd-tty-ask-password-agent with a link to /bin/true. But it's still hanging. Note that I killed all hanging processes before trying this. Now I get: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND ... root 4597 0.0 0.1 25824 5292 tty1 S17:53 0:02 \_ -bash root 9841 0.2 0.1 24124 7392 tty1 S19:05 0:00 \_ dpkg --pending --configure root 9842 0.0 0.0 4328 792 tty1 S19:05 0:00 | \_ /bin/sh /var/lib/dpkg/info/network-manager.postinst configure root 9845 0.0 0.0 4328 1436 tty1 S19:05 0:00 | \_ /bin/sh /usr/sbin/invoke-rc.d dbus force-reload root 9876 0.0 0.0 24904 2592 tty1 S19:05 0:00 | \_ systemctl reload dbus.service root 9877 0.0 0.0 0 0 tty1 Z19:05 0:00 | \_ [systemd-tty-ask] defunct root 9884 0.0 0.0 21680 2472 tty1 R+ 19:06 0:00 \_ ps auxwww --forest ... So it looks like reloading dbus doesn't work. Note that dbus *is* running: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND ... message+ 493 0.0 0.0 42352 3624 ?Ss 09:51 0:10 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation ... If you suggest any further tries / experiments, this machine isn't production so I can try all sort of stuff. Ralf -- Ralf Schlatterbeck email: r...@zoo.priv.at -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737825: another hang of systemd-tty-ask-password-agent
On Tue, Feb 10, 2015 at 07:56:12PM +0100, Michael Biebl wrote: Can you provide instructions how we can reproduce the problem? Ideally starting from a pristine, minimal debian jessie installation. Not really, it happened when I tried to apt-get update apt-get upgrade from a system installed about 4-6 weeks ago. The hang occurred on installation of network-manager, this never finished. Ralf -- Ralf Schlatterbeck email: r...@zoo.priv.at -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737825: another hang of systemd-tty-ask-password-agent
Hmm, looking closer: Is there a process systemd supposed to run? I don't have one on that machine: # ps auxwww | grep systemd root 147 0.0 0.1 32956 4512 ?Ss Feb10 0:47 /lib/systemd/systemd-journald root 166 0.0 0.0 41472 3636 ?Ss Feb10 0:00 /lib/systemd/systemd-udevd root 10866 0.0 0.0 19848 2416 ?Ss 08:45 0:00 /lib/systemd/systemd-logind message+ 10871 0.0 0.0 42352 3488 ?Ss 08:45 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation root 10922 0.0 0.0 13168 1532 tty1 S08:48 0:00 /bin/systemd-tty-ask-password-agent --watch root 10941 0.0 0.0 13168 1584 tty1 S08:50 0:00 /bin/systemd-tty-ask-password-agent --watch root 11186 0.0 0.0 15148 2148 tty1 S+ 08:52 0:00 grep systemd This is with some hanging processes (notable shutdown -h now and reboot are both hanging) after removing my workaround with a link to /bin/true. Ralf -- Ralf Schlatterbeck email: r...@zoo.priv.at -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684009: isc-dhcp-client: dhclient must not assume a IPv6 prefix length of 64 when setting an address
On Tue, Jan 14, 2014 at 02:11:55PM +0100, Florent Fourcot wrote:
I did not see anything new in your patches, the patch of Arne Nordmark
already includes your changes (and some others, covering more cases).
Second, the /128 of ${new_ip6_address}/128 can probably be removed. An
address without prefix is set to /128 by default.
Thanks, you're right, the other patch is more complete, I didn't notice
there already was a patch.
Do you know more than us mere mortals about ISC's plans to fix this bug?
Thanks
Ralf
--
Ralf Schlatterbeck email: r...@zoo.priv.at
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684009: isc-dhcp-client: dhclient must not assume a IPv6 prefix length of 64 when setting an address
Note that dhclient does not itself configures the interface but instead
calls the shellscript /sbin/dhclient-script to do the work. So a quick
workaround is to patch that script to use a fixed netmask of /128
(patch attached).
The real fix is to hand a fixed /128 netmask to the dhclient-script from
the daemon. This patches C-code in dhclient (patch attached).
Note that the dhcpv6 protocol doesn't have an option for a netmask. So
it is always /128 and routing is left to icmpv6 router advertisements.
That also means that the option accept_ra of the dhcp method for the
INET6 address family in /etc/network/interfaces (see interfaces(5) man
page) probably should be on by default or completely removed. In
addition maybe a fixed netmask should be configurable (see excerpts from
RFC5942 below).
Just some more facts regarding this issue:
RFC 5942 is very clear about a DHCP client inventing a prefix:
RFC5942, p.7 under Host Rules:
1. The assignment of an IPv6 address -- whether through IPv6
stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
or manual configuration -- MUST NOT implicitly cause a prefix
derived from that address to be treated as on-link and added to
the Prefix List. ...
and on p.8 under the heading Observed Incorrect Implementation Behavior:
... An address
could be acquired through the DHCPv6 identity association for non-
temporary addresses (IA_NA) option from [RFC3315] (which does not
include a prefix length), or through manual configuration (if no
prefix length is specified). The host incorrectly assumes an
invented prefix is on-link. This invented prefix typically is a /64
that was written by the developer of the operating system network
module API to any IPv6 application as a default prefix length when
a length isn't specified...
I sincerely hope this gets fixed in the next release of dhcpd. Note that
I've also filed an upstream report with issue number #35178 (before I
knew about this debian report) and I'm surprised the currently scheduled
4.3.0a1 release doesn't yet have the fix.
Ralf
--
Ralf Schlatterbeck email: r...@zoo.priv.at
--- /sbin/dhclient-script.orig 2013-05-27 23:00:32.0 +0200
+++ /sbin/dhclient-script 2014-01-10 17:08:13.0 +0100
@@ -344,9 +344,9 @@
;;
BOUND6|RENEW6|REBIND6)
-if [ ${new_ip6_address} ] [ ${new_ip6_prefixlen} ]; then
+if [ ${new_ip6_address} ]; then
# set leased IP
-ip -6 addr add ${new_ip6_address}/${new_ip6_prefixlen} \
+ip -6 addr add ${new_ip6_address}/128 \
dev ${interface} scope global
fi
--- client/dhc6.c.orig 2014-01-14 13:18:41.0 +0100
+++ client/dhc6.c 2014-01-14 13:19:06.0 +0100
@@ -3841,11 +3841,8 @@
piaddr(addr-address),
(unsigned) addr-plen);
} else {
- /* Current practice is that all subnets are /64's, but
- * some suspect this may not be permanent.
- */
client_envadd(client, prefix, ip6_prefixlen,
- %d, 64);
+ %d, 128);
client_envadd(client, prefix, ip6_address,
%s, piaddr(addr-address));
}
Bug#708674: asterisk: segfault when connecting to jabber server (security)
Package: asterisk Version: 1:1.8.13.1~dfsg-3 Severity: important Tags: patch Dear Maintainer, Bug #545272 has been closed because the fix was incorporated in 1:1.8.13.1~dfsg-2 but due to a decision by the release team as documented in /usr/share/doc/asterisk/changelog.Debian.gz the fix was reverted. The changelog says the bug would be reopened. But the bug was not re-opened as stated. I don't understand the decision of the release-team as the issue is security relevant. Someone controlling a jabber server to which asterisk connects can make asterisk segfault. I've already stated this in Message #25 of #545272. Note that many people connect to outside servers like google talk. Contrary to the title of Bug #545272 the problem also happens when the jabber server is remote. The issue occurs if asterisk receives a buddy information from an unknown buddy and the search in the local buddy database returns a NULL pointer. The bug makes asterisk dereference that pointer and crash. This can happen with both remote and local jabber servers. Please fix this issue as a security upgrade! And please don't make me code up an exploit. For reference, the patch is here: https://issues.asterisk.org/jira/secure/attachment/43441/xmpp_no_crash_with_ejabberd.patch [short sidenote: Bug #701505, the fix for which was also reverted in 1:1.8.13.1~dfsg-3 and for which the changelog mentiones that it would be re-opened is also still closed as of this writing, you may want to reopen it] Thanks. Ralf Schlatterbeck -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages asterisk depends on: ii adduser 3.113+nmu3 ii asterisk-config 1:1.8.13.1~dfsg-3 ii asterisk-core-sounds-en [asterisk-prompt-en] 1.4.22-1 ii asterisk-core-sounds-en-gsm 1.4.22-1 ii asterisk-modules 1:1.8.13.1~dfsg-3 ii libc6 2.13-38 ii libcap2 1:2.22-1.2 ii libgcc1 1:4.7.2-5 ii libssl1.0.0 1.0.1e-2 ii libstdc++64.7.2-5 ii libtinfo5 5.9-10 ii libxml2 2.8.0+dfsg1-7+nmu1 Versions of packages asterisk recommends: ii asterisk-moh-opsound-gsm 2.03-1 ii asterisk-voicemail [asterisk-voicemail-storage] 1:1.8.13.1~dfsg-3 ii sox 14.4.0-3 Versions of packages asterisk suggests: ii asterisk-dahdi 1:1.8.13.1~dfsg-3 ii asterisk-dev 1:1.8.13.1~dfsg-3 ii asterisk-doc 1:1.8.13.1~dfsg-3 pn asterisk-ooh323 none -- no debconf information -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com allmenda.com member email: r...@allmenda.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545272: This is probably security relevant
To me this issue looks like a security-bug, a denial of service attack is possible if the attacker controls (or can influence) the jabber service used by asterisk. The result is a segmentation fault of asterisk. So I guess the prio should be raised and the enclosed patch should be applied before shipping the current release. -- Ralf Schlatterbeck email: r...@zoo.priv.at -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614786: chan_mobile
I've just applied the patch mentioned earlier that sets the outgoing channel number to 0 instead of 1. With this patch, chan_mobile finally works for me. An explanation what this patch does: Newer kernels (since 1.6.7 or so, early enough for current debian kernels to include the feature) allow to bind to a local bluetooth channel by specifying 0 which makes the kernel take the first free channel. This is similar to binding to a local port number for IP-based protocols (e.g. UDP or TCP) and specifying 0 as the port number, the kernel will chose the next free port. The current asterisk version uses the hard-coded channel number 1 for the local channel of the bluetooth connection to the mobile phone. This fails when some other bluetooth application is already using that port. Apparently -- as shipped -- debian bluez already runs some other application on that port. This is definitely a bug in chan_mobile. A workaround -- as somebody else has suggested -- is to not start any bluetooth services and thus keep this port free. But this means that chan_bluetooth would not work for 90% of debian users. So *please* go ahead and apply this bug before squeeze ships, otherwise we'll have to live for a whole debian release to get a working chan_mobile. Thanks Ralf -- Ralf Schlatterbeck email: r...@zoo.priv.at -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#332988: use -T key option
I've tried using all the different algorithms, none of them work, and I've tried using -k, that doesn't help either. For me it works when I use -T key instead of -k, the manpage tells us: -k Deprecated in favor of -T KEY. -T rrtype Specifies the resource record type to use for the key. rrtype must be either DNSKEY or KEY. The default is DNSKEY when using a DNSSEC algorithm, but it can be overridden to KEY for use with SIG(0). Using any TSIG algorithm (HMAC-* or DH) forces this option to KEY. So this seems to be a usage error, no bug in dnssec-keygen (and a bug in some early dynamic dns howtos). Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com osAlliance member email: r...@osalliance.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620146: inkscape generated .eps files interact badly with psnup from psutils
Package: inkscape Version: 0.47.0-2+b1 Severity: normal Tags: squeeze When including inkscape-generated EPS files into LaTeX, then generating Postscript and then using psnup on the resulting Postscript all text after the inkscape image lands on the next page. This also seems to screw up the postscript structuring because there is now one page more. Only the last image on a page generated by psnup seems to be affected Steps to reproduce: - I'm including a test-file t.tex and cc_by_sa.svg, I hope reportbug lets me do that :-) - Issue the following series of commands: latex t.tex dvips t psnup -n 4 t.ps t-4.ps gv t-4.ps You need LaTeX and psutils installed. for the last step you can use almost any postscript interpreter. The problem indicates that the inkscape-generated postscript probably doesn't conform to some postscript guidelines. I was unable to fix the postscript by editing. My current workaround is to run the inkscape-generated postscript through Ghostscripts eps2eps -- this fixes the eps files in question. -- System Information: Debian Release: 6.0.1 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages inkscape depends on: ii libaspell150.60.6-4 GNU Aspell spell-checker runtime l ii libatk1.0-01.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libcairomm-1.0-1 1.8.4-3 C++ wrappers for Cairo (shared lib ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2.1 FreeType 2 font engine, shared lib ii libgc1c2 1:6.8-1.2 conservative garbage collector for ii libgcc11:4.4.5-8 GCC support library ii libgconf2-42.28.1-6 GNOME configuration database syste ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libglibmm-2.4-1c2a 2.24.2-1 C++ wrapper for the GLib toolkit ( ii libgnomevfs2-0 1:2.24.3-1GNOME Virtual File System (runtime ii libgomp1 4.4.5-8 GCC OpenMP (GOMP) support library ii libgsl0ldbl1.14+dfsg-1 GNU Scientific Library (GSL) -- li ii libgtk2.0-02.20.1-2 The GTK+ graphical user interface ii libgtkmm-2.4-1c2a 1:2.20.3-1C++ wrappers for GTK+ (shared libr ii libgtkspell0 2.0.16-1 a spell-checking addon for GTK's T ii liblcms1 1.18.dfsg-1.2+b3 Color management library ii libmagick++3 8:6.6.0.4-3 object-oriented C++ interface to I ii libmagickcore3 8:6.6.0.4-3 low-level image manipulation libra ii libpango1.0-0 1.28.3-1+squeeze2 Layout and rendering of internatio ii libpangomm-1.4-1 2.26.2-1 C++ Wrapper for pango (shared libr ii libpng12-0 1.2.44-1 PNG library - runtime ii libpoppler-glib4 0.12.4-1.2PDF rendering library (GLib-based ii libpoppler50.12.4-1.2PDF rendering library ii libpopt0 1.16-1lib for parsing cmdline parameters ii libsigc++-2.0-0c2a 2.2.4.2-1 type-safe Signal Framework for C++ ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libwpd8c2a 0.8.14-1 Library for handling WordPerfect d ii libwpg-0.1-1 0.1.3-1 WordPerfect graphics import/conver ii libx11-6 2:1.3.3-4 X11 client-side library ii libxml22.7.8.dfsg-2 GNOME XML library ii libxslt1.1 1.1.26-6 XSLT 1.0 processing library - runt ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages inkscape recommends: ii aspell 0.60.6-4GNU Aspell spell-checker ii imagemagick 8:6.6.0.4-3 image manipulation programs pn libwmf-bin none (no description available) pn perlmagick none (no description available) ii pstoedit 3.50-3+b1 PostScript and PDF files to editab Versions of packages inkscape suggests: ii dia-gnome 0.97.1-7 Diagram editor (GNOME version) ii libgnomevfs2-extra 1:2.24.3-1 GNOME Virtual File System (extra m pn libsvg-perl none (no description available) pn libxml-xql-perl none (no description available) ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii python-lxml 2.2.8-2 pythonic binding for
Bug#584898: iproute: tc action ipt doesn't work (again)
On Tue, Jun 08, 2010 at 11:33:20AM +0200, Andreas Henriksson wrote: Hi Ralf! I've had a quick look at the problem now... You could revert to this version for a temporary workaround: http://snapshot.debian.org/package/iproute/20100224-4/ I'll be travelling this week and won't have time until atleast next week to find the proper solution. I've gone back to debian lenny for now with iproute version 20091226-1 (this used to be in debian testing for a while, I found it in an ubuntu repository and built it using dpkg-buildpackage). This seems to be compatible with the iptables version that ships with debian lenny -- the iproute version shipping with debian lenny does *not* work with the iptables version shipping with lenny. I'm glad to test any version in testing/unstable you throw at me. Maybe we can get to the next stable release where iptables/iproute is fully working together... Thanks for the quick feedback! Ralf -- Ralf Schlatterbeck email: r...@zoo.priv.at FAX: +43/2243/26465/23 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584898: iproute: tc action ipt doesn't work (again)
Package: iproute Version: 20100519-2 Severity: important Trying to set up a tc filter with an ipt action I'm getting the following error: # tc filter add dev eth0 parent root protocol ip prio 10 u32 match u32 0 0 action ipt -j MARK --set-mark 1 /lib/xtables/libxt_MARK.so: /lib/xtables/libxt_MARK.so: undefined symbol: xt_params failed to find target MARK bad action parsing parse_action: bad value (5:ipt)! Illegal action zsh: exit 1 sudo tc filter add dev eth0 parent root protocol ip prio 10 u32 match u32 0 0 Similar problems existed earlier, see for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559022 which also includes a command that *should* work. seems the inter-package link where tc tries to link to a iptables module fails again. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages iproute depends on: ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.26-1 Berkeley v4.8 Database Libraries [ Versions of packages iproute recommends: pn libatm1 none (no description available) Versions of packages iproute suggests: pn iproute-doc none (no description available) -- 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#505404: opensc 0.11.13 should fix this
I had the same problem, that certs could not be deleted on Java based cards, a Java Card Gemalto TOP IM FIPS CY2 (Cyberflex Access 64k v2) This is fixed in the latest release of OpenSC, 0.11.13: http://www.opensc-project.org/files/opensc/opensc-0.11.13.tar.gz For details, see: http://thread.gmane.org/gmane.comp.encryption.opensc.user/3471 The bug probably also affects --update-certificate as the permissions are incorrectly computed, so the suggested workaround probably doesn't help (I haven't tried, though) So I would be glad if 0.11.13 would make it into debian squeeze! Thanks, Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting Fax: +43/2243/26465-23 Reichergasse 131www: http://www.runtux.com A-3411 Weidling email: off...@runtux.com osAlliance member email: r...@osalliance.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216102049.ga6...@runtux.com
Bug#559471: opensc: switching key sizes after pkcs15-init -E impossible with muscle card
Package: opensc Version: 0.11.4-5+lenny1 Severity: normal When initializing a card with pkcs15-init -E --create-pkcs15 --no-so-pin pkcs15-init --store-pin --auth-id 01 --label User Name pkcs15-init --generate-key rsa/2048 --auth-id 01 --split-key then again but this time with a 1024 bit key: pkcs15-init -E --create-pkcs15 --no-so-pin pkcs15-init --store-pin --auth-id 01 --label User Name pkcs15-init --generate-key rsa/1024 --auth-id 01 --split-key I'm getting the following error: [pkcs15-init] iso7816.c:102:iso7816_check_sw: Unknown SWs; SW1=9C, SW2=03 [pkcs15-init] muscle.c:557:msc_generate_keypair: returning with: Card command failed [pkcs15-init] card.c:678:sc_card_ctl: returning with: Card command failed [pkcs15-init] pkcs15-muscle.c:272:muscle_generate_key: Unable to generate key [pkcs15-init] pkcs15-muscle.c:273:muscle_generate_key: returning with: Card command failed Failed to generate key: Card command failed I'm using a Gemalto TOP IM FIPS CY2 (Cyberflex Access 64k v2) in a Gemalto USB Shell V2 (GemPC Key) (CCID compliant). I'm using the MCardApplet from the musclecard project in its latest incarnation, the one from the opensc wiki at: http://www.opensc-project.org/opensc/attachment/wiki/Cyberflex/CardEdgeII.ijc When I re-upload the applet to the card and initialize the password according to Howto at http://www.opensc-project.org/opensc/wiki/Cyberflex I can successfully generate a 1024 bit key. Looks like there is some persistent state after pkcs15-init -E that should be gone after initializing the card with pkcs15-init. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages opensc depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libltdl3 1.5.26-4 A system independent dlopen wrappe ii libopensc2 0.11.4-5+lenny1 SmartCard library with support for ii libssl0.9.80.9.8g-15+lenny5 SSL shared libraries ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime opensc recommends no packages. opensc 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#559281: Detection of java .class files is buggy (doesn't recognize them)
Package: file Version: 4.26-1 Severity: normal Tags: patch Detection of java class files doesn't work although the current config attempts it. The documentation above the pattern is right (correct location of java version information is mentioned), but checking the version number of the class file fails, the java version is at offet 4, not 2. Patch: --- zz 2009-12-03 11:19:21.0 +0100 +++ /usr/share/file/magic 2009-12-03 11:04:38.0 +0100 @@ -3174,7 +3174,7 @@ 0 beshort 0xcafe 2 beshort 0xbabe !:mime application/x-java-applet -2belong 30 compiled Java class data, +4belong 30 compiled Java class data, 6 beshort x version %d. 4 beshort x \b%d 4belong 1 Mach-O fat file with 1 architecture -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages file depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libmagic1 4.26-1File type determination library us ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime 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#527048: Info received (Bug#527048: Acknowledgement (lufthansa newsletter kills amavisd-new (segfault)))
Update: I've upgraded the system in question. On the old system I had the problematic messages on hold. On the new system the go through amavis fine -- so it seems with Debian lenny the problem is gone. Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting Fax: +43/2243/26465-23 Reichergasse 131www: http://www.runtux.com A-3411 Weidling email: off...@runtux.com osAlliance member email: r...@osalliance.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527048: lufthansa newsletter kills amavisd-new (segfault)
Package: amavisd-new Version: 1:2.4.2-6.1 Severity: normal /var/log/kern.log reports May 5 10:22:09 XX kernel: amavisd-new[10645]: segfault at 74508 ff4 rip 2b59b5f954c3 rsp 74508ff0 error 6 May 5 10:38:56 XX kernel: amavisd-new[13048]: segfault at 74508 ff4 rip 2b59b5f954c3 rsp 74508ff0 error 6 May 5 10:55:32 XX kernel: amavisd-new[13104]: segfault at 74508 ff4 rip 2b59b5f954c3 rsp 74508ff0 error 6 turns out this is only one email triggering a segfault: XX:~# cd /var/lib/amavis/tmp/ XX:/var/lib/amavis/tmp# diff -r *10645 *13048 XX:/var/lib/amavis/tmp# I've now put the offending email on hold in postfix. The email is a pre-flight information from Lufthansa newslet...@lufthansa.com I'll attach an anonymized version of the unpacked amavis files to the bug report via the web-interface. We'll probably try to upgrade a copy of this virtual machine to lenny soon and I'll report back if the problem is gone with lenny. -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages amavisd-new depends on: ii adduser3.102 Add and remove users and groups ii debconf [debconf-2.0] 1.5.11etch2 Debian configuration management sy ii file 4.17-5etch3 Determines file type using magic ii libarchive-tar-perl1.30-2Archive::Tar - manipulate tar file ii libarchive-zip-perl1.16-1Module for manipulation of ZIP arc ii libberkeleydb-perl 0.31-1use Berkeley DB 4 databases from P ii libcompress-zlib-perl 1.42-2Perl module for creation and manip ii libconvert-tnef-perl 0.17-5Perl module to read TNEF files ii libconvert-uulib-perl 1.06-1Perl interface to the uulib librar pn libdigest-md5-perl none(no description available) ii libio-stringy-perl 2.110-2 Perl5 modules for IO from scalars ii libmailtools-perl 1.74-1Manipulate email in perl programs pn libmime-base64-perlnone(no description available) ii libmime-perl 5.420-0.1 Perl5 modules for MIME-compliant m ii libnet-server-perl 0.94-1An extensible, general perl server ii libunix-syslog-perl0.100-5 Perl interface to the UNIX syslog( ii perl [libtime-hires-perl] 5.8.8-7etch6 Larry Wall's Practical Extraction ii perl-modules [libnet-perl] 5.8.8-7etch6 Core Perl modules ii postfix [mail-transport-ag 2.3.8-2+etch1 A high-performance mail transport amavisd-new recommends no packages. -- debconf information: amavisd-new/outdated_config_style_warning: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527048: Acknowledgement (lufthansa newsletter kills amavisd-new (segfault))
enclosed: .tar.gz of the problematic files in /var/lib/amavis/tmp, I've overwritten all the personal information (and hope that this can still reproduce the bug). Thanks, Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting Fax: +43/2243/26465-23 Reichergasse 131www: http://www.runtux.com A-3411 Weidling email: off...@runtux.com osAlliance member email: r...@osalliance.com amavis-20090505T105020-13104-anonymized.tar.gz Description: Binary data
Bug#521845: udev: mISDN* devices have wrong permission with new in-kernel misdn
Package: udev Version: 0.125-7 Severity: normal Tags: patch When using the new in-kernel mISDN (starting with kernel 2.6.27) a device named /dev/mISDNtimer is created. To run the new linux call router (for which prototype debian packages are available) with asterisk, the device should be group-accessible as group dialout. I'm currently using the following file to do the permission setting, but this should be folded into /etc/udev/rules.d/91-permissions.rules # cat /etc/udev/rules.d/91-isdn.rules ACTION!=add|change, GOTO=permissions_end KERNEL==mISDN*, GROUP=dialout LABEL=permissions_end -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 168 lrwxrwxrwx 1 root root19 2009-03-06 19:07 025_libgphoto2.rules - ../libgphoto2.rules lrwxrwxrwx 1 root root22 2009-02-11 11:46 025_logitechmouse.rules - ../logitechmouse.rules -rw-r--r-- 1 root root 3586 2008-09-19 03:11 50-udev.rules -rw-r--r-- 1 root root 1543 2008-09-19 03:11 60-persistent-input.rules -rw-r--r-- 1 root root 4554 2008-09-19 03:11 60-persistent-storage.rules -rw-r--r-- 1 root root 1582 2008-09-19 03:11 60-persistent-storage-tape.rules -rw-r--r-- 1 root root 523 2008-09-19 03:11 60-persistent-v4l.rules -rw-r--r-- 1 root root 991 2009-02-05 20:49 65_mdadm.vol_id.rules -rw-r--r-- 1 root root 1628 2008-11-30 10:45 70-persistent-cd.rules -rw-r--r-- 1 root root 347 2007-10-05 12:20 70-persistent-net.rules -rw-r--r-- 1 root root 452 2008-09-19 03:11 75-cd-aliases-generator.rules -rw-r--r-- 1 root root 3083 2008-09-19 03:11 75-persistent-net-generator.rules -rw-r--r-- 1 root root 2282 2008-09-19 03:11 80-drivers.rules -rw-r--r-- 1 root root82 2009-01-07 23:42 90-hal.rules -rw-r--r-- 1 root root 4247 2008-09-19 03:11 91-permissions.rules -rw-r--r-- 1 root root 593 2008-09-19 03:11 95-late.rules lrwxrwxrwx 1 root root16 2009-02-11 11:29 libmtp7.rules - ../libmtp7.rules lrwxrwxrwx 1 root root15 2007-10-05 12:26 z60_hdparm.rules - ../hdparm.rules -rw-r--r-- 1 root root 2656 2008-06-15 19:27 z60_libpisock9.rules -rw-r--r-- 1 root root 14883 2008-10-20 17:52 z60_libsane-extras.rules -rw-r--r-- 1 root root 72908 2008-12-09 23:49 z60_libsane.rules -rw-r--r-- 1 root root 6661 2007-12-02 04:06 z60_xserver-xorg-input-wacom.rules -- /sys/: /sys/block/dm-0/dev /sys/block/dm-1/dev /sys/block/dm-2/dev /sys/block/dm-3/dev /sys/block/dm-4/dev /sys/block/dm-5/dev /sys/block/dm-6/dev /sys/block/dm-7/dev /sys/block/dm-8/dev /sys/block/fd0/dev /sys/block/hda/dev /sys/block/loop0/dev /sys/block/loop1/dev /sys/block/loop2/dev /sys/block/loop3/dev /sys/block/loop4/dev /sys/block/loop5/dev /sys/block/loop6/dev /sys/block/loop7/dev /sys/block/md0/dev /sys/block/md1/dev /sys/block/md2/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/block/sda/dev /sys/block/sda/sda1/dev /sys/block/sdb/dev /sys/block/sdb/sdb1/dev /sys/block/sdb/sdb2/dev /sys/block/sdc/dev /sys/block/sdc/sdc1/dev /sys/block/sdc/sdc2/dev /sys/block/sdd/dev /sys/block/sdd/sdd1/dev /sys/block/sdd/sdd2/dev /sys/class/bsg/0:0:0:0/dev /sys/class/bsg/0:0:1:0/dev /sys/class/bsg/2:0:0:0/dev /sys/class/bsg/3:0:0:0/dev /sys/class/input/input0/event0/dev /sys/class/input/input1/event1/dev /sys/class/input/input2/event2/dev /sys/class/input/input3/event3/dev /sys/class/input/input4/event4/dev /sys/class/input/input4/mouse0/dev /sys/class/input/mice/dev /sys/class/misc/cpu_dma_latency/dev /sys/class/misc/device-mapper/dev /sys/class/misc/hpet/dev /sys/class/misc/network_latency/dev /sys/class/misc/network_throughput/dev /sys/class/misc/psaux/dev /sys/class/misc/snapshot/dev /sys/class/misc/watchdog/dev /sys/class/ppdev/parport0/dev /sys/class/printer/lp0/dev /sys/class/rtc/rtc0/dev /sys/class/sound/adsp/dev /sys/class/sound/audio1/dev /sys/class/sound/audio/dev /sys/class/sound/controlC0/dev /sys/class/sound/controlC1/dev /sys/class/sound/dsp1/dev /sys/class/sound/dsp/dev /sys/class/sound/mixer1/dev /sys/class/sound/mixer/dev /sys/class/sound/pcmC0D0c/dev /sys/class/sound/pcmC0D0p/dev /sys/class/sound/pcmC0D1c/dev /sys/class/sound/pcmC0D2c/dev /sys/class/sound/pcmC0D3c/dev /sys/class/sound/pcmC0D4p/dev /sys/class/sound/pcmC1D0p/dev /sys/class/sound/timer/dev /sys/class/usb_device/usbdev1.1/dev /sys/class/usb_device/usbdev2.1/dev /sys/class/usb_device/usbdev3.1/dev /sys/class/usb_device/usbdev4.1/dev /sys/class/usb_device/usbdev5.1/dev /sys/class/usb_device/usbdev5.2/dev /sys/class/usb_endpoint/usbdev1.1_ep00/dev /sys/class/usb_endpoint/usbdev1.1_ep81/dev /sys/class/usb_endpoint/usbdev2.1_ep00/dev /sys/class/usb_endpoint/usbdev2.1_ep81/dev /sys/class/usb_endpoint/usbdev3.1_ep00/dev /sys/class/usb_endpoint/usbdev3.1_ep81/dev /sys/class/usb_endpoint/usbdev4.1_ep00/dev
Bug#521845: udev: mISDN* devices have wrong permission with new in-kernel misdn
On Mon, Mar 30, 2009 at 03:25:12PM +0200, Marco d'Itri wrote:
Please report the output of udevadm info -a -n /dev/mISDNtimer .
dab:/usr/src# udevadm info -a -n /dev/mISDNtimer
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/class/misc/mISDNtimer':
KERNEL==mISDNtimer
SUBSYSTEM==misc
DRIVER==
This looks wrong to me. Driver is in
/lib/modules/2.6.28.5-amd64/kernel/drivers/isdn/mISDN/mISDN_{core,dsp}.ko
and
/lib/modules/2.6.28.5-amd64/kernel/drivers/isdn/hardware/mISDN/...
KERNEL==mISDN*, GROUP=dialout
Do you expect more future devices matching mISDN*?
AFAIK The old mISDN had more devices. And mISDN is work in progress
Maybe Karsten Keil can give more info here (CCd him)
Also, mixed case devices suck.
:-)
It's that way starting with kernel.org Kernel 2.6.27. Maybe you want to
file a bug-report
Ralf
--
Ralf Schlatterbeck
email: r...@zoo.priv.at FAX: +43/2243/26465/23
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511252: python-pypdf: escape-sequence '\b' in PDF strings is incorrectly parsed as 'b' instead of Backspace.
Package: python-pypdf Version: 1.10-1 Severity: important Tags: patch Tried today to verify a PDF signature. Had a hard time with DER encoded ASN1 string due to a problem when reading PDF strings. The following patch says more than a long description. --- generic.py.orig 2007-10-05 04:37:14.0 +0200 +++ generic.py 2009-01-08 21:21:32.0 +0100 @@ -295,7 +295,7 @@ elif tok == t: tok = \t elif tok == b: -tok == \b +tok = \b elif tok == f: tok = \f elif tok == (: -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (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 python-pypdf depends on: ii python-support0.8.4 automated rebuilding support for P python-pypdf recommends no packages. python-pypdf 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#452931: linux-image-2.6.18-5-686: too much memory for EXT3 inode-cache in slab
Package: linux-image-2.6.18-5-686 Version: 2.6.18.dfsg.1-13etch4 Severity: important On two very different systems (a desktop system and one running a database application) running debian kernel 2.6.18-5 I'm observing the following behaviour: System accumulates *large* amounts of slab-memory in EXT3 Inode-Cache, example-output from the command slabtop: Active / Total Objects (% used): 1559187 / 1578880 (98.8%) Active / Total Slabs (% used) : 135874 / 135878 (100.0%) Active / Total Caches (% used) : 94 / 140 (67.1%) Active / Total Size (% used) : 529040.32K / 531151.94K (99.6%) Minimum / Average / Maximum Object : 0.01K / 0.34K / 128.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 907400 905957 99%0.49K 1134258453700K ext3_inode_cache 565964 565089 99%0.13K 19516 29 78064K dentry_cache 62064 56390 90%0.05K862 72 3448K buffer_head 7756 7752 99%0.27K554 14 2216K radix_tree_node 6313 2673 42%0.06K107 59 428K size-64 As you can see, this system has accumulated more that 400MB of Slab-Memory (on a system with 1GB of memory, i.e. half of the whole memory of the system just for caching inodes!). This memory is not freed, even in an out-of-memory situation, the system rather invokes the out-of-memory-killer (OOM-Killer) before freeing this memory. The only way I can reclaim this memory is running echo 2 /proc/sys/vm/drop_caches After issuing this command, slab-usage goes back to sane values: Active / Total Objects (% used): 87942 / 117616 (74.8%) Active / Total Slabs (% used) : 3532 / 3542 (99.7%) Active / Total Caches (% used) : 96 / 140 (68.6%) Active / Total Size (% used) : 10961.59K / 13940.84K (78.6%) Minimum / Average / Maximum Object : 0.01K / 0.12K / 128.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 61632 52088 84%0.05K856 72 3424K buffer_head 8874 2227 25%0.13K306 29 1224K dentry_cache 8302 7748 93%0.27K593 14 2372K radix_tree_node 6254 2533 40%0.06K106 59 424K size-64 3780 3752 99%0.04K 45 84 180K sysfs_dir_cache 2806 2790 99%0.08K 61 46 244K vm_area_struct 2712 2647 97%0.03K 24 11396K size-32 2028892 43%0.02K 12 16948K dm_io 1696568 33%0.49K2128 848K ext3_inode_cache On the desktop-system the time until the inode-cache is using so much memory takes several days. On the database server I'm doing a nightly backup that copies 20 files -- after the copying the inode-cache is using more than 400MB of memory as in the above output of slabtop. Is this a bug present in upstream-kernels too or something seen only in debians build? Is anybody else seeing this? -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-686 Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Versions of packages linux-image-2.6.18-5-686 depends on: ii coreutils 5.97-5.3 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii initramfs-tools [linux-initra 0.85h tools for generating an initramfs ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo Versions of packages linux-image-2.6.18-5-686 recommends: pn libc6-i686none (no description available) -- debconf information: linux-image-2.6.18-5-686/postinst/create-kimage-link-2.6.18-5-686: true linux-image-2.6.18-5-686/postinst/old-system-map-link-2.6.18-5-686: true linux-image-2.6.18-5-686/preinst/elilo-initrd-2.6.18-5-686: true linux-image-2.6.18-5-686/postinst/bootloader-test-error-2.6.18-5-686: linux-image-2.6.18-5-686/postinst/depmod-error-2.6.18-5-686: false * linux-image-2.6.18-5-686/preinst/already-running-this-2.6.18-5-686: linux-image-2.6.18-5-686/preinst/bootloader-initrd-2.6.18-5-686: true linux-image-2.6.18-5-686/postinst/old-dir-initrd-link-2.6.18-5-686: true linux-image-2.6.18-5-686/postinst/old-initrd-link-2.6.18-5-686: true linux-image-2.6.18-5-686/preinst/failed-to-move-modules-2.6.18-5-686: linux-image-2.6.18-5-686/preinst/abort-install-2.6.18-5-686: linux-image-2.6.18-5-686/prerm/would-invalidate-boot-loader-2.6.18-5-686: true linux-image-2.6.18-5-686/postinst/bootloader-error-2.6.18-5-686: linux-image-2.6.18-5-686/preinst/lilo-initrd-2.6.18-5-686: true linux-image-2.6.18-5-686/preinst/overwriting-modules-2.6.18-5-686: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-5-686/postinst/depmod-error-initrd-2.6.18-5-686: false
Bug#399861: dfsbuild fails with: /path/to/Release: openFile: does not exist
On Wed, Nov 22, 2006 at 04:21:15PM -0600, John Goerzen wrote: Thanks for the report. This is a holiday weekend in the US, and I'm going to try to take a break from Debian hacking, but I'll look into it on Monday. Did you have time looking into this? I've just upgraded debian etch without a change in behaviour. I've also tried it on a different etch-system with the same results. Ralf -- Ralf Schlatterbeck email: [EMAIL PROTECTED] FAX: +43/2243/26465/23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399861: dfsbuild fails with: /path/to/Release: openFile: does not exist
Package: dfsbuild Version: 0.99.2 Severity: normal I'm running dfsbuild against a local debian-etch (and -sarge) mirror. The mirror is OK, it was used before to install a system. Note that I also tried with dlrepos = etch suite = etch and dlrepos = etch and removing all the amd64-related stuff resulting in the same error message. dfsbuild terminates with the following message: dfsbuild: /var/tmp/dfsbuild/target/var/cache/bootstrap/Release: openFile: does not exist (No such file or directory) I'm running it with the options sudo dfsbuild -v -V -a i386 -w /var/tmp/dfsbuild -c /etc/dfsbuild/dfs-rsc.cfg The config-file used is a modified version of the sample file distributed. It only modifies the mirror statements, they are: mirror = http://bee/debian and in the [repo amd64] section: mirror = http://bee/debian-amd64 These mirrors contain up-to-date debian-etch and -sarge mirrors updated nightly. On demand I can supply the whole -v -V output of dfsbuild. Note that from the debug-output it seems to store the Release file under a different name: P: Retrieving Release D: Execute wget -q -O /var/tmp/dfsbuild/target/var/cache/bootstrap/_dists_._Rel ease http://bee/debian-amd64/dists/stable/Release; D: Return code: 0 P: Parsing Release P: Retrieving Release D: Execute wget -q -O /var/tmp/dfsbuild/target/var/cache/bootstrap/_dists_._mai n_binary-amd64_Release http://bee/debian-amd64/dists/stable/main/binary-amd64/Re lease D: Return code: 0 D: Reinit suite sarge -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-p4 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages dfsbuild depends on: ii cdebootstrap 0.3.15 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii debconf [debconf-2.0] 1.5.8 Debian configuration management sy ii grub 0.97-19GRand Unified Bootloader ii libc6 2.3.6.ds1-7GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii mkisofs 5:1.0~pre5-1 Creates ISO-9660 CD-ROM filesystem ii reprepro 1.3.1-1debian package repository producer ii ucf 2.0016 Update Configuration File: preserv dfsbuild recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382004: Win32-UPX Heap Overflow is also present in clamav in stable
Comparing the exploitable code from http://www.overflow.pl/adv/clamav_upx_heap.txt to the code present in the source of libclamav1_0.84-2.sarge.9_i386.deb it seems to me that the current stable version of libclamav1 is vulnerable. Can you confirm/deny this? IMHO stable should be fixed?! I can supply a patch if needed. Ralf -- Ralf Schlatterbeck email: [EMAIL PROTECTED] FAX: +43/2243/26465/23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365819: apt-get update chokes on Bad header line
On Thu, May 04, 2006 at 01:46:10PM +0200, Goswin von Brederlow wrote: Could you use tcpdump or ethereal or similar to log the actual network traffic of apt-get? But please, only that of apt-get. On Mon, May 08, 2006 at 11:13:30AM +0200, Michael Vogt wrote: The output of: # apt-get -o Debug::Acquire::http=true update 2 apt_http.log would be usefull here (please attach it to this bugreport). I've attached a tcpdump log, 10.0.0.5 is the server 10.0.0.17 the debian etch client. The first answer from the server (200 OK to Release.gpg) looks garbled (my ethereal's dissector could not parse it). This lead me to restart apache on the server and I haven't seen the problem since. If it occurs again I'll try with the Debug options to apt-get. For now I think you can close this report, doesn't seem to be a problem in apt-get afaict. Sorry for the report, looks like wget could parse the broken header-line ok and I hadn't seen that behaviour of apache ever before. Ralf -- Ralf Schlatterbeck email: [EMAIL PROTECTED] FAX: +43/2243/26465/23 dump.try1 Description: Binary data
Bug#365819: apt-get update chokes on Bad header line
On Wed, May 03, 2006 at 12:52:37AM -0700, Steve Langasek wrote: On Wed, May 03, 2006 at 09:20:39AM +0200, Ralf Schlatterbeck wrote: apt-get update produces Bad header line messages on some files. Note that this error is not reproduceable always (and happens for different files although Release.gpg is often among them), sometimes the update runs successfully, This error certainly isn't reproducible in the general case. I can now confirm that only apt-get in etch is affected. My apt-get in sarge works perfectly. Anything I can do (e.g. build the apt package with debugging turned on) to help you diagnose this problem? Ralf -- Ralf Schlatterbeck email: [EMAIL PROTECTED] FAX: +43/2243/26465/23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365819: apt-get update chokes on Bad header line
Package: apt Version: 0.6.43.3 Severity: critical apt-get update produces Bad header line messages on some files. Note that this error is not reproduceable always (and happens for different files although Release.gpg is often among them), sometimes the update runs successfully, I've also tried apt-get -o Acquire::http::Pipeline-Depth=0 update suggested in an earlier bug-report for apt but this did not work. I'm running apache 1.3.33-6sarge1 on a debian server for my local debian mirror. Output of apt-get: gnu:~# apt-get -o Acquire::http::Pipeline-Depth=0 update Errhttp://bee etch Release.gpg Bad header line [IP: 10.0.0.5 80] Ign http://bee etch Release Errhttp://bee etch/main Packages Bad header line [IP: 10.0.0.5 80] Hit http://bee etch/non-free Packages Hit http://bee etch/contrib Packages Hit http://bee etch/main Sources Hit http://bee etch/non-free Sources Hit http://bee etch/contrib Sources Get: 1 http://security.debian.org etch/updates Release.gpg [189B] Get: 2 http://debian.inode.at etch Release.gpg [189B] Hit http://debian.inode.at etch Release Hit http://security.debian.org etch/updates Release Hit http://security.debian.org etch/updates/main Packages Hit http://debian.inode.at etch/main Packages Hit http://security.debian.org etch/updates/contrib Packages Hit http://debian.inode.at etch/non-free Packages Hit http://security.debian.org etch/updates/non-free Packages Hit http://debian.inode.at etch/contrib Packages Hit http://security.debian.org etch/updates/main Sources Hit http://security.debian.org etch/updates/contrib Sources Hit http://security.debian.org etch/updates/non-free Sources Fetched 190B in 0s (394B/s) Failed to fetch http://bee/debian/dists/etch/Release.gpg Bad header line [IP: 10.0.0.5 80] Failed to fetch http://bee/debian/dists/etch/main/binary-i386/Packages.gz Bad header line [IP: 10.0.0.5 80] Reading package lists... Done E: Some index files failed to download, they have been ignored, or old ones used instead. Corresponding Apache access.log on the server: 10.0.0.12 - - [03/May/2006:09:07:09 +0200] GET /debian/dists/etch/Release.gpg HTTP/1.1 200 189 - Debian APT-HTTP/1.3 - 10.0.0.12 - - [03/May/2006:09:07:09 +0200] GET /debian/dists/etch/Release HTTP/1.1 304 - - Debian APT-HTTP/1.3 - 10.0.0.12 - - [03/May/2006:09:07:09 +0200] GET /debian/dists/etch/main/binary-i386/Packages.gz HTTP/1.1 304 - - Debian APT-HTTP/1.3 - 10.0.0.12 - - [03/May/2006:09:07:09 +0200] GET /debian/dists/etch/non-free/binary-i386/Packages.gz HTTP/1.1 304 - - Debian APT-HTTP/1.3 - 10.0.0.12 - - [03/May/2006:09:07:09 +0200] GET /debian/dists/etch/contrib/binary-i386/Packages.gz HTTP/1.1 304 - - Debian APT-HTTP/1.3 - 10.0.0.12 - - [03/May/2006:09:07:09 +0200] GET /debian/dists/etch/main/source/Sources.gz HTTP/1.1 304 - - Debian APT-HTTP/1.3 - 10.0.0.12 - - [03/May/2006:09:07:09 +0200] GET /debian/dists/etch/non-free/source/Sources.gz HTTP/1.1 304 - - Debian APT-HTTP/1.3 - -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture i386; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Authentication ; APT::Authentication::TrustCDROM true; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::userstatus status.user; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::sourceparts sources.list.d; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::dpkg /usr/bin/dpkg; DPkg ; DPkg::Pre-Install-Pkgs ; DPkg::Pre-Install-Pkgs:: /usr/sbin/dpkg-preconfigure --apt || true; Acquire ; AcquireProxy false; -- (no /etc/apt/preferences present) -- -- /etc/apt/sources.list -- # deb http://bee/debian/ etch main deb http://bee/debian/ etch main non-free contrib deb-src http://bee/debian/ etch main non-free contrib #deb http://bee/debian-dist/security/ etch/updates main non-free contrib deb http://debian.inode.at/debian/ etch main non-free contrib deb http://security.debian.org/ etch/updates main contrib non-free deb-src http://security.debian.org/ etch/updates main contrib non-free -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Versions of packages apt depends on: ii libc6 2.3.6-7 GNU C Library: Shared libraries ii libgcc1 1:4.1.0-1+b1 GCC support library ii libstdc++6 4.1.0-1+b1 The GNU Standard C++ Library v3 Versions of packages apt recommends: pn
Bug#365819: apt-get update chokes on Bad header line
On Wed, May 03, 2006 at 12:52:37AM -0700, Steve Langasek wrote: tags 365819 moreinfo unreproducible This error certainly isn't reproducible in the general case. How much free space do you have on /var? That's the only time I've ever seen this particular error. On the server: [EMAIL PROTECTED]:(260)% df /var Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1151225248 139694388 3848984 98% / On the to-be-installed etch system: gnu:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1189682520516288 179530852 1% / tmpfs 513976 0513976 0% /dev/shm tmpfs 51397672513904 1% /dev So I guess space is not the problem. Downgrading this report, since it's certainly not true that apt is generally unusable... OK. For me it's a showstopper -- although I maybe should try with ftp on the server. Note that this hit me also during install of another box (soekris embedded hardware with serial console), after apt configuration the magic in the installer marked all apt sources as unavailable, so I was unable to complete the installation normally because neither lilo nor grub would be installed... -- Ralf Schlatterbeck email: [EMAIL PROTECTED] FAX: +43/2243/26465/23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349642: Symbol clash with /usr/X11R6/lib/modules/linux/libint10.a
Package: fglrx-driver Version: 8.19.10-1 Severity: important -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.8-11-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages fglrx-driver depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libstdc++5 1:3.3.5-13The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu ii xserver-xfree864.3.0.dfsg.1-14sarge1 the XFree86 X server -- no debconf information I'm getting a symbol clash with the following two libraries from a stock debian sarge amd64 install: /usr/X11R6/lib/modules/linux/libint10.a /usr/X11R6/lib/modules/libint10.a From gdm log: Duplicate symbol rol_long in /usr/X11R6/lib/modules/drivers/fglrx_drv.o Also defined in /usr/X11R6/lib/modules/libint10.a The symbol is the same for both libint10 libs. Disabling (moving these libs to .disabled) fixes my problem and fglrx loads ok. Thanks for your effort, this was a quite painless way of getting a driver for my X550 card. So far I've not tried to build a kernel-module, though. Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293112: on ppc x0rfbserver is linked against libxclass.so.0.6.2 but 0.8.3 is installed
Package: rfb Version: 0.6.1-8 Severity: important On the powerpc architecture x0rfbserver from the rfb package is linked against libxclass.so.0.6.2 -- this version is no longer available, when installing libxclass0, 0.8.3 is installed. Error message: [EMAIL PROTECTED]:(8)% x0rfbserver x0rfbserver: error while loading shared libraries: libxclass.so.0.6.2: cannot open shared object file: No such file or directory [EMAIL PROTECTED]:(9)% ldd =x0rfbserver libz.so.1 = /usr/lib/libz.so.1 (0x0ffcd000) libXtst.so.6 = /usr/X11R6/lib/libXtst.so.6 (0x0ffa6000) libxclass.so.0.6.2 = not found libXpm.so.4 = /usr/X11R6/lib/libXpm.so.4 (0x0ff85000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x0ff53000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x0fe5a000) libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x0fd81000) libm.so.6 = /lib/libm.so.6 (0x0fcec000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x0fcbe000) libc.so.6 = /lib/libc.so.6 (0x0fb5f000) libdl.so.2 = /lib/libdl.so.2 (0x0fb3c000) /lib/ld.so.1 = /lib/ld.so.1 (0x3000) The problem is specific to the ppc architecture, on x86 I'm not seeing the problem: [EMAIL PROTECTED]:(5)% ldd =x0rfbserver ... libxclass.so.0.8.3 = /usr/lib/libxclass.so.0.8.3 (0x4003d000) ... -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.4.27-powerpc Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 Versions of packages rfb depends on: ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii libgcc1 1:3.4.2-2 GCC support library ii libstdc++51:3.3.4-13 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-8 X Window System protocol client li ii libxclass00.8.3-1C++ GUI toolkit for X ii libxext6 4.3.0.dfsg.1-8 X Window System miscellaneous exte ii libxpm4 4.3.0.dfsg.1-8 X pixmap library ii libxtst6 4.3.0.dfsg.1-8 X Window System event recording an ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries m ii zlib1g1:1.2.2-3 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
