Ubiquity crashes over recipe that leads to "Missing filesystem.size."

hello

you must regenerate this filesystem.size

printf $(sudo du -sx --block-size=1 chroot | cut -f1) > image/casper/filesystem.size

in the casper dir of your live-cd with the filesystem.squashfs ....

Just as smo says, you need to provide a filesystem.size file with your live CD.

Work around -- Please take a look at http://forums.linuxmint.com/viewtopic.php?f=46&t=49841&p=305723#p305723

Reopening. We should really provide fallback code here; it wouldn't hurt us to be a bit slower in cases where derivatives have forgotten to create this file rather than crashing.

My naive search has found 17 bugs matching this symptom. I'm pretty sure there are more as I haven't looked inside tarball attachments and the like.

Apparently e.g. unetbootin fails to copy this file, which is another source of this kind of problem. See bug 837186. While I'm going to stop ubiquity crashing in this case, (a) it would be good for performance if unetbootin copied this file, and (b) I can't retroactively fix old Ubuntu images but modern unetbootin code might well be used with older Ubuntu images.

I don't believe that UNetbootin is actually leaving out filesystem.size (at any rate I just tried running several versions it on various platform to create a Ubuntu 11.10 live USBs and the file is indeed there every time); rather it seems that the bug reports where , for whatever reason, the users unmounted /cdrom before starting the installer, in which case of course it wouldn't be found; see, for example https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/875190 (first line: "Did umount -l -r -f /media/cdrom before starting the installer") and http://ubuntuforums.org/showthread.php?p=10225227 ("... it seems like people got it right by manually unmounting /cdrom. When I tried that however..."); those 2 are the only references that I have found that seem to claim that UNetbootin left out the file. So unless there's actually someone who has actually checked the filesystem and found that the filesystem.size file is missing, this should be marked invalid for UNetbootin.

And observing https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/877032 the user says the filesystem.size file is indeed there in the casper folder on the filesystem in spite of getting this error, so yes, this indeed seems to be users deciding to unmount the filesystem rather than UNetbootin leaving the file out. Perhaps whatever error message Ubiquity is printing which is leading the users to decide they need to unmount the filesystem could be made more clear?

Based on https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/875519 it appears that the misleading error message Ubiquity is giving which leads users to unmount /cdrom and get this error is "Can't unmount /cdrom".

And I believe I now know what the scenario which is leading to this error is. UNetbootin has an option to put the live environment (squashfs and all) onto a hard drive partition (the hard drive install mode), so that it can be booted in live mode. If a user has a single system partition, puts the live Ubuntu environment onto that partition, and attempts to boot it, it will boot into live mode correctly.

However, if the user launches the installer, then the only partition which can be installed to is the same hard drive partition that the live Ubuntu environment is running from. Hence, when the partitioner starts, it will attempt to unmount that partition (which is currently mounted to /cdrom), and this will of course fail because that's where filesystem.casper et al reside. Hence the user gets the "Can't unmount /cdrom" error. The user now manually unmounts /cdrom, starts the installer, and gets this error.

So, I believe the solution would be to display an error message more along the lines of "you can't install to the partition that you booted the Ubuntu live environment from; please use a CDROM or USB drive to install".

That seems like a sensible analysis, but I'd like to track it separately
(because there are other reasons filesystem.size might actually be
missing). Would you mind filing a separate bug against ubiquity for
this?

This bug was fixed in the package ubiquity - 2.9.20

---------------
ubiquity (2.9.20) precise; urgency=low

  [ Colin Watson ]
  * Restore old fallback code in case /cdrom/casper/filesystem.size doesn't
    exist (LP: #557388).
  * Fix some more uses of deprecated python-apt APIs.
  * ubiquity-dm: Try openbox after openbox-lubuntu (LP: #888107).
  * Thomson SA is now called Technicolor SA (LP: #856992).
  * Limit maximum length of username editing widgets to 32 (LP: #831319).
  * UTF-8-encode the syslog message when a geoname lookup fails, since it
    might include non-ASCII characters entered by the user (LP: #928891).
  * Run test suite under xvfb-run by default when running it from the
    command line. 'tests/run --no-xvfb' inhibits this behaviour for cases
    where it's useful to see the UIs constructed by the test suite.
  * Stop manually inserting newlines in hostname and username errors. GTK+
    3 seems to do a reasonable job of wrapping these by itself now.
  * Port the user page from GtkTable to GtkGrid, so that we get sensible
    height-for-width geometry management (LP: #830933).
  * Internationalise hostname and username validation errors (LP: #784825).

  [ Mario Limonciello ]
  * Have two separate failsafe attempts for 'fbdev' and 'vesa'. It's
    possible that /dev/fb0 will exist but be backed by a VGA framebuffer
    causing X to exit non-zero.

  [ Stéphane Graber ]
  * Use the Xubuntu wallpaper when available. (LP: #936572)
  * Detect bogus DNS servers and ignore them. (LP: #760884)
  * Automatic update of included source packages: base-installer
    1.122ubuntu5, choose-mirror 2.39ubuntu4.
 -- Stephane Graber <email address hidden> Tue, 21 Feb 2012 21:09:02 -0500