Bug#814408: aptitude uses all disk space (12G) with recursive trace-dump in /tmp

2016-02-11 Thread Chris Tillman
Package: aptitude
Version: 0.7.5-3
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

   * What led up to the situation?
I had upgraded all packages a couple of weeks ago to testing current level.
Today I opened aptitude, performed update, and it said there were 123 packages
to be updated. I marked the Upgradeable line with +.
It said it was Resolving Dependencies, and then became unresponsive. I went on
to do something else. After 10 minutes or so I found I could not use readline
completion in bash because I had run out of disk space on the root device.
Going back to the aptitude window, I saw many out of disk space messages.
I hit OK on the messages window, and then canceled my pending actions and quit
aptitude.
Once back on the command line, I confirmed I was out of space with df -h.

root@ctillman:/home/chris# df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda519G   17G  865M  96% /

 Conveniently, I had just done df -h before starting the upgrade, so I scrolled
back up and verified I had 12G free beforehand.

root@ctillman:/home/chris# df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda519G  7.0G   11G  41% /

I then used du to drill down to where the space was being used. Here are the
final few lines.

root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH/
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton
9.7G/tmp/aptitude-root.7985:PR9HPH/
root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-
root.7985\:PR9HPH/*
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr
16K /tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/etc
24K /tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/var
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton
root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-
root.7985\:PR9HPH/usr
du: cannot access ‘/tmp/aptitude-root.7985:PR9HPH/usr’: No such file or
directory
root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH
/aptitude-trace-dumpubvton/usr
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr/bin
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr
root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH
/aptitude-trace-dumpubvton/usr/bin
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr/bin/X11
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr/bin
root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH
/aptitude-trace-dumpubvton/usr/bin/X11
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-
dumpubvton/usr/bin/X11/X11
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-dumpubvton/usr/bin/X11
root@ctillman:/home/chris# du --max-depth=1 -h /tmp/aptitude-root.7985\:PR9HPH
/aptitude-trace-dumpubvton/usr/bin/X11/X11/X11/X11/X11/X11/
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-
dumpubvton/usr/bin/X11/X11/X11/X11/X11/X11/X11
9.7G/tmp/aptitude-root.7985:PR9HPH/aptitude-trace-
dumpubvton/usr/bin/X11/X11/X11/X11/X11/X11/

As you can see, the X11 directory has been recursively created.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Quit aptitude, that freed up about 1G. Then
root@ctillman:/home/chris# rm -rf /tmp/aptitude-root.7985:PR9HPH/aptitude-
trace-dumpubvton/usr/bin/X11/X11/X11/X11/X11/X11/

   * What was the outcome of this action?
root@ctillman:/home/chris# df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda519G  6.9G   11G  40% /



-- Package-specific info:
$TERM not set.
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.5
Compiler: g++ 5.3.1 20151207
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.6.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20151024
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-gate.so.1 (0xb771)
libapt-pkg.so.5.0 => /usr/lib/i386-linux-gnu/libapt-pkg.so.5.0 
(0xb71b8000)
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb7182000)
libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb715d000)
libsigc-2.0.so.0 => /usr/lib/i386-linux-gnu/libsigc-2.0.so.0 
(0xb7156000)
libcwidget.so.3 => /usr/lib/i386-linux-gnu/libcwidget.so.3 (0xb7053000)
libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xb6f71000)
libboost_iostreams.so.1.58.0 => 
/usr/lib/i386-linux-gnu/libboost_iostreams.so.1.58.0 (0xb6f58000)
libboost_filesystem.so.1.58.0 => 
/usr/lib/i386-linux-gnu/libboost_filesystem.so.1.58.0 (0xb6f3c000)
libboost_system.so.1.58.0 => 
/usr/lib/i386-linux-gnu/libboost_system.so.1.58.0 (0xb6f37000)
libxapian.so.22 => /usr/lib/i386-linux-gnu/sse2/libxapian.so.22 
(0xb6d2d000)
libpthread.so.0 

Bug#782498: network-manager: GLib-GObject-CRITICAL **: object NMIfupdownConnection Seen in log (reported fixed in #743166)

2015-04-13 Thread Chris Tillman
Package: network-manager
Version: 0.9.10.0-6
Severity: serious
Justification: Reporting as serious because the other bug reporting the
error was serious and the message says CRITICAL

(See attachment generated by reportbug)


reportbug-network-manager-20150413-1976-xJuccQ
Description: Binary data


Bug#758932: kernel crash on usb disk removal

2014-09-18 Thread Chris Tillman
Here are the log statements from kern.log on that occasionn. Is there
anything else I can supply?

Aug 23 10:01:37 121-73-239-129 kernel: [143836.389518] usb 2-6: USB
disconnect, device number 3
Aug 23 10:01:37 121-73-239-129 kernel: [143836.591902] FAT-fs (sdb9):
unable to read boot sector to mark fs as dirty
Aug 23 10:01:37 121-73-239-129 kernel: [143836.764466] Buffer I/O error on
device sdb10, logical block 2
Aug 23 10:01:37 121-73-239-129 kernel: [143836.764474] lost page write due
to I/O error on sdb10

Chris



On Fri, Sep 19, 2014 at 4:57 AM, Riku Voipio riku.voi...@iki.fi wrote:

 severity 758932 normal
 reassign 758932 linux-image-3.14-2-686-pae
 thanks

 Hi Chris,

 A kernel crash is usually not the fault of userspace applications -
 it's a kernel bug. For kernel bugs, full kernel logs are needed for
 debugging.

 Riku




-- 
Chris Tillman
Developer


Bug#758932: udisksd: Disconnecting USB disk results in kernel crash

2014-08-22 Thread Chris Tillman
Package: udisks2
Version: 2.1.3-2
Severity: critical
File: udisksd
Justification: breaks the whole system

Dear Maintainer,

   * What led up to the situation? Disconnecting a USB drive
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Could not regain access to the system, had to cold boot

Here are entries from syslog just after disconnecting the drive until the
kernel crash.

Aug 23 10:01:37 121-73-239-129 kernel: [143836.389518] usb 2-6: USB disconnect,
device number 3
Aug 23 10:01:37 121-73-239-129 udisksd[1529]: Cleaning up mount point
/media/ctillman/15d722f2-ca41-4346-9def-d70df88e350f (device 8:28 no longer
exist)
Aug 23 10:01:37 121-73-239-129 udisksd[1529]: Cleaning up mount point
/media/ctillman/win (device 8:25 no longer exist)
Aug 23 10:01:37 121-73-239-129 kernel: [143836.591902] FAT-fs (sdb9): unable to
read boot sector to mark fs as dirty
Aug 23 10:01:37 121-73-239-129 gnome-session[1424]: libmediaart-Message:
Mount:'19 GB Volume' with UUID:'15d722f2-ca41-4346-9def-d70df88e350f' now
unmounted from:'/media/ctillman/15d722f2-ca41-4346-9def-d70df88e350f'
Aug 23 10:01:37 121-73-239-129 udisksd[1529]: Cleaning up mount point
/media/ctillman/Mac9.2 (device 8:27 no longer exist)
Aug 23 10:01:37 121-73-239-129 udisksd[1529]: Cleaning up mount point
/media/ctillman/bootstrap (device 8:26 no longer exist)
Aug 23 10:01:37 121-73-239-129 kernel: [143836.764466] Buffer I/O error on
device sdb10, logical block 2
Aug 23 10:01:37 121-73-239-129 kernel: [143836.764474] lost page write due to
I/O error on sdb10

I believe this occurred because I had a terminal window open in one of the
directories on the USB mounted drive when I disconnected it (the 19GB volume
which was sdb10).





-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.14-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages udisks2 depends on:
ii  dbus   1.8.6-1
ii  libacl12.2.52-1
ii  libatasmart4   0.19-3
ii  libc6  2.19-9
ii  libglib2.0-0   2.40.0-4
ii  libgudev-1.0-0 208-6
ii  libpam-systemd 208-6
ii  libpolkit-agent-1-00.105-6.1
ii  libpolkit-gobject-1-0  0.105-6.1
ii  libsystemd-daemon0 208-6
ii  libsystemd-login0  208-6
ii  libudisks2-0   2.1.3-2
ii  parted 3.2-4
ii  udev   208-6

Versions of packages udisks2 recommends:
ii  dosfstools   3.0.26-3
ii  eject2.1.5+deb1+cvs20081104-13.1
ii  gdisk0.8.8-1
ii  ntfs-3g  1:2014.2.15AR.1-5
ii  policykit-1  0.105-6.1

Versions of packages udisks2 suggests:
pn  btrfs-tools none
ii  cryptsetup-bin  2:1.6.4-4
pn  exfat-utils none
pn  mdadm   none
pn  reiserfsprogs   none
pn  xfsprogsnone

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org