Bug#925957: Proper fix is now available upstream
Control: reopen -1 Hello, you have closed the bug without fixing it properly (an extra warning is not a fix for an algorithmic bug). A proper fix is available upstream now, please backport it to the Debian package, including the stable and LTS releases. The fix is https://github.com/cosmos72/fstransform/commit/1a935732abdd2ef998b8a3f172dc6d9548b49fab Thanks! -- Alexander E. Patrakov
Bug#925957: fstransform: Reproducible filesystem corruption (data loss)
Package: fstransform Version: 0.9.3-2 Severity: critical Tags: upstream Justification: causes serious data loss Dear Maintainer, approximately 1.5 years ago I have discovered a reproducible case of filesystem corruption by fstransform, and reported it upstream: https://github.com/cosmos72/fstransform/issues/13 I understand that the reproducer is with non-default options, but it may also apply with the default options to systems with huge storage and relatively small amount of RAM. This is still unfixed and reproducible in Debian Buster. I would like the package to be removed from Debian, for users' safety. Here is a copy-paste of the reproducer. I understand that the "-m" option asks fstransform to use a ridiculously low amount of RAM, but, on the other hand, the filesystem to be transformed (in this case, from ext4 to xfs) is also very small. wget https://downloads.lede-project.org/releases/17.01.2/targets/x86/64/lede-17.01.2-x86-64-rootfs-ext4.img.gz zcat lede-17.01.2-x86-64-rootfs-ext4.img.gz > lede-17.01.2-x86-64-rootfs-ext4.img losetup /dev/loop7 lede-17.01.2-x86-64-rootfs-ext4.img fstransform --opts-fsremap="-m 262144" /dev/loop7 xfs xfs_repair -n /dev/loop7 # Result: lots of corruption found -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fstransform depends on: ii libc6 2.28-8 ii libgcc1 1:8.3.0-2 ii libstdc++6 8.3.0-2 fstransform recommends no packages. fstransform suggests no packages. -- no debconf information
Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout
Stefan Fritsch : > The rng should be initialized after the seed is loaded from disk. This is false according to systemd developers. Its state is changed, but it is still not initialized, because they think that the seed might come from a gold master image. -- Alexander E. Patrakov
Bug#914897: debating the wrong thing
Ansgar Burchardt wrote: Making the feature default was discussed years ago which you are surely aware of. It's not mandatory. Unfortunately I have to disagree here. Merged /usr is already, de-facto, mandatory for everyone who installs Debian Testing using the official netinst CD. The user is not even asked the question, there is nothing on the help screens. There is simply no opt-out except pressing Alt-F2 and replacing the "debootstrap" script with a wrapper that adds --no-merged-usr to the arguments. In other words, non-merged /usr is currently achievable only by upgrading an old system, or running debootstrap directly, or running old debootstrap, or using major hacks during the install procedure. -- Alexander E. Patrakov
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Ian Jackson wrote: Obviously I disagree. I think the question is urgent. Please would you rapidly overrule the debootstrap maintainers. After we have ceased introducing new lossage we can have a proper conversation about what the plan ought to be for buster and bullseye. Well, please take into account that a version of debootstrap which defaulted to merged /usr has been in Debian Testing (and thus, if I am not mistaken, available through daily builds of the netinst CDs) since June 25 or so. Five months. No matter what we decide finally, it is necessary to support systems that were installed during that five-month period. In other words, it's already too late to "minimize" the damage by undoing the change, and there is no point in acting quickly. At least in my opinion. -- Alexander E. Patrakov
Bug#784070: Stable is still affected
Are there any plans to produce a stable update containing this fix?
Bug#784070: The same bug exists in Dracut
05.07.2015 21:43, Alexander E. Patrakov wrote: I have hit this bug in a Jessie-based virtual machine that I created in order to teach myself how to deal with MD RAID1. In order to work around it, I have replaced initramfs-tools with dracut (040+1-1). Result: the bug is still reproducible. The logic to run a degraded RAID1 array if, after some timeout, we cannot find all RAID components, is missing. Attaching the SOS report generated by the dracut-based initramfs. -- Alexander E. Patrakov + cat /lib/dracut/dracut-040-207-g7252cde dracut-040-207-g7252cde + cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=UUID=5d55878f-b13e-4061-a773-85a84ea5ea4e ro quiet + '[' -f /etc/cmdline ']' + for _i in '/etc/cmdline.d/*.conf' + '[' -f '/etc/cmdline.d/*.conf' ']' + break + cat /proc/self/mountinfo 0 0 0:1 / / rw shared:1 - rootfs rootfs rw 14 0 0:14 / /sys rw,nosuid,nodev,noexec,relatime shared:2 - sysfs sysfs rw 15 0 0:3 / /proc rw,nosuid,nodev,noexec,relatime shared:7 - proc proc rw 16 0 0:5 / /dev rw,nosuid shared:8 - devtmpfs devtmpfs rw,size=500116k,nr_inodes=125029,mode=755 17 14 0:15 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:3 - securityfs securityfs rw 18 16 0:16 / /dev/shm rw,nosuid,nodev shared:9 - tmpfs tmpfs rw 19 16 0:11 / /dev/pts rw,nosuid,noexec,relatime shared:10 - devpts devpts rw,gid=5,mode=620,ptmxmode=000 20 0 0:17 / /run rw,nosuid,nodev shared:11 - tmpfs tmpfs rw,mode=755 21 20 0:18 / /run/lock rw,nosuid,nodev,noexec,relatime shared:12 - tmpfs tmpfs rw,size=5120k 22 14 0:19 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:4 - tmpfs tmpfs ro,mode=755 23 22 0:20 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:5 - cgroup cgroup rw,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 24 14 0:21 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:6 - pstore pstore rw 25 22 0:22 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:13 - cgroup cgroup rw,cpuset 26 22 0:23 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime shared:14 - cgroup cgroup rw,cpu,cpuacct 27 22 0:24 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:15 - cgroup cgroup rw,devices 28 22 0:25 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:16 - cgroup cgroup rw,freezer 29 22 0:26 / /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime shared:17 - cgroup cgroup rw,net_cls,net_prio 30 22 0:27 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:18 - cgroup cgroup rw,blkio 31 22 0:28 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime shared:19 - cgroup cgroup rw,perf_event + cat /proc/mounts rootfs / rootfs rw 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 devtmpfs /dev devtmpfs rw,nosuid,size=500116k,nr_inodes=125029,mode=755 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0 tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 + blkid /dev/vda1: UUID="d66bdf7d-d6db-1d38-328e-f5f0f8722809" UUID_SUB="a2bfdf6b-45f1-ab7a-fa0e-548995a276e0" LABEL="debian:0" TYPE="linux_raid_member" /dev/vda2: UUID="364c1067-ee45-08dc-9b1a-8a99c30e2aea" UUID_SUB="b4652541-2053-3b71-209b-639f68ae80f6" LABEL="debian:1" TYPE="linux_raid_member" + blkid -o udev ID_FS_UUID=d66bdf7d-d6db-1d38-328e-f5f0f8722809 ID_FS_UUID_ENC=d66bdf7d-d6db-1d38-328e-f5f0f8722809 ID_FS_UUID_SUB=a2bfdf6b-45f1-ab7a-fa0e-548995a276e0 ID_FS_UUID_SUB_ENC=a2bfdf6b-45f1-ab7a-fa0e-548995a276e0 ID_FS_LABEL=debian:0 ID_FS_LABEL_ENC=debian:0 ID_FS_TYPE=linux_raid_member ID_FS_UUID=364c1067-ee45-08dc-9b1a-8a99c30e2aea ID_FS_UUID_ENC=364c1067-ee45-08dc-9b1a-8a99c30e2aea ID_FS_UUID_SUB=b4652541-2053-3b71-209b-639f68ae80f6 ID_FS_UUID_SUB_ENC=b4652541-2053-3b71-209b-639f68ae
Bug#784070: The same bug exists in Dracut
I have hit this bug in a Jessie-based virtual machine that I created in order to teach myself how to deal with MD RAID1. In order to work around it, I have replaced initramfs-tools with dracut (040+1-1). Result: the bug is still reproducible. The logic to run a degraded RAID1 array if, after some timeout, we cannot find all RAID components, is missing. -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503196: rrdtool: Plots wrong data with -A -Y options
Package: rrdtool Version: 1.3.1-4 Severity: grave Justification: causes non-serious data loss First, create a round-robin database that will hold our test data. rrdtool create testdata.rrd --start 1224453000 --step 1800 \ DS:testdata:GAUGE:28000:0:U RRA:LAST:0.5:1:1800 Then, populate it with numbers: rrdtool update testdata.rrd 1224453300:1350535 rrdtool update testdata.rrd 1224467700:1350545 rrdtool update testdata.rrd 1224482100:1350554 rrdtool update testdata.rrd 1224496500:1350560 rrdtool update testdata.rrd 1224514800:1350562 rrdtool update testdata.rrd 1224539700:1350562 rrdtool update testdata.rrd 1224557700:1350562 rrdtool update testdata.rrd 1224576000:1350562 rrdtool update testdata.rrd 1224590100:1350562 rrdtool update testdata.rrd 1224604800:1350562 rrdtool update testdata.rrd 1224622500:1350562 rrdtool update testdata.rrd 1224636900:1350562 rrdtool update testdata.rrd 1224651300:1350562 rrdtool update testdata.rrd 1224669300:1350562 rrdtool update testdata.rrd 1224683700:1350562 rrdtool update testdata.rrd 1224698100:1350562 rrdtool update testdata.rrd 1224712500:1350562 rrdtool update testdata.rrd 1224730500:1350562 rrdtool update testdata.rrd 1224744900:1350562 Let's plot it: rrdtool graph testdata.png -t testdata --start 1224453000 --end 1224757634 \ DEF:testdata=testdata.rrd:testdata:LAST 'LINE2:testdata#ff' Result (correct): http://lh4.ggpht.com/patrakov/SQBmKaXKPtI/AOc/O8iAIBxWbw4/s800/testdata.png Indeed, there is not much change. But let's suppose that we are really interested in the small change that happened over the week. Let's use the alternative autoscaling option that, according to the manual page, is designed specifically for such cases: rrdtool graph testdata-bug.png -t testdata --start 1224453000 --end 1224757634 \ -A -Y DEF:testdata=testdata.rrd:testdata:LAST 'LINE2:testdata#ff' Result (wrong): http://lh4.ggpht.com/patrakov/SQBmKohptyI/AOk/29p6b-TuuJw/s800/testdata-bug.png The buggy image says that testdata is about 35000M, while it is actually at 1.35M. Misleading plot = data loss. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) Shell: /bin/sh linked to /bin/bash Versions of packages rrdtool depends on: ii libc6 2.7-14GNU C Library: Shared libraries ii libfontconfig1 2.6.0-1 generic font configuration library ii libpixman-1-0 0.10.0-2 pixel-manipulation library for X a ii libpng12-0 1.2.27-2 PNG library - runtime ii librrd41.3.1-4 Time-series data storage and displ ii libx11-6 2:1.1.5-2 X11 client-side library ii libxcb-render-util00.2.1+git1-1 utility libraries for X C Binding ii libxcb-render0 1.1-1.1 X C Binding, render extension ii libxcb11.1-1.1 X C Binding ii libxrender11:0.9.4-2 X Rendering Extension client libra ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime rrdtool recommends no packages. Versions of packages rrdtool suggests: pn librrds-perl (no description available) -- no debconf information -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449350: No reason to keep debmirror out of testing
tags 449350 unreproducible severity 449350 normal thanks Hello Luk, you have blocked debmirror out of testing due to bug #449350. However, with a fully up-to-date Lenny install, I can't reproduce the bug (even the original testcase), and therefore it definitely doesn't make the package unusable for me. The original submitter did find a workaround, so the package isn't unusable for him, too. Thus, the bug is either not RC at all, or belongs to a different package (and the proper title is "package ZZZ version YYY breaks debmirror"). Please reconsider your decision to block the package from testing. $ /usr/bin/debmirror \ > --verbose --host=ftp.debian.org \ > --root=debian/ --method=http --progress \ > --passive --dist=sid --arch=none \ > --ignore-release-gpg --section=main \ > --pdiff=none \ > /home/mirror/sid Mirroring to /home/mirror/sid from http://ftp.debian.org/debian// Arches: Dists: sid Sections: main Including source. Passive mode on. Will clean up AFTER mirroring. Pdiff mode: none. Attempting to get lock, this might take 2 minutes before it fails. Get Release files. [0%] Getting: dists/sid/Release... ok [0%] Getting: dists/sid/Release.gpg... ok Get Packages and Sources files and other miscellany. dists/sid/main/source/Sources.gz needs fetch [ 1%] Getting: dists/sid/main/source/Sources.gz... ok dists/sid/main/source/Release needs fetch [100%] Getting: dists/sid/main/source/Release... ok Parse Packages and Sources files and add to the file list everything therein. Download all files that we need to get (16765 MiB). [ 0%] Getting: pool/main/2/2vcard/2vcard_0.5-2.diff.gz... ok [ 0%] Getting: pool/main/2/2vcard/2vcard_0.5-2.dsc... ok [ 0%] Getting: pool/main/2/2vcard/2vcard_0.5.orig.tar.gz... ok ... so it works -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages debmirror depends on: ii bzip2 1.0.4-2high-quality block-sorting file co ii libcompress-zlib-perl 2.008-1Perl module for creation and manip ii libdigest-sha1-perl 2.11-2 NIST SHA-1 message digest algorith ii liblockfile-simple-perl 0.2.5-7Simple advisory file locking ii libwww-perl 5.808-1WWW client/server library for Perl ii perl [libdigest-md5-perl] 5.8.8-12 Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.8-12 Core Perl modules ii rsync 2.6.9-6fast remote file copy program (lik Versions of packages debmirror recommends: ii ed0.7-1 The classic unix line editor ii gnupg 1.4.6-2+b1 GNU privacy guard - a free PGP rep ii patch 2.5.9-4Apply a diff file to an original -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459603: Partial fix
Jeff Johnson mentioned that some of the "Error:" lines about unknown tags can be fixed with the help of RPM macros: http://rpm5.org/community/rpm-lsb/0004.html This, however, doesn't help killing the 1147 (RPMTAG_FILECONTEXTS) tag. In any case, macros required for producing LSB-compliant RPM packages must be documented somewhere under /usr/share/doc/lsb-rpm, or, better, made the defaults for the "lsb-rpm" command. -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459603: lsb-rpm: Produces packages that are not LSB-compliant
Package: lsb-rpm
Version: 4.4.1-14.1
Severity: grave
Justification: renders package unusable
Packages created by lsb-rpm don't pass the checks that the lsbpkgchk
program (from the lsb-pkgchk3 package, or directly from LSB website,
http://ftp.freestandards.org/pub/lsb/test_suites/released-3.1.0/binary/application/lsb-pkgchk-3.1.1-1.i486.rpm)
does.
Additionally, according to some anonymous pretending to be Jeff
Johnson on the linux.org.ru site,
(http://www.linux.org.ru/jump-message.jsp?msgid=2391597&cid=2394613)
"The LSB format is not used by any version of rpm since rpm-3.0.5 and
LSB packages cannot be produced by any version of rpm currently used in
Linux."
(http://www.linux.org.ru/jump-message.jsp?msgid=2391597&cid=2394781)
"unmodified rpm-4.4.2.1 cannot produce LSB "standard" packages" (and
debian doesn't apply patches that affect the output format)
I don't know whether the comments above come actually from Jeff Johnson
and whether they are true, but the "lsbpkgchk" messages do have the
ultimate authority.
Testcase: try bulding something simple, like Bison.
First, edit the /usr/lib/rpm/rpmrc file so that the "buildarchtranslate"
statements point to i486 (as mandated by LSB) instead of i386.
Second, put bison-2.3.tar.bz2 (from GNU) to /usr/src/rpm/SOURCES/ and
create the following spec file (save as bison.spec):
- 8< -
Summary: Generates parsers
Name: bison
Version: 2.3
Release: 1
Group: Base
License: GPL
Distribution: LeafOS
Vendor: LeafOS
Packager: LeafOS
URL: http://www.gnu.org/software/bison/
Source0: http://ftp.gnu.org/gnu/bison/bison-%{version}.tar.bz2
BuildRoot: %{_tmppath}/%{name}-root
Requires: lsb = 3.1, lsb-core-ia32 >= 3.0
%description
Bison generates, from a series of rules, a program for analyzing the
structure
of text files; Bison is a replacement for Yacc (Yet Another Compiler
Compiler)
%prep
%setup -q
%build
%configure CC=lsbcc3 CXX=lsbc++3
echo '#define YYENABLE_NLS 1' >> config.h
make
%install
rm -rf $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT install
rm -f $RPM_BUILD_ROOT/usr/share/info/dir
%preun
install-info --delete %{_infodir}/bison.info.gz %{_infodir}/dir
%post
install-info %{_infodir}/bison.info.gz %{_infodir}/dir
%files
%defattr(-,root,root)
/*
%doc AUTHORS COPYING ChangeLog NEWS README THANKS TODO
%clean
rm -rf $RPM_BUILD_ROOT
- 8< -
Finally, run these commands:
lsb-rpm -bb bison.spec
lsbpkgchk /usr/src/rpm/RPMS/i486/bison-2.3-1.i486.rpm
and see the following errors:
Error: checkRpmIdx() unexpected Index tag=1140 type=4 offset=d00 count=21
Error: checkRpmIdx() unexpected Index tag=1141 type=4 offset=d84 count=21
Error: checkRpmIdx() unexpected Index tag=1142 type=8 offset=e08 count=7
Error: checkRpmIdx() unexpected Index tag=1143 type=4 offset=eec count=21
Error: checkRpmIdx() unexpected Index tag=1144 type=4 offset=f70 count=21
Error: checkRpmIdx() unexpected Index tag=1145 type=4 offset=ff4 count=1
Error: checkRpmIdx() unexpected Index tag=1147 type=8 offset=ff8 count=21
Since the only purpose of lsb-rpm is to produce LSB-compliant packages
and it fails to do this, I am reporting a grave bug.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages lsb-rpm depends on:
ii rpm 4.4.1-14.1 Red Hat package manager
lsb-rpm recommends no packages.
-- no debconf information
--
Alexander E. Patrakov
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438626: File conflict with security update
Package: ftp.debian.org Version: unavailable Severity: serious Tags: security There are two files named "file_4.17-5etch2_i386.deb" with different md5sum, one at http://ftp.debian.org/debian/pool/main/f/file/file_4.17-5etch2_i386.deb and one at http://security.debian.org/pool/updates/main/f/file/file_4.17-5etch2_i386.deb Please remove the wrong file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403706: Udev sometimes forgets to RUN a program when renaming network interface
Joey Hess wrote: Please file this as a separate bug on udev. Done, see #405775. -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403706: Udev sometimes forgets to RUN a program when renaming network interface
To Marco d'Itri: this testcase may explain at least a fraction of Debian bug
#403706 (because in Debian ifup is run, essentially, from udev rules),
that's why the CC. Udev version is 0.100-2.3. Also reproducible with 0.103-1.
To repeat the steps below, you need a Debian Etch installation CD, and
VMware Server. QEMU may be able to reproduce this too, but it is untested.
1) Create a virtual machine with two network cards. The first of them should
look into a custom empty virtual network (e.g., /dev/vmnet2 - the intention
is to simulate a useless network card looking into nowhere). The other card
should use host-only or NAT networking (the intention is that it gets its IP
address via DHCP).
2) Install Debian Etch into this virtual machine from the CD. Select eth1 as
the primary network interface. Do not update the system, because this would
trigger the update-initramfs script and break the testcase! (the testcase
relies on the fact that udev not in initramfs has to swap the two network
interfaces at step 6)
This installation procedure creates the following files:
/etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth1
iface eth1 inet dhcp
/etc/udev/rules.d/z25_persistent-net.rules:
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:29:d8:39:6e",
NAME="eth1"
# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:29:d8:39:64",
NAME="eth0"
3) Create the file /etc/udev/rules.d/z49_debug.rules with the following
contents:
SUBSYSTEM=="net", ACTION=="add", RUN+="/bin/sh -c 'echo FOUND NETWORK
INTERFACE %k >/dev/console'"
4) Reboot the system, watch how it prints that it found eth1, eth0 and lo.
So far so good. Note that the renaming rules above are not really triggered,
because these two network cards are PCI cards served by the same module.
5) Now edit /etc/network/interfaces so that it mentions eth0 instead of
eth1, and edit /etc/udev/rules.d/z25_persistent-net.rules by swapping eth0
and eth1 (so that 00:0c:29:d8:39:6e becomes eth0 and 00:0c:29:d8:39:64
becomes eth1). The intention is, as you may have guessed, is to swap the
names, so that the used card becomes eth0, and the useless one is eth1. The
consequence is that the renaming rules become essential.
6) Reboot. This time it prints the message:
udevd-event[2669]: rename_netif: error changing net interface name
eth1_rename to eth0: No such device
(but "ifconfig -a" shows that the 00:0c:29:d8:39:6e card does become eth0)
Then it prints a message that it found eth1 and lo, and no message about
eth0. And of course, the network is not up, because udev forgot to run
net.agent for the new eth0. Bug!
While it took us some special preparations to trigger this bug with two
identical network cards, I guess that this will happen by itself with 50%
probability if the network cards are not identical, due to random module
loading order.
7) This time, repeat step (5), using names "used" and "unused" for the two
interfaces, reboot and watch how udev finds the "used", "unused" and "lo"
interfaces.
--
Alexander E. Patrakov
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397032: zinf: Fails to start with X error
Package: zinf Version: 2.2.5-5.2 Severity: grave Justification: renders package unusable Every time I start zinf, it shows the filetype association dialog, and then quits. If I start it from the console, I see the following error: [EMAIL PROTECTED]:~$ zinf (:2295): Gdk-WARNING **: Attempt to draw a drawable with depth 24 to a drawable with depth 32 (:2295): Gdk-WARNING **: Attempt to draw a drawable with depth 24 to a drawable with depth 32 (:2295): Gdk-WARNING **: Attempt to draw a drawable with depth 24 to a drawable with depth 32 (:2295): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `pixmap == NULL || gdk_drawable_get_depth (window) == gdk_drawable_get_depth (pixmap)' failed The program '' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 1202 error_code 8 request_code 62 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) xorg.conf is attached. -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) (note: I removed zinf, taht's why libmusicbrainz4c2a shows as "pn") Versions of packages zinf depends on: ii libatk1.0-0 1.12.2-1The ATK accessibility toolkit ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libcairo21.2.4-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.1-2 generic font configuration library ii libgcc1 1:4.1.1-13 GCC support library ii libgdbm3 1.8.3-3 GNU dbm database routines (runtime ii libglib2.0-0 2.12.3-2The GLib library of C routines ii libgtk2.0-0 2.8.20-1The GTK+ graphical user interface ii libid3-3.8.3c2a 3.8.3-5 Library for manipulating ID3v1 and pn libmusicbrainz4c2a (no description available) ii libpango1.0-01.14.4-2Layout and rendering of internatio ii libstdc++6 4.1.1-13The GNU Standard C++ Library v3 ii libvorbis0a 1.1.2-1 The Vorbis General Audio Compressi ii libvorbisfile3 1.1.2-1 The Vorbis General Audio Compressi ii libx11-6 2:1.0.0-9 X11 client-side library ii libxcursor1 1.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-4 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-3 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii zlib1g 1:1.2.3-13 compression library - runtime zinf recommends no packages. # xorg.conf (Xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type "man xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/xorg.conf /etc/X11/xorg.conf.custom # md5sum /etc/X11/xorg.conf >/var/lib/xfree86/xorg.conf.md5sum # dpkg-reconfigure xserver-xorg Section "Files" FontPath"/usr/share/X11/fonts/misc" EndSection Section "Module" Load"dbe" Load"dri" Load"extmod" Load"freetype" Load"glx" # Load"vbe" EndSection Section "Extensions" Option "Composite" "enabled" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "acpi" Option "XkbLayout" "us,ru(winkeys)" Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll,compose:rwin" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePoint
Bug#295832: Solution to this bug
This bug is also present in previous versions of slirp if one compiles them with gcc-3.3 or gcc-3.4. The manifestation is that all TCP packets are discarded as having wrong checksum. There was already a discussion of a similar issue on qemu-devel list. Solution: add -fno-strict-aliasing to all CFLAGS, this is necessary to fix slirp-1.0.16 and previous versions. In adiition, for slirp-1.0.16 for some strange reason the mtu has to be set to value lower than 1500, but that's probably a different bug. -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
