Ubiquity got stuck at 'Identifying file system...'

Bug #1373365 reported by sudodus on 2014-09-24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)

Bug Description

I had a partition made and formatted to ext4 with gparted, so it is not a problem because of reformatting.

I did not use OEM, so it should not be 'post-OEM', but maybe it is the same cause?


Isotesting: From the live session I tried 'something else' at the partitioning page, reused a shared swap partition, and used a partition made for this purpose, that was never used (only formatted). I had complaints, that the swap was on when it was not on. After re-trying, the installer could continue.

The target drive is a USB HDD dedicated to testing. There are already two linux distros installed: Xubuntu and Mageia, but it should work anyway.

I could enter language and user identification. The installation continued, but got stuck with a rotating round cursor at the text 'Identifying file system...' (in Swedish).

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: ubiquity 2.19.8
ProcVersionSignature: Ubuntu 3.16.0-17.23-generic 3.16.3
Uname: Linux 3.16.0-17-generic i686
ApportVersion: 2.14.7-0ubuntu2
Architecture: i386
CasperVersion: 1.344
CurrentDesktop: LXDE
Date: Wed Sep 24 12:39:24 2014
InstallCmdLine: file=/cdrom/preseed/lubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash -- debian-installer/language=sv keyboard-configuration/layoutcode?=se
LiveMediaBuild: Lubuntu 14.10 "Utopic Unicorn" - Alpha i386 (20140923)
 PATH=(custom, no user)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

sudodus (nio-wiklund) wrote :
sudodus (nio-wiklund) wrote :

After writing the bug report, I tried to shut down the installer window. Then it responded with:

'The installation has finished...'. That info window was a little hard to shut down, but finally it went away. And then there was a good (normal) shutdown sequence. But no system was installed.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
sudodus (nio-wiklund) wrote :

Trying again, this time directly from Syslinux via 'Install Lubuntu', and formatting the (same) partition: It reached 'Restart' seeming to work well, but it ended at a black screen and I had to press the Enter key to make it restart. Not only was something installed, it was a working Lubuntu Utopic system :-)

So my conclusion so far is that either there are problems installing from the live session, or the installer was not happy with the file system made by gparted.

sudodus (nio-wiklund) wrote :

3rd test:

Trying again, this time again from a live session , and using another partition formatted by gparted: This time it created a working Lubuntu Utopic system :-)

So my conclusion so far is that either there are problems installing from the live session when several other programs has been run (testing that the live session works), or that first particular file system made by gparted was bad. The Ubiquity installer has been very sensitive during several versions, and installation should be done at once, not after running several other programs, particularly with low RAM.

With 4 GB RAM (in this test), there should not be a problem with too low RAM, but maybe zRAM was crowded and caused problems (zRAM is used in Lubuntu's live session).

4th test:

Tried again, this time without swap and zRAM, but running some programs before starting Ubiquity and setting up the root partition for re-formatting. The same thing happened as the first time (or very similar). Stuck at 'Identifying file system...'.

I had htop on, and it showed RAM usage approx 300 MB (of a total of 4 GB) so the computer was not running out of memory.

Just after leaving the partitioning screen the system complained that it could not shut off the swap. But I had already done it manually (including zRAM).

It seems that Ubiquity is happy only when it is allowed to run first (not after other programs have been running).

sudodus (nio-wiklund) wrote :

I can turn swap on and off manually (in the same live session after the install failure in the 4th test). And I can mount and unmount the target device for the root file system (manually with mount and umount).

But for some reason Ubiquity has problems.

sudodus (nio-wiklund) wrote :

I was asked to change the severity from a red bug to a grey bug (and did so) because far nobody else has been affected by this bug.

sudodus (nio-wiklund) wrote :

5th test


6th test


I found the problem:

A program tested before ubiquity left cruft in /etc/mtab, which was not seen by df, and not affecting terminal window commands (umount and swapoff), but it was affecting ubiquity. This is a very special case.

Running various programs, and checking that /etc/mtab is clean (matching the output of df), makes it possible to install into this same computer (as in tests #1-4) with a USB 3 HDD, as well as installing into another computer's internal HDD.

So we can give this bug very low priority.

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

Other bug subscribers