karmic beta: This computer has only 0 bytes disk space

Bug #444901 reported by NoOp on 2009-10-06
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)

Bug Description

Binary package hint: ubiquity

Testing karmic beta liveCD installer.

System: 1Ghz/384Mb - 2 drives: 1 10.2G (sda), 1 20G (sdb)
sda has 9.10 installed from Alternate CD (karmic beta)
sdb has 8.04 installed.

Insert liveCD & elect to install.
Partition screen defaults to sdb 8.04 install.
Selected 'Erase and use the entire disk'
 SCSII (0,0,0) (sda) - 10.2 GB ATA ST310212A
 ! This will delete Ubuntu karmic (development branch) (9.10) and
install Ubuntu 9.10.
Select 'Forward' & 'Install' on next screen.
Eventually popup appears advising: "This computer has only 0 bytes disk space remaining."

Repeated the test 4 times; one test used gparted to reformat sda to ext3 w/same results.
Screenshots follow.
Note: I have no problems installing on sda using the Alternate CD w/guided partitioning.

NoOp (glgxg) wrote :
NoOp (glgxg) wrote :
NoOp (glgxg) wrote :
NoOp (glgxg) wrote :
Fred Korz (korz-vendor) wrote :

I've had a similar experience in an independent environment, confirming it's not unique to NoOp's setup, and narrowed down some hypotheses seen in mailing list posts (which led me here).

My test environment is a 1.2GHz Via C3 box, running Debian (squeeze) and virtualbox, used to test Ubuntu and other installations in virtual machines.

Using 384MB and 512MB virtual machines, with virtual disks of 8GB per virtual machine, I tried a series of things.

 * 9.04 OK: A 9.04 graphical desktop install went fine.

 * 9.10 overlay FAIL: Wanting to try 9.10 beta (before upgrading my netbook) I attempted to install over the 9.04 in the virtual machine. I selected the erase and use whole disk. It failed in the way described above.

 * 9.10 clean FAIL: On the chance it was the installing over 9.04, I deleted the virtual disk and provided a new, empty one. Same failure.

 * 9.10 alt installer - OK: Thinking it might be the installer or virtual machines RAM size, I used the alternate installer and raised the VM's RAM to 512MB and with a new, empty virtual disk. Success

 * 9.10 clean moreram FAIL: To check installer vs. RAM, I tried 512MB RAM, regular 9.10 beta installer and a new, empty virtual disk. Failure as above.

So, whether two disks as NoOp wrote or one virtual disk in my case, no difference - regular installer fails with the 0 bytes message, alternate installer succeeds.

Also, the amount of memory which can be a sensitive point for some Linux distributions' installers, no difference in outcome.

For reference I'll attach three pngs from the failure path.

Fred Korz (korz-vendor) wrote :

Here is the screen shot of the virtual machine, having been dumped back into the live cd environment after the "0 byte" message with 'df' and 'mount' output. Perhaps the installer has already unmounted the disk, or perhaps it never mounted it.

Fred Korz (korz-vendor) wrote :

The "0 bytes" message screenshot.

If there's a new beta before the RC or the rollout, I could download the iso and try again. Trying takes about 2 hours total between the iso download and the actual trial.

joeclarkia (joeclark) wrote :

I had the same problem on a computer with ~384 MB RAM and a 10GB disk using one of the Karmic daily builds (2009-10-04). I first ran the Install icon from within the LiveCD GUI, and it got to the partitioning phase (only 5sec or so into the real install phase), and then the window just disappeared, and there didn't appear to be any further install-related activity.

I then ran the Install from boot and it acted pretty much exactly as described in the report(s) above. Install seemed to go okay for a minute or so, then X appeared to crash with the install continuing (install.py showing in top), then the text-mode messages, then reload of X with the LiveCD running and the "0 bytes" message. Interestingly, at the end of this, the LiveCD environment was active, but not very usable -- menus were not very responsive, etc.

Interestingly, I previously used the same CD to install the daily build on another computer (1 GB RAM, 172GB hard disk), and it installed without any problems.

joeclarkia (joeclark) wrote :

Tried again on same computer, found something in /var/log/installer/debug. At the end of the file, it says:

  30%: Getting the time from a network time server...
  30%: Scanning disks...
  30%: Detecting file systems...

  Unable to commit the partition table, exiting.

Aha! Why would it be unable to commit the partition table?

joeclarkia (joeclark) wrote :

Aha #2! I found this in /var/log/messages

  Oct 15 05:37:00 ubuntu ubiquity: Cannot open display "default display"
  Oct 15 05:37:02 ubuntu ubiquity: cp: cannot stat `/var/lib/partman/devices': No such file or directory

Not sure if the first line is normal or not, but the 2nd one sounds ominous. partman == partition manager?

Evan (ev) wrote :

Just to rule it out, can anyone that's experiencing this bug please boot the CD into "Try or Install Ubuntu", remove the ubiquity-slideshow-ubuntu package, and then attempt an install and report back here on whether or not that let you proceed?


Changed in ubiquity (Ubuntu):
status: New → Incomplete
NoOp (glgxg) wrote :

@Evan: Be happy to give it a shot. Unfortunately I most likely won't be able to get to it until Monday (US Pacific time).

joeclarkia (joeclark) wrote :

@NoOp: good catch! I downloaded karmic daily 2009-10-14, and tried an install the old way, and got the same sort of errors. So then I took your suggestion and did sudo apt-get remove ubiquity-slideshow-ubuntu first, and now the install seems to be going fine.

While I waited for the install I looked around some, and found bug #445050. Looks like they are duplicates (and that one also mentions #440407 as a probable duplicate). Being a newcomer here, I'll let someone else make that call officially.

For the record, my test machine's CPU is an Athlon XP 2000+ (notably, most others reporting this problem also have Athlons).

joeclarkia (joeclark) wrote :

oops, meant to say @Evan

Evan (ev) wrote :

There are two bugs here. One is what's causing the installer to crash, and the other is what's causing the live CD session to crash.

The former is, I suspect, a webkit bug that we've identified as causing lots of installer crashes. I've been dealing with each of those installer crash reports individually, to make sure we're not missing a crash that simply looks similar to the webkit one. However, the webkit bug is fixed in the latest version in the archive, so please try the latest daily live CD (http://cdimage.ubuntu.com/daily-live/) if you're experiencing installer crashes.

The latter bug that's occurring here is caused by the installer starting the noninteractive frontend on failure, which proceeds to install onto the live CD session, thus causing the missing icons and "0 bytes free space" messages. I've committed a fix for this to trunk, but it hasn't made it onto the CDs yet.

If you are experiencing crashes with a daily live CD that's newer than yesterday, please file a new bug.


Changed in ubiquity (Ubuntu):
status: Incomplete → Fix Committed
Fred Korz (korz-vendor) wrote :

Used the 20091018 daily (karmic desktop i386).
Successful installation in full graphical mode, unlike the beta last week (where I had to use the alternate installer).
 I'll try RC1 when it comes out (on the 22nd per the schedule, if I recall correctly).

Thanks - Fred

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 2.0.1

ubiquity (2.0.1) karmic; urgency=low

  [ Evan Dandrea ]
  * Check to see whether X crashed or ubiquity crashed before attempting
    to bail into the noninteractive frontend from only-ubiquity mode
    (LP: #444901).
  * Wrap the format warning label while working around GTK+ label layout
    problems (LP: #364617).

  [ Colin Watson ]
  * Rewrite X_LOADTEMPLATEFILE commands in case they refer to template files
    in the /target chroot (LP: #452118).
  * Install -generic-pae kernels if necessary; this requires some custom
    hacks since -generic-pae isn't in the live filesystem (LP: #413135).
  * Don't do kernel installation/removal in oem-config.
  * Skip partition_too_small check during Wubi installs, as Wubi does some
    of its own checks and the delay imposed by this check looks particularly
    weird in Wubi. This may or may not be the cause of apparent hangs
    towards the end of partitioning, but I suspect that it will at least get
    rid of some conflated reports and make testing quicker.
  * Update translations from Launchpad.
  * Automatic update of included source packages: clock-setup 0.98ubuntu3,
    flash-kernel 2.13ubuntu13, grub-installer 1.43ubuntu6, partman-auto
    89ubuntu2, partman-target 64ubuntu4.

  [ Mario Limonciello ]
  * Mythbuntu: Don't allow "removing" LIRC as it's not supported with install.

  [ Roman Shtylman ]
  * Fixed India timezone map (LP: #453009)

  [ Michael Casadevall ]
  * Added support for partman-uboot in ubiquity (LP: #455713)

 -- Colin Watson <email address hidden> Tue, 20 Oct 2009 01:20:06 +0100

Changed in ubiquity (Ubuntu):
status: Fix Committed → Fix Released
NoOp (glgxg) wrote :

Sorry for the delay in testing this... must have been waiting for launchpad to respond :-)

Tested today using
and it worked - thanks. Only issue is why it does not offer to import the installed 9.10 home (as was done previously in jaunty). It offers to import the WinXP files from sda, (step 6 of 7) but not the 9.10 files from sdb. No idea what I'd do with the WinXP files from sda...

Stephen Birch (sgbirch) wrote :

Note - this bug causes karmic rc installation failures, see bug 446182

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

Other bug subscribers

Remote bug watches

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