mount point /tmp/tmp.${RANDOM}/var does not exist

[TJ]

ubiquity 2.21.31

mount point /tmp/tmp.${RANDOM}/var does not exist

Running the manual partitioner on 15.10 kubuntu desktop amd64 for 2015-09-24 this error shows up in the syslog after assigning existing (empty) ext4 LVs for root-fs /home /var /usr/local (no swap assigned) and /dev/mapper/LUKS_BOOT for /boot (LUKS /dev/sdc4).

The ubiquity process then spins at close to 100% of 1 CPU, shows "Saving installed packages... 0%", slide-show continues but /var/log/syslog doesn't show any progress.

ubiquity 2.18.8.9 on 14.04 is also affected in an identical way.

[TJ (tj)]

tar.gz containing logs:

$ ls -l var/log/ var/log/installer/
var/log/:
total 9760
-rw-r--r-- 1 tj tj 958 Sep 26 20:22 casper.log
drwxr-xr-x 2 tj tj 4096 Sep 26 20:23 installer
-rw-r--r-- 1 tj tj 7996300 Sep 26 22:33 partman
-rw-r----- 1 tj tj 1985442 Sep 26 22:47 syslog

var/log/installer/:
total 20
-rw-r--r-- 1 tj tj 5783 Sep 26 22:32 debug
-rw-r--r-- 1 tj tj 4557 Sep 26 20:23 dm
-rw-rw-r-- 1 tj tj 17 Sep 26 21:43 version

[TJ (tj)]

An additional knock-on bug; quitting the installer GUI (pressing the X window control) causes the GUI to be dismissed but the ubiquity process remains running, with CPU usage at 100%.

[TJ (tj)]

ps -efly | grep ubiquity:

S root 1 0 0 80 0 6040 29929 ep_pol 20:21 ? 00:00:09 /sbin/init maybe-ubiquity splash ---
S kubuntu 3896 17914 0 80 0 2348 2375 pipe_w 23:11 pts/0 00:00:00 grep --color=auto ubiquity
S root 18144 17603 0 80 0 1628 1119 wait 21:43 ? 00:00:00 /bin/sh /usr/lib/udisks2/udisks2-inhibit /usr/lib/ubiquity/bin/ubiquity kde_ui
R kubuntu 18158 18144 44 80 0 196548 476922 ? 21:43 ? 00:38:53 /usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity kde_ui
S root 31662 18158 0 80 0 37712 20722 pipe_w 22:32 ? 00:00:00 /usr/bin/perl -w /usr/bin/debconf-communicate -fnoninteractive ubiquity
S root 31664 18158 0 80 0 37616 20689 pipe_w 22:32 ? 00:00:00 /usr/bin/perl -w /usr/bin/debconf-communicate -fnoninteractive ubiquity

[TJ (tj)]

On 14.04 I re-ran ubiquity in --debug mode.

The process stalled with 100% CPU use at around 02:55. I suspect the causeis the non-zero return code from partman-commit:

debconf (developer): --> 1 Installing system
Sep 27 02:55:31 debconf (filter): --> 0 OK
Sep 27 02:55:31 debconf (filter): <-- PROGRESS INFO ubiquity/install/apt_clone_save
Sep 27 02:55:31 debconf (filter): widget found for ubiquity/install/title
debconf (developer): <-- METAGET ubiquity/install/apt_clone_save description
debconf (developer): --> 1 Saving installed packages...
Sep 27 02:55:31 debconf (filter): --> 0 OK
Sep 27 02:55:31 ubiquity: ['log-output', '-t', 'ubiquity', '--pass-stdout', '/bin/partman-commit'] exited with code 32

[TJ (tj)]

Ubiquity --debug logs for 15.10 (ISO kubuntu-desktop-amd64 20150924)

[TJ (tj)]

This snapshot from 15.10, taken at 12:07, shows how the installer GUI has reached the end of its slide-show but is still reporting "Saving installed packages... 0%", the python/ubiquity process is using 100% of 1 CPU core, whilst the terminal below it shows a "tail -f /var/log/installer/debug" with the error line:

Sep 27 11:58:49 ubiquity: ['log-output', '-t', 'ubiquity', '--pass-stdout', '/bin/partman-commit'] exited with code 32

[TJ (tj)]

Another run with 15.10 ubiquity --debub, with "set -x" added to /bin/partman-commit. Shell script output is captured in var/log/syslog.

Sep 27 12:36:06 kubuntu partman: mkswap:
Sep 27 12:36:06 kubuntu partman: /dev/sdc3: warning: wiping old swap signature.
Sep 27 12:36:06 kubuntu partman:
Sep 27 12:36:06 kubuntu ubiquity: + [ -x /lib/partman/commit.d/50format_basicfilesystems ]
Sep 27 12:36:06 kubuntu ubiquity: + /lib/partman/commit.d/50format_basicfilesystems
Sep 27 12:36:06 kubuntu kernel: [11258.056247] Adding 5242876k swap on /dev/sdc3. Priority:-1 extents:1 across:5242876k FS
Sep 27 12:36:06 kubuntu ubiquity: + [ -x /lib/partman/commit.d/50format_btrfs ]
Sep 27 12:36:06 kubuntu ubiquity: + /lib/partman/commit.d/50format_btrfs
Sep 27 12:36:06 kubuntu ubiquity: + [ -x /lib/partman/commit.d/50format_efi ]
Sep 27 12:36:06 kubuntu ubiquity: + /lib/partman/commit.d/50format_efi
Sep 27 12:36:07 kubuntu ubiquity: + [ -x /lib/partman/commit.d/50format_ext3 ]
Sep 27 12:36:07 kubuntu ubiquity: + /lib/partman/commit.d/50format_ext3
Sep 27 12:36:07 kubuntu ubiquity: + [ -x /lib/partman/commit.d/50format_jfs ]
Sep 27 12:36:07 kubuntu ubiquity: + /lib/partman/commit.d/50format_jfs
Sep 27 12:36:07 kubuntu ubiquity: + [ -x /lib/partman/commit.d/50format_xfs ]
Sep 27 12:36:07 kubuntu ubiquity: + /lib/partman/commit.d/50format_xfs
Sep 27 12:36:07 kubuntu ubiquity: + [ -x /lib/partman/finish.d/01apt_clone_save ]
Sep 27 12:36:07 kubuntu ubiquity: + /lib/partman/finish.d/01apt_clone_save
Sep 27 12:36:07 kubuntu kernel: [11259.041784] EXT4-fs (dm-22): mounted filesystem with ordered data mode. Opts: (null)
Sep 27 12:36:07 kubuntu ubiquity: mount:
Sep 27 12:36:07 kubuntu ubiquity: mount point /tmp/tmp.jngT8xIZHZ/var does not exist
Sep 27 12:36:07 kubuntu ubiquity:
Sep 27 12:36:07 kubuntu ubiquity[22328]: debconffilter_done: ubiquity.components.partman_commit (current: None)

This appears to suggest 01apt_clone_save is being called too early - before the sub-mounts and basic file-system structure is in place maybe?

[Simon Quigley (tsimonq2)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. If you test it and it is still an issue, kindly upload the updated logs by running only once:
apport-collect 1500110

and any other logs that are relevant for this particular issue.

[Launchpad Janitor (janitor)]

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]