Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Hello, On Fri, 17 Jan 2014 21:33:16 +0100 Michael Vogt m...@debian.org wrote: [...] I haven't found the root cause of the issue yet unfortunately. As a workaround you can use the -o Dpkg::Use-Pty=False option, e.g.: # apt-get -o Dpkg::Use-Pty=False dist-upgrade This issue is still valid. If we can't find a proper solution before the freeze, would it be possible to ship this workaround with Jessie for kFreeBSD-*? I can confirm that using Dpkg::Use-Pty=False in /etc/apt/apt.conf.d/99kfreebsd fixes the issue for me. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Hi, On 29/08/14 11:41, Markus Koschany wrote: This issue is still valid. If we can't find a proper solution before the freeze, would it be possible to ship this workaround with Jessie for kFreeBSD-*? I haven't seen this bug in a long time? Earlier messages in the bug log say it seems fixed. (It's just a text-formatting issue now). If you still see it, could you please tell me kernel and relevant package versions? (Best to get this from `reportbug -N 732937`, option 'x' to submit extra info). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Package: apt Version: 1.0.7 Followup-For: Bug #732937 I still get error messages like this one. ioctl(TIOCSCTTY) failed for fd: 17 It's true that dpkg does not fail completely anymore but the text formatting makes the output unnecessarily hard to read. Hence my suggestion to ship the workaround in /etc/apt/apt.conf.d/ Here are the requested extra information: Markus -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture kfreebsd-amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-image-11\.0-0-amd64$; APT::NeverAutoRemove:: ^linux-headers-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-headers-11\.0-0-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-11\.0-0-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-11\.0-0-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-10\.0-1-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-11\.0-0-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-10\.0-1-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-11\.0-0-amd64$; APT::NeverAutoRemove:: ^gnumach-image-10\.0-1-amd64$; APT::NeverAutoRemove:: ^gnumach-image-11\.0-0-amd64$; APT::NeverAutoRemove:: ^.*-modules-10\.0-1-amd64$; APT::NeverAutoRemove:: ^.*-modules-11\.0-0-amd64$; APT::NeverAutoRemove:: ^.*-kernel-10\.0-1-amd64$; APT::NeverAutoRemove:: ^.*-kernel-11\.0-0-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-11\.0-0-amd64$; APT::NeverAutoRemove:: ^linux-tools-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-tools-11\.0-0-amd64$; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Default-Release testing; APT::Architectures ; APT::Architectures:: kfreebsd-amd64; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma; APT::Compressor::lzma::Binary xz; APT::Compressor::lzma::Cost 5; APT::Compressor::lzma::CompressArg ; APT::Compressor::lzma::CompressArg:: --format=lzma; APT::Compressor::lzma::CompressArg:: -9; APT::Compressor::lzma::UncompressArg ; APT::Compressor::lzma::UncompressArg:: --format=lzma; APT::Compressor::lzma::UncompressArg:: -d; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::mirrors mirrors/; Dir::State::extended_states extended_states; 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
apt: kfreebsd: ioctl(TIOCSCTTY) fails, stair-stepped text (was: Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64)
clone 732937 -1 retitle -1 apt: kfreebsd: ioctl(TIOCSCTTY) fails, stair-stepped text severity -1 normal notfixed -1 apt/0.9.12.1 notfound -1 apt/0.9.13~exp1 notfound -1 apt/0.9.14.2 found -1 apt/1.0.7 thanks On 29/08/14 12:34, Markus Koschany wrote: I still get error messages like this one. ioctl(TIOCSCTTY) failed for fd: 17 It's true that dpkg does not fail completely anymore but the text formatting makes the output unnecessarily hard to read. Thanks! I'll track this as a separate bug since the original #732937 issue is fixed, and this one is less serious. The failing ioctl and error message are both coming from apt-get, according to ktrace: 39983 apt-get CALL ioctl(0xb,0x20007461 ,0) 37015 apt-get CALL wait4(0x9c2f,0x7fffc610,0x1WNOHANG,0) 39983 apt-get RET ioctl -1 errno 6 No such device or address 37015 apt-get RET wait4 0 37015 apt-get CALL pselect(0xd,0x7fffc6a0,0,0,0x7fffc5a0,0x62f12c) 37015 apt-get RET pselect 1 39983 apt-get CALL write(0x2,0x800972670,0x20) 37015 apt-get CALL read(0xa,0x7fffc000,0x400) 37015 apt-get GIO fd 10 read 0 bytes 39983 apt-get GIO fd 2 wrote 32 bytes ioctl(TIOCSCTTY) failed for fd: [...] 11 Output text is then stair-stepped, meaning with each newline there is no carriage return: Unpacking hello (from .../hello_2.9-1_kfreebsd-amd64.deb) ... Processing triggers for install-info ... Processing triggers for man-db ... ioctl(TIOCSCTTY) failed for fd: 11 Setting up hello (2.9-1) ... == How can you help? (doc: http://wiki.debian.org/how-can-i-help ) == Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540077f1.7040...@pyro.eu.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Source-Version: 1.0.3 This bug (causing APT to abort) was reported fixed in 1.0.3 (or perhaps even 1.0.2?). Possibly it was related to this change: apt (1.0.3) unstable; urgency=medium . * Only do openpty() if both stdin/stdout are terminals (Closes: 746434) Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540078d7.3050...@pyro.eu.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Hi Guillem (2013.12.23_08:00:00_+0200) I can reproduce it with simply running: $ apt-get install --reinstall git This appears fixed with 1.0.3. I was getting it on almost every package installation, and now, with apt 1.0.3, I could complete a 300 odd package dist-upgrade without running into the bug. dpkg output is a bit mangled, as if it's missing a CR. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140509121602.ga7...@purcell.lan
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
fredag den 9 maj 2014 klockan 14:16 skrev Stefano Rivera detta: This appears fixed with 1.0.3. I was getting it on almost every package installation, and now, with apt 1.0.3, I could complete a 300 odd package dist-upgrade without running into the bug. dpkg output is a bit mangled, as if it's missing a CR. No, the problem is that TIOCSCTTY is not automatic on FreeBSD, like it is with eglibc. The disturbing issue is this: Processing triggers for man-db (...) . ioctl(TIOCSCTTY) failed for fd: 18 Setting up ... I have not been able to figure out which component, to whom apt-get is delegating actions, would be the culprit in this matter. Regards, M E Andersson -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140509131345.ga22...@mail.gisladisker.se
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On 17/01/2014 21:33, Michael Vogt wrote: I have a kfreebsd stable install in qemu now and can reproduce the bug with my git apt tree. It looks like the pty handling in pkgDpkgPM broke and the stdout of the dpkg inside the pty is closed/unavailable too early for some reason. I see: error writing to 'standard output': No such file or directory on the dpkg status-fd when running with apt-get install 2vcard -o Debug::pkgDPkgProgressReporting=true I haven't found the root cause of the issue yet unfortunately. As a workaround you can use the -o Dpkg::Use-Pty=False option, e.g.: # apt-get -o Dpkg::Use-Pty=False dist-upgrade Thank you. pty support in glibc was recently adjusted to use the new /dev/pts interface. Perhaps this might be related? -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52daa587.9070...@debian.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On Sun, Jan 12, 2014 at 08:05:06PM +, Steven Chamberlain wrote: Control: tags -1 found apt/0.9.14.2 Indeed upgrading only libapt-pkg4.12 is enough to trigger this. [..] I bisected this and it it appears that c3045b is the one that introduced the problem. Looking closer it appears that I can not do ioctl(d-slave, TIOCSCTTY, 0) more than ones on freebsd without a new openpty() to get a new master pty (i.e. I can not use the slave fd again). I will do more digging into this issue. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140118231653.GB10489@bod
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Hello, On Thu, Jan 16, 2014 at 12:15:18PM +, Steven Chamberlain wrote: On 16/01/14 12:11, Robert Millan wrote: If you just want a sid system to debug apt, it's probably quicker to install wheezy and dist-upgrade. This bug should be reproducible in stable just by upgrading libapt-pkg4.12 and dependencies as needed. So I think Aurelien's Qemu wheezy images would be the quickest way. Thank you and Robert and Cyril for your help and suggestions. I have a kfreebsd stable install in qemu now and can reproduce the bug with my git apt tree. It looks like the pty handling in pkgDpkgPM broke and the stdout of the dpkg inside the pty is closed/unavailable too early for some reason. I see: error writing to 'standard output': No such file or directory on the dpkg status-fd when running with apt-get install 2vcard -o Debug::pkgDPkgProgressReporting=true I haven't found the root cause of the issue yet unfortunately. As a workaround you can use the -o Dpkg::Use-Pty=False option, e.g.: # apt-get -o Dpkg::Use-Pty=False dist-upgrade Cheers, Michael -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140117203316.GQ3662@bod
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Michael Vogt m...@debian.org (2014-01-16): On Sun, Jan 12, 2014 at 08:05:06PM +, Steven Chamberlain wrote: Control: tags -1 found apt/0.9.14.2 Indeed upgrading only libapt-pkg4.12 is enough to trigger this. [..] Thanks a bunch for your bugreport and sorry for my slow reply. Its likely that this is fallout from some fairly big changes in the handling of dpkg. What is the best way for me to reproduce this? I don't have a kfreebsd system right now - is installing one from a current installer image in kvm the quickest way (I assume so)? This might be slightly quicker: http://blog.aurel32.net/153 http://people.debian.org/~aurel32/qemu/ But otherwise, that's what I'd do. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On 16/01/2014 07:42, Michael Vogt wrote: What is the best way for me to reproduce this? I don't have a kfreebsd system right now - is installing one from a current installer image in kvm the quickest way (I assume so)? The development version of D-I for kfreebsd tends to break a lot more often than the linux counterpart (just recently it had one major issue caused by grub and another one by zfsutils). If you just want a sid system to debug apt, it's probably quicker to install wheezy and dist-upgrade. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d7cc62.6090...@debian.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On 16/01/14 12:11, Robert Millan wrote: If you just want a sid system to debug apt, it's probably quicker to install wheezy and dist-upgrade. This bug should be reproducible in stable just by upgrading libapt-pkg4.12 and dependencies as needed. So I think Aurelien's Qemu wheezy images would be the quickest way. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d7cd56.6080...@pyro.eu.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On Sun, Jan 12, 2014 at 08:05:06PM +, Steven Chamberlain wrote: Control: tags -1 found apt/0.9.14.2 Indeed upgrading only libapt-pkg4.12 is enough to trigger this. [..] Thanks a bunch for your bugreport and sorry for my slow reply. Its likely that this is fallout from some fairly big changes in the handling of dpkg. What is the best way for me to reproduce this? I don't have a kfreebsd system right now - is installing one from a current installer image in kvm the quickest way (I assume so)? Cheers, Michael -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140116064226.GU3852@bod
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Control: fixed -1 apt/0.9.12.1 I haven't updated from dpkg/1.16.12 and apt/0.9.12.1, and I haven't experienced this issue yet. -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.0-RC5 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt depends on: ii debian-archive-keyring 2012.4 ii gnupg 1.4.15-1.1 ii libapt-pkg4.12 0.9.12.1 ii libc0.1 2.17-93 ii libgcc1 1:4.8.2-1 ii libstdc++6 4.8.2-1 apt recommends no packages. Versions of packages apt suggests: pn apt-doc none ii aptitude0.6.8.2-1.2 pn dpkg-devnone ii python-apt 0.9.1 ii xz-utils5.1.1alpha+20120614-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112193656.ge8...@squeeze.pyro.eu.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Control: tags -1 found apt/0.9.14.2 Indeed upgrading only libapt-pkg4.12 is enough to trigger this. On 00:07, Robert Millan wrote: Does ktrace -d yield anything interesting? Or maybe one of dpkg's debug flags? (see dpkg --debug=help) I think this is the interesting part: 6058 apt-get CALL read(0xd,0x7fffbd10,0x400) 6058 apt-get GIO fd 13 read 0 bytes 6058 apt-get RET read 0 6058 apt-get CALL wait4(0x19ed,0x7fffc330,0x1WNOHANG,0) 6058 apt-get RET wait4 0 6058 apt-get CALL pselect(0x10,0x7fffc3c0,0,0,0x7fffc2c0,0xb39b4c) 6058 apt-get RET pselect 1 6637 dpkg RET fsync 0 6637 dpkg CALL close(0x8) 6637 dpkg RET close 0 6637 dpkg CALL close(0x4) 6637 dpkg RET close 0 6637 dpkg CALL munmap(0x8007f8000,0x4000) 6637 dpkg RET munmap 0 6637 dpkg CALL unlink(0x753d20) 6637 dpkg NAMI /var/lib/dpkg/updates/tmp.i 6637 dpkg RET unlink 0 6637 dpkg CALL fcntl(0x3,invalid=8,0xd2c0) 6637 dpkg RET fcntl 0 6637 dpkg CALL write(0x2,0x42a788,0x2a) 6637 dpkg RET write -1 errno 6 No such device or address 6637 dpkg CALL write(0x2,0x800bb70a3,0x1) 6637 dpkg RET write -1 errno 6 No such device or address 6637 dpkg CALL write(0x2,0x7fffac00,0x6) 6637 dpkg RET write -1 errno 6 No such device or address 6637 dpkg CALL write(0x2,0x800bb70a3,0x1) 6637 dpkg RET write -1 errno 6 No such device or address 6637 dpkg CALL exit(0x1) 6058 apt-get CALL read(0xd,0x7fffbd10,0x400) 6058 apt-get GIO fd 13 read 0 bytes 6058 apt-get RET read 0 6058 apt-get CALL wait4(0x19ed,0x7fffc330,0x1WNOHANG,0) 6058 apt-get RET wait4 0 6058 apt-get CALL pselect(0x10,0x7fffc3c0,0,0,0x7fffc2c0,0xb39b4c) 6058 apt-get RET pselect 2 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112200505.gf8...@squeeze.pyro.eu.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On 20:05, Steven Chamberlain wrote: I think this is the interesting part: Something interesting happened before that, too. I was trying to update the 'gzip' package: 2014-01-12 19:57:56 status unpacked gzip:kfreebsd-amd64 1.6-3 2014-01-12 19:57:57 status half-configured gzip:kfreebsd-amd64 1.6-3 2014-01-12 19:57:58 status installed gzip:kfreebsd-amd64 1.6-3 but dpkg had a problem with stdout prior to that: 6637 dpkg CALL open(0x758980,0O_RDONLY,unused0) 6637 dpkg NAMI /var/lib/dpkg/diversions 6637 dpkg RET open 7 6637 dpkg CALL fcntl(0x7,invalid=1,0) 6637 dpkg RET fcntl 0 6637 dpkg CALL fcntl(0x7,invalid=2,FD_CLOEXEC) 6637 dpkg RET fcntl 0 6637 dpkg CALL fstat(0x7,0x7fffcbd0) 6637 dpkg STRU invalid record 6637 dpkg RET fstat 0 6637 dpkg CALL mmap(0,0x4000,0x3PROT_READ|PROT_WRITE,0x1002MAP_ANON|MAP_TYPE|MAP_PRIVATE,0x,0) 6637 dpkg RET mmap 34368126976/0x80080 6637 dpkg CALL read(0x7,0x80080,0x4000) 6637 dpkg GIO fd 7 read 417 bytes [...] 6637 dpkg RET read 417/0x1a1 6637 dpkg CALL read(0x7,0x80080,0x4000) 6637 dpkg GIO fd 7 read 0 bytes 6637 dpkg RET read 0 6637 dpkg CALL break(0x9b4000) 6637 dpkg RET break 0 6637 dpkg CALL write(0x1,0x7fffaaf0,0x1c) 6637 dpkg RET write -1 errno 6 No such device or address and an error message about this subsequently fails to go to stderr: 6637 dpkg CALL fcntl(0x5,invalid=1,invalid0x753e20) 6637 dpkg RET fcntl 1 6637 dpkg CALL fcntl(0x5,invalid=2,FD_CLOEXEC) 6637 dpkg RET fcntl 0 6637 dpkg CALL fcntl(0x5,invalid=9,0xd120) 6637 dpkg RET fcntl 0 6637 dpkg CALL stat(0x753e20,0x7fffd0d0) 6637 dpkg NAMI /var/lib/dpkg/triggers/Unincorp 6637 dpkg STRU invalid record 6637 dpkg RET stat 0 6637 dpkg CALL fcntl(0x5,invalid=8,0xd110) 6637 dpkg RET fcntl 0 6637 dpkg CALL open(0x753d80,0O_RDONLY,unused0) 6637 dpkg NAMI /usr/share/locale/en_GB/LC_MESSAGES/libc.mo 6637 dpkg RET open -1 errno 2 No such file or directory 6637 dpkg CALL open(0x7681d0,0O_RDONLY,unused0) 6637 dpkg NAMI /usr/share/locale/en/LC_MESSAGES/libc.mo 6637 dpkg RET open -1 errno 2 No such file or directory 6637 dpkg CALL write(0x2,0x7fffa560,0x6c) 6637 dpkg RET write -1 errno 6 No such device or address 6637 dpkg CALL write(0x2,0x800bb70a3,0x1) 6637 dpkg RET write -1 errno 6 No such device or address 6637 dpkg CALL write(0x10,0x75b500,0x57) 6637 dpkg GIO fd 16 wrote 87 bytes status: gzip : error : error writing to 'standard output': No such file or directory 6637 dpkg RET write 87/0x57 6637 dpkg CALL open(0x75b6a0,0x601O_WRONLY|O_CREAT|O_TRUNC,0x1b6invalid438) 6637 dpkg NAMI /var/lib/dpkg/status-new 6637 dpkg RET open 8 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112202726.gg8...@squeeze.pyro.eu.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Control: reassign -1 apt Control: found -1 0.9.13~exp1 On Mon, 2013-12-23 at 07:00:00 +0100, Guillem Jover wrote: On Sun, 2013-12-22 at 21:53:19 +0100, Axel Beckert wrote: Michael Gilbert wrote: dpkg seems to often fail on kfreebsd-amd64 on unstable (I had not experienced this with wheezy). I can confirm that for kfreebsd-i386. Ok, this is something new, I had not seen it before, but I can see it being broken only when using apt. The same command using dpkg directly works fine. I can reproduce it with simply running: $ apt-get install --reinstall git The error message is E: Sub-process /usr/bin/dpkg returned an error code (1) Yeah, and noting else. It's not clear, why there was an error. The problem is that something messes with dpkg's standard output and error, and it fails when doing the fflush() and ferror() check on it in m_output() I think. But this seems to be coming from something lower than dpkg or apt, perhaps a change in glibc or the kernel. As I've tried with downgraded versions matching the ones in stable, and it still fails. I've not tested further. Ok, my testing was flawed, I missed downgrading libapt*.deb, so my initial suspicion was right, and with those now it stops failing with «src:apt=0.9.12.1». I'd recommend anyone with up-to-date apt versions on kfreebsd-* to downgrade and put these packages on hold. The last thing reported from dpkg to apt through the status-fd channel is: status: git : error : error writing to 'standard output': No such file or directory and then dpkg exits “normally” after proceeding with the error unwinding cleanup. This is easily recoverable by running the command a second time, which usually succeeds. Yeah, but it often needs multiple tries though. I usually run aptitude install -y || aptitude install -y || aptitude install -y or such after I saw such a failure. Ouch. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131225235557.ga16...@gaara.hadrons.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Hi! Guillem Jover guil...@debian.org writes: The problem is that something messes with dpkg's standard output and error, and it fails when doing the fflush() and ferror() check on it in m_output() I think. But this seems to be coming from something lower than dpkg or apt, perhaps a change in glibc or the kernel. As I've tried with downgraded versions matching the ones in stable, and it still fails. I've not tested further. It's not in the kernel as I've seen this showing up on the buildds yesterday and the buildds run stable kernels. Christoph -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gavg6ci@mitoraj.siccegge.de
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Hi, Michael Gilbert wrote: dpkg seems to often fail on kfreebsd-amd64 on unstable (I had not experienced this with wheezy). I can confirm that for kfreebsd-i386. The error message is E: Sub-process /usr/bin/dpkg returned an error code (1) Yeah, and noting else. It's not clear, why there was an error. This is easily recoverable by running the command a second time, which usually succeeds. Yeah, but it often needs multiple tries though. I usually run aptitude install -y || aptitude install -y || aptitude install -y or such after I saw such a failure. Cc'ing the kfreebsd porters' list to make them aware of the bug report. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013105318.ga15...@sym.noone.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On 22/12/2013 21:53, Axel Beckert wrote: E: Sub-process /usr/bin/dpkg returned an error code (1) Yeah, and noting else. It's not clear, why there was an error. This is easily recoverable by running the command a second time, which usually succeeds. Yeah, but it often needs multiple tries though. I usually run aptitude install -y || aptitude install -y || aptitude install -y or such after I saw such a failure. Cc'ing the kfreebsd porters' list to make them aware of the bug report. Does ktrace -d yield anything interesting? Or maybe one of dpkg's debug flags? (see dpkg --debug=help) -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52b770cd.2010...@debian.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
Hi! On Sun, 2013-12-22 at 21:53:19 +0100, Axel Beckert wrote: Michael Gilbert wrote: dpkg seems to often fail on kfreebsd-amd64 on unstable (I had not experienced this with wheezy). I can confirm that for kfreebsd-i386. Ok, this is something new, I had not seen it before, but I can see it being broken only when using apt. The same command using dpkg directly works fine. I can reproduce it with simply running: $ apt-get install --reinstall git The error message is E: Sub-process /usr/bin/dpkg returned an error code (1) Yeah, and noting else. It's not clear, why there was an error. The problem is that something messes with dpkg's standard output and error, and it fails when doing the fflush() and ferror() check on it in m_output() I think. But this seems to be coming from something lower than dpkg or apt, perhaps a change in glibc or the kernel. As I've tried with downgraded versions matching the ones in stable, and it still fails. I've not tested further. The last thing reported from dpkg to apt through the status-fd channel is: status: git : error : error writing to 'standard output': No such file or directory and then dpkg exits “normally” after proceeding with the error unwinding cleanup. This is easily recoverable by running the command a second time, which usually succeeds. Yeah, but it often needs multiple tries though. I usually run aptitude install -y || aptitude install -y || aptitude install -y or such after I saw such a failure. Ouch. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013122306.gb32...@gaara.hadrons.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On Mon, 23 Dec 2013, Guillem Jover wrote: The problem is that something messes with dpkg's standard output and error, and it fails when doing the fflush() and ferror() check on it in m_output() I think. But this seems to be coming from something lower than dpkg or apt, perhaps a change in glibc or the kernel. As I've tried with downgraded versions matching the ones in stable, and it still fails. I've not tested further. The last thing reported from dpkg to apt through the status-fd channel is: status: git : error : error writing to 'standard output': No such file or directory This is not without reminding me of this years old bug on launchpad (with hundreds of duplicates) that we never clearly understood: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/545790 I don't know if they are related but if that's the case, then it's good to finally have a way to reproduce it more reliably. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131223073257.gb9...@x230-buxy.home.ouaza.com
