Ubiquity should have a command line option to override the free space check

Catchup from bug https://bugs.launchpad.net/bugs/772164
"same behavior on an EeePc 4G; the forward button is greyed out."
"please file bug against the ubiquity package"
"I've got a work around...
Run the live CD, press alt+f2 and type:
gksu gedit /usr/lib/ubiquity/plugins/ubi-prepare.py
Then on line 310, change "min_disk_size = size * 2" to "min_disk_size = size * 1.4"
Then run then Ubuntu installer."

more people bugged by this bug:
http://ubuntuforums.org/showthread.php?t=1737684

more people bugged by this bug:
http://ubuntuforums.org/showthread.php?t=1736109

Here is the wonder boy who caused this bug:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/745148/comments/10

Thanks, marker. That did the trick! On my EeePC 4G a full Ubuntu install takes up 2.6 GB, leaving 1.4 GB, which is 35% of the total storage. I would have to try to install in a VM to see what the minimum required margin is, but whatever it is I'm sure it's a value you must add, not multiply!

Actually that idea was thanks to Nathan, see (https://bugs.launchpad.net/bugs/772164). I don't mean to take credit for it.

Arturo, excellent idea. I just installed it in a VM, so I could see the peak disk space used based on the size of my .vdi file. On the disk, the base install of ubuntu-11.04-desktop-i386.iso only takes up 2.2GB, but the .vdi file is 2.6GB (2708508672 bytes), so that was its peak for a base install, no extra packages.

I just think its awful for the UI to enforce an arbitrary (and artificially high) limit. The UI says "for best results, have 4.4GB, a connection to the internet, and be plugged into power" (see attached screenshot above), when actually you are completely hindered from proceeding.

Hello, I would like to add my experience on this matter. A long time ago (I think with ubuntu 10.04) I had a problem after some time. I had it installed on a 4gb ssd netbook and after some months it ran out of space and I could not even login due to the full disk. I think that as time passes the disk fets full because of the updates... Right now I use jolicloud (which is based on ubuntu) for about 6 months and the problem seems to be gone.

I finally got around to doing some testing with both Lubuntu 11.04 (which I realize was not officially part of Ubuntu) and the Lubuntu Oneiric alpha 3 image, but I don't think the DE makes much difference here. Regardless Lubuntu Natty requires 5.3GB and the Lubuntu Oneiric alpha 3 requires 4.6GB so it's not possible to install on my machine with an old 3.2GB drive in spite of having a 1500mhz CPU and 2GB of RAM.

As said I think this is really DE agnostic because an advanced user should know what they're doing and be able to override most defaults using the live CD. Consider that we're presented with three "must have" options:

1) has at least <such-n-such> drive space
2) is plugged in to a power source
3) is connected to the internet

I have no laptop or netbook so I can't test option #2 regarding the need for a hardwired power source but I have tried installing with no Internet connection just by unplugging my ethernet cable and the installation does proceed, usually successfully (language packs can be problematic but that's easily solved post-installation).

So I really don't think we need to be presented with a CLI option. Why can't the disc space option be treated just like the internet option? That is more as a warning than an absolute dead-end? How is the power source option treated?

When I look at that "page" in the installation process I really don't see any wasted space so I don't see how we could add an additional line such as:

Proceeding if any of the above are not observed may result in a failed installation!

I'd want us to be very cautious to avoid something like the nearly unreadable fonts discussed in bug 743238. We must be able to read the text :^(

But one should be able to proceed with a "manual" installation (now called "something else") which assumes that the person installing knows what they are doing.

In other words, the installation should not be stopped for the lack of disc space anymore than for the lack of an internet connection.

Either Evan Dandrea or Colin Watson will need to make a decision regarding this.

Please see:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/766265/comments/23

I don't see why we can't treat this similar to the other two requirements (internet and power supply) with the caveat of offering only the manual partitioning option. With that being the only option offered there should be room to add an ample warning.

As I am not an ISO spinner, and I know the author of this one is busy in Real Life stuff. At least a pointer to whoever is eventually going to look at this may be found at https://help.ubuntu.com/community/Lubuntu/Documentation/FAQ#Lubuntu 11.04 will not install in less than 5.3 GB of disk space
From my contact with him, this was a simple fix and if times allows him, I'd ask that he be asked to provide the ubiquity team how he got round it. I know that, as per our Head of Devel, Ubiquity be allowed to ask itself "is this lubuntu" I feel that it should also ask if the other team releaes such as xubuntu and kubuntu be included. This would have the reverse option of "if NOT ubuntu, then...."

All I did for my low-disk-space ISO for Lubuntu 11.04 was to edit the file casper/filesystem.size to contain a number lower than the one that was there before. I then edited one line of the file containing md5sums, so that the Test CD Image menu item still works. No change to any code whatsoever was needed, just two text files in the ISO image.

This casper/filesystem.size file is supposed to contain (as a string of ASCII digits) the size in bytes of the filesystem needed for the installation, computed from the installed sizes of all the packages in the default install. What happened, as far as I can tell, is that Ubuntu 11.04 needed a lot of additional working free space, so someone came up with a quick fix and multiplied the value obtained from this file by a "fudge factor" in the ubiquity code. They then tested their change on Ubuntu (and only Ubuntu -- not Xubuntu or Lubuntu), and it worked for Ubuntu, so it was accepted!

In an ideal world, we should revert the "fudge factor" patch in the code, and allow the casper/filesystem.size file to contain the actual size of filesystem needed for a successful installation of whatever flavour of Ubuntu this image is. This is clean, elegant, and easy to understand. Provide the correct data to ubiquity, and it does the right thing.

In practice, I am not sure the Ubuntu folks will want to do that -- the way things are now works fine for them :)

There are many other practical ways to solve this, including code in ubiquity testing which Ubuntu flavour is being used, and setting the "fudge factor" accordingly, which is "ugly" but definitely workable. Other possibilities include a command line option to ubiquity that sets the fudge factor, or one that disables the disk space check, or (trying to avoid too many ugly fudge constants in the code!) looking for an optional file under casper/ that does one of those things and which is then present in Lubuntu ISO images but absent in Ubuntu ones...

In a related bug report (I think it started out satying teh Xubuntu web site had bad info about disk size needs, but was really this issue in disguise), a couple of months ago or more, I offered some time ago to implement one of these ways forward, if someone would tell me it would be accepted, but apparently no-one relevant read it or responded to me about it. Even though my work and real life time constraints are a lot worse now than they were then, that offer stands... I don't have time to discuss all the options, or write formal proposals and try to persuade a group of people to agree on one, etc... but tell me a patch to fix this in any of the ways I mentioned above will be accepted, and I'll happily create that patch and submit a debdiff or a bzr packaging branch containing it.

Jonathan

First of all I don't disagree with anything said here, but I do need to do a better job of explaining what I was trying to convey ;^)

In order to keep things as simple as possible when I refer to "free space" I actually mean "unallocated" or "unpartitioned" space on any disc, this could include any hard drive, flash drive, media card, etc.

Also when I refer to "automated install" I mean anything other than the use of "manual partitioning" which is now described as "something else: you can create or resize .......... or choose multiple partitions ........".

What I hope to convey is the reasoning for always displaying the manual partitioning option regardless of how much disc space is available, and regardless of whether it's free space or existing partitions. Currently Lubuntu requires approximately 2.3GB for / whereas Ubuntu requires about 3.2GB.

I'm unsure about Kubuntu and Xubuntu ATM, but with Kubuntu having proposed a KDE Lite version (actually referred to as "low-fat Kubuntu" when I read about it) I'll assume that all DE's can at least exist with no more than 4GB as /. If I'm mistaken please correct me.

Let's first consider that the automated install always creates a new swap partition, generally anywhere from the same size as RAM to double the size of RAM. I'm not sure how ubiquity calculates that but the two machines I commonly use to test with both have 2GB of RAM and I've had the automated installation create anywhere from just over 2GB of swap to as much as 3GB+.

That is where bug 782507 plays into the whole thing. So, if I were using the Lubuntu live CD, and I tried installing to a 4GB drive with either an existing swap partition, or if it were a blank drive (that is all free space), the installer would presumably still fail based on the amount of swap commonly created during an automated installation. (2.3GB for / + 2GB for swap)

To make things worse if the 4GB drive were completely unpartitioned, and was the only drive present, bug 766265 comes into play because the installation would just begin with no option to use the advanced partitioning tool :^(

I hope that's fairly clear. I see Colin Watson commented at bug 782507 which indicates that the devs are paying attention, so I hope I made it clear why always presenting the manual partitioning option is needed. In some cases it may need to be presented along with other automated install options, but in others it may need to be presented as the only option along with a stern warning.

Regardless I'm fairly certain that Lubuntu will have an alternate CD available by Oneiric final, so difficult installations can always be performed using it. I'll still bet Colin and Evan have a dartboard dedicated to me somewhere in the office ;^)

I hope all of the devs know I'm only trying to help. BTW the latest specs I'm aware of are here:

https://docs.google.com/View?id=dfkkjjcj_101gnkrpg5v#2.7.14

If I'm mistaken please let me know.

@lbsolost: You wrote:

> So, if I were using the Lubuntu live CD, and I tried installing to
> a 4GB drive with either an existing swap partition, or if it
> were a blank drive (that is all free space), the installer would
> presumably still fail ...

> If I'm mistaken please let me know.

OK... I think you are mistaken, at least in some cases :) The Lubuntu 11.04 LiveCD, with the one file hacked so the "limit" value is smaller, installs fine for me on a 3GB hard drive (virtual hard drive, in a VM). I don't remember the RAM size I had on that VM, probably 256MB or 512MB.

The problem I have with the idea of "just make all the tests into warnings" is that it could increase the number of unhelpful "bug reports" when newcomers do impractical things on inadequate hardware, and then blame Ubuntu! I suspect that preventing this was probably behind the "hard" limit for disk space that is currently implemented.

I am still very time limited, but will look into detecting the Ubuntu "flavour" being installed, and using it to decide what the size limit is, hopefully this weekend. That could be a quick fix that needs no UI changes, no extra files on the CD image, etc. My current thinking would be to use the current code for the "big boys" (Ubuntu and Kubuntu), and use a "casper/filesystem.size + offset" approach for Lubuntu and Xubuntu, with "offset" being of the order of 600MB. Any other flavours (new ones I don't know about?) should of course default to using the "very safe" approach that is currently in place.

Anyone with comments/suggestions/reasons why this is a terrible idea, please state them :)

The Lubuntu Oneiric Beta 1 live-i386 image now says only 3.9GB is required. I think the Ubuntu image says 4.4GB but I need to recheck that.

So I started the "automated" install (install alongside) where my blank 4GB flash drive was the only unpartitioned space available, and I have 2GB of RAM, so the installation stalls with the attached warning because it wants to create about 2GB of swap which leaves an insufficient amount of disc space for /.

IMHO that's actually OK though, because you're told that clicking on continue will result in failure, and if you click on back you end up in the manual partitioning screen.

Lubuntu now also has an alternate install image so I'd think we're OK here.

I have no 64bit hardware so I can't test the amd64 images.

Just checked to be sure my memory was correct and the Ubuntu Oneiric Beta 1 i386 image does require 4.4GB.

I see however that the alternate images passed iso-testing so I guess my feeling is that the d-i can be used in unusual installation scenarios.

Patch created that looks for the seed files lubuntu.seed and xubuntu.seed to decide
whether this is an Lubuntu or Xubuntu install. If either one is found, the " * 2"
fudge factor that Evan added is reverted, and instead the filesystem.size value is
used, plus 600MB so there is some free space to use.

Comments, and especially testing, welcomed :)

New bzr branch created with a package containing this fix, at

    http://bazaar.launchpad.net/~jmarsden/ubiquity/lp775124

Note: patch added to this bug may well have a spaces vs tabs issue,
the version in bzr has all spaces.

Merge proposal at

  https://code.launchpad.net/~jmarsden/ubiquity/lp775124/+merge/73963

The attachment "ubiquity-diskspace-needed.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

As discussed during the installer virtual sprint, one option is to establish a size whereby disks smaller than this should automatically override the space check, provided that they have enough space (plus a small amount) for the contents of the installation.

The rationale was that if a disk is smaller than the minimum size check but still large enough to hold the installation, we shouldn't get in the users way, provided that attempting the install wont hit -ENOSPC.

For what it's worth, the fudge factor is there not as a workaround, but because we do not want users creating an Ubuntu installation that is only just big enough to contain the system files. We should ensure they have enough room to be able to use the operating system, including storing documents, music, and downloads, for the life of the installation.

Indeed,

but, for example, 4GB SSD Drives are now inexpensive, and on some laptops.
I also recall the pleas for help with 2.3GB hell when the system just used
2.3GB and then left no room for user data! Can we find a 'middle' ground,
or are such people faced with alternate install only.

Regards,

Phill.

On 19 March 2012 15:08, Evan Dandrea <email address hidden> wrote:

> For what it's worth, the fudge factor is there not as a workaround, but
> because we do not want users creating an Ubuntu installation that is
> only just big enough to contain the system files. We should ensure they
> have enough room to be able to use the operating system, including
> storing documents, music, and downloads, for the life of the
> installation.
>
> --
> You received this bug notification because you are a member of Lubuntu
> Packages Team, which is subscribed to a duplicate bug report (819538).
> https://bugs.launchpad.net/bugs/775124
>
> Title:
> Ubiquity should have a command line option to override the free space
> check
>
> Status in “ubiquity” package in Ubuntu:
> Triaged
> Status in “ubiquity” source package in Oneiric:
> Won't Fix
> Status in “ubiquity” source package in Precise:
> Triaged
>
> Bug description:
> Binary package hint: ubiquity
>
> I downloaded the 11.04 desktop i386 iso, put it on a usb drive so i
> could it install it on my netbook, but couldnt even get past the
> install screen, because it says i need 4.4GB to install ubuntu 11.04.
> The problem is that my hard drive is only 4GB large, a common size in
> netbooks. I have run installers for ubuntu 10.10, 10.04, 9.10 and
> 9.04 netbook editions on my netbook and never had a problem before. I
> notice that 11.04 has netbook and desktop editions combined into a
> single ISO, so maybe that is why the error happened in 11.04 and not
> before.
>
> Also, I notice that the install footprint of 10.10 is around 2.1GB, so
> it shouldnt be a problem running 11.04 unless they truly added 2GB of
> junk to the OS. The problem is I just can't get past the installer.
>
> [i am intentionally posting a duplicate of bug
> https://bugs.launchpad.net/bugs/772164 because i can't change the package
> of
> bug https://bugs.launchpad.net/bugs/772164 to ubiquity from netbook]
>
> ProblemType: Bug
> DistroRelease: Ubuntu 11.04
> Package: ubiquity 2.6.10
> ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
> Uname: Linux 2.6.38-8-generic i686
> Architecture: i386
> Date: Sun May 1 20:24:28 2011
> LiveMediaBuild: Ubuntu 11.04 "Natty Narwhal" - Release i386 (20110427.1)
> ProcEnviron:
> LANGUAGE=en_US:en
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: ubiquity
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/775124/+subscriptions
>

--
https://wiki.ubuntu.com/phillw

On 03/19/2012 08:08 AM, Evan Dandrea wrote:

> For what it's worth, the fudge factor is there not as a workaround,
> but because we do not want users creating an Ubuntu installation that
> is only just big enough to contain the system files. We should ensure
> they have enough room to be able to use the operating system,
> including storing documents, music, and downloads, for the life of
> the installation.

How can we determine the amount of additional space this requires, for
any imaginable set of users on any imaginable computing device? How can
we compute the value of "enough room"? How do we know whether they will
use the machine mainly for writing text documents, or for storing and
editing large numbers of HD videos? We don't. Yet the users intended
use would have a huge impact on the correct value of "enough room".

The current approach of doubling the OS size is total overkill on
smaller single user systems (at least for users whose primary usage will
not be collecting videos!). This leads me to suspect that the concept
of a "factor" could be a problem. If, instead, "we" make it an offset
instead, say 500MBytes (which is a LOT of typing, for those who will use
their machine mostly for text documents!), that would be fine. An OS
needing up to 3.5GB of space for its default install would then be
permitted to install onto a 4GB SSD.

Is this (500Mbyte fixed size definition of "enough room") acceptable?

I would suggest that, because *any* factor or offset will be a guess
based on an unreliable estimate of their intended use of the machine,
there should be a way for the installing user to override this "enough
room warning" and proceed with the installation "at their own risk".

SUMMARY:

Please can "we": (1) make this freespace check into a warning, not an
absolute installation stopper and (2) set the value of "enough room" to
a fixed 500MB, not to a factor of the size of the OS?

Jonathan

P.S Unreliable guesstimate of space usage for text creation: One user
typing at 60wpm (average 5 chars per word and a space) typing 8
hours/day 5 days/week 50 weeks/year for 10 year lifetime of machine:

  60 * 6 * 60 * 8 * 5 * 50 * 10 = 432000000

So, under 500MB ... and most machines don't have a ten year lifetime :)

I still rather like the idea of always letting the manual partitioning option (now referred to as "Something else") proceed under any circumstances. I mean we have to assume that someone using a manual partitioning option has some knowledge of what they're doing.

I also realize that's not always the case because I've seen some pretty strange partitioning arrangements in the past (like a huge / or /boot with a tiny /home) but it's impossible to make things totally fool-proof.

ubuntu-12.04-beta2-desktop-i386.iso install no go and the block of code I use to edit /usr/lib/ubiquity/plugins/ubi-prepare.py is gone. :( The file is there, just not the same block of code.

Asus 900 4GB internal SSD. <-- / goes here and /home --> 4GB external.

I just had the same problem with lubuntu-12.04-beta2-desktop-i386.iso, so I created a USB installer from the iso, edited casper/filesystem.size to say 1800000000 and changed the md5sum.txt file to reflect this change (as mentioned in post #12). Inserted the USB into my 4GB eee-pc and now it works (only requires 3.6GB).

I'm glad Kees was able to do what I did almost a year ago, and am happy it still works.

I'm sad we seem to have made no actual progress on this issue in that year!

At this late stage in Precise, I care more that *a* solution allowing installation of Lubuntu 12.04 from the normal official LiveCD installer image onto a 4GB SSD is created and tested, than about what solution we use.

So, if that means agreeing to Evan Dandrea's concept of "disks smaller than X but bigger than "size of distro + Y" can always be installed onto, then OK.

I propose:

  "All disks smaller than 64GB but bigger than "size of distro" + 250MB should always be allowed to be installed onto"

Is that workable? Can Evan or others with official Ubuntu credentials get such a patch into Ubiquity in time for 12.04?

Thanks,

Jonathan

There is a very simple workaround, that works automatically. I used an 8GB USB-stick to install Lubuntu on my netbook with only 4GB space. The requirement of 4.4 GB disk space was okayed automatically. I assume that there is a second bug (PLEASE don' t fix that one!) that lets the install script look at all the available drives, including the USB-drive from which you install!

But it took me ages to get past the partitioning screen. I do not want a swap drive, because I checked regularly if it was being used, and this was NEVER the case.
Now, default *buntu will create a swap drive the size of the internal memory, In my case 1GB. That would leave me with just 3GB of disk space for Lubuntu, and 1GB of NEVER USED swap drive. It really is a hell of a job at the moment to prevent the creation of a swap drive, whatever your own opinion on this.
My suggeston is to add just one question in the install script: "Do you want to create a swap drive". If the answer is "No" please leave the person who installs Lubuntu in peace and respect his choice.
IMHO a swap drive is a hobby of early Linux users, who used computers with low internal memory. The days to create a swap drive by default should long be over now! I do not need it on my low resources netbook with 1GB memory.

I went to install 12.04 on my 4gb netbook. First I had to edit
/usr/lib/ubiquity/plugins/misc.py to override the space check, next I ran out of space. Do you know why I ran out of space? because 12.04 automatically partitioned 2GB of swap (i had 2GB of ram). Next attempt I manually partitioned 500MB of swap, and then I was able to install. Still, I was surprised that 12.04 has regressed in that:
1) the bug I reported here 1 year ago to overide the space check was not addressed, and
2) It was not netbook aware in its automatic partitioning.

Previous versions of ubuntu installed on a netbook would automatically do 500MB for swap. I guess Ubuntu is linux for "new hardware" (not linux for human beings). As I sidenote, the netbook I bought from dell had ubuntu 9.04 pre-installed on it.

Stumbled on the issue yesterday and worked around the problem using marker's fix (many thanks to you!). Note that the file to mod is /usr/lib/ubiquity/ubiquity/misc.py , not /usr/lib/ubiquity/plugins/misc.py, as can be seen at http://packages.ubuntu.com/precise/amd64/ubiquity/filelist).

I hope this bug can get solved in the end. The best solution for me would be to have a simple way of bypassing the check, as is done for instance for swap space (where the installer warns that you might get into trouble but nevertheless allows you to continue).

I wanted to install Lubuntu 12.10 to a 4GB USB flash drive, but the 12.10 installer refuses to work if the disk size is less than 4.4GB. That's a problem because Lubuntu would actually install fine on a 4GB USB drive, especially if the user chooses to not create a swap partition. But the installer doesn't let the user get past the "I won't install on a <4.4GB disk" stage.

It's perfectly feasible to install Lubuntu to a 4GB flash drive; there would about 2GB free space after installation with no swap partition.

Some suggestions:
 - Reduce the minimum allowable disk size and make it a recommendation, not mandatory.
 - When working out whether the drive is large enough for Lubuntu to be installed, take into account the size of any swap partition. Perhaps show a warning dialog if the user proceeds with a small drive, but don't prevent installation completely.

Here are some space-used figures after I installed Lubuntu 12.10 to a 4.4GB VirtualBox VM:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 3766504 1911200 1663972 54% /

Device Start End Blocks Id System
/dev/sda1 2048 7655423 3826688 83 Linux
/dev/sda2 7657470 9226239 784385 5 Extended
/dev/sda5 7657472 9226239 784384 82 Linux swap / Solaris

Note the swap size! With no swap partition there would be almost 2.5GB of free space. There would therefore be over 2GB of free space after installing to a 4GB USB stick/memory card, if the installer allowed it. That's plenty for light usage.

This bug is still present with the Lubuntu 13.04 beta 1 installer. Sigh. :(

On 14.04 the workaround:

Quit the installer to go to the LiveCD desktop. Press alt+f2 and type:

gksu gedit /usr/lib/ubiquity/plugins/ubi-prepare.py

Edit line 53 and change False to True:

self.controller.allow_go_forward(True)

Continue with your install. Of course you should create separate mount points for /home and /var if you have multiple disks (like on EEEPC) so that you don't run out of space and / has enough to run.

- Link Swanson

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release