Click fails to create chroot (exit status 100) during Kit creation process

Bug #1398460 reported by Aaron Hastings
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
click (Ubuntu)
New
Undecided
Unassigned

Bug Description

Creating a Kit using the Ubuntu SDK startup wizard. Everything starts okay and packages begin to download and install, etc. All of a sudden the process stops and I get the following output in bold red text:

There was an error creating the click target, cleaning up
click target was removed successfully

---Click exited with errors, please check the output---Traceback (most recent call last):
  File "/usr/bin/click", line 86, in <module>
    sys.exit(main())
  File "/usr/bin/click", line 82, in main
    return mod.run(args)
  File "/usr/lib/python3/dist-packages/click/commands/chroot.py", line 266, in run
    return args.func(parser, args)
  File "/usr/lib/python3/dist-packages/click/commands/chroot.py", line 68, in create
    return chroot.create(args.keep_broken_chroot)
  File "/usr/lib/python3/dist-packages/click/chroot.py", line 506, in create
    self.full_name, ret_code))
click.chroot.ClickChrootException: Failed to create chroot 'click-ubuntu-sdk-14.10-armhf' (exit status 100)
Command returned 100: schroot -u root -c source:click-ubuntu-sdk-14.10-armhf -- /finish.sh
E: Sub-process /usr/bin/dpkg returned an error code (2)
E: Failed to write temporary StateFile /var/lib/apt/extended_states.tmp
dpkg: unrecoverable fatal error, aborting:
 unable to create `/var/lib/dpkg/updates/tmp.i': No space left on device
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
dpkg: error processing archive /var/cache/apt/archives/libboost1.55-dev_1.55.0+dfsg-1ubuntu3_armhf.deb (--unpack):
 unable to create `/usr/include/boost/flyweight/detail/value_tag.hpp.dpkg-new' (while processing `./usr/include/boost/flyweight/detail/value_tag.hpp'): No space left on device
Moving old data out of the way

Revision history for this message
Aaron Hastings (thecosmicfrog) wrote :

Okay, turns out this is not a false reporting. My root filesystem turned out to be eating inodes, locking up my system just a few minutes later.

Still, I'll leave this here in case it presents any usability issues (e.g. better reporting that disk space is the cause).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.