partman-auto prefers to give disk to swap, leaving root too small

Bug #1351267 reported by Matthew on 2014-08-01
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
partman-auto (Ubuntu)
Critical
Dimitri John Ledkov
Xenial
Critical
Dimitri John Ledkov

Bug Description

[Impact]

 * Impossible to perform guided LVM installation, with an all-in-one configuration out of the box, on high-memory systems. High-memory systems are systems that have RAM on par, or more than, disk space. E.g. 8GB RAM with 8GB disk space, or 1TB RAM with 256GB hard drive.

[Test Case]

 * Start d-i installer
 * Select Use entire disk & setup LVM
 * Select drive to use, which is on par, or less then total RAM on the system
 * Select all in one / atomic partition recipe
 * Install should succeed, with no more than 2GB of swap partition / volume

[Regression Potential]

 * SWAP partition or LVM volume is typically calculated as a percentage of RAM - between 100% and 200% of RAM. Yet, this assumes that RAM is significantly less than total disk space, and thus on high-memory systems results in badly setup systems with too small rootfs, and too much swap.

[Other Info]

 * Original bug report

I was trying to install Ubuntu 14.04.1 LTS on an Oracle VirtualBox VM with 6.5GB of RAM and 8GB (default for a new Virtual HDD on VirtualBox) of disk space.

I selected the option "Erase disk and install Ubuntu" (and post crash "Erase Ubuntu 14.04.1 LTS and reinstall") and let it use the defaults.

The installer gives the error:

 "Some of the partitions you created are too small. Please make the following partitions at least this large:

 / 3.4 GB

 If you do not go back to the partitioner and increase the size of these partitions, the installation may fail."

The message is very confusing to a new user who did not specify any partition sizes themselves.

The installer created a 6GB Swap partition on the 8GB drive. The installer then could not install to the root partition and failed midway:

"The installer encountered an error copying files to the hard disk:

[Errno 28] No space left on device

This is due to there being insufficient disk space for the install to complete on the target partition. Please run the installer again and select a larger partition to install into."

..then a box appears stating that the installer has crashed:

"Installer crashed

We're sorry; the installer crashed. After you close this window, we'll allow you to file a bug report using the integrated bug reporting tool. This will gather information about your system and your installation process. The details will be sent to our bug tracker and a developer will attend to the problem as soon as possible."

The box cannot be closed. No bug reporting tool launches. The computer requires restarting to become usable again.

Please let me know if you need any more information as this is my first bug report.

Thanks for your time,
Matthew

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed

i was having the same message issue when reinstalling ubuntu 14_04 EFI 64bits
then after debugging a while,

on installation, it was saying to put the /boot partition to 15,9 mb. I was putting 16mb and it wasnt enough...

on terminal of livecd installing i ran: df -h and found the problem:

/dev/sda6 15M 15M 0 100% /target/boot

changing it /boot to 20mb solved the problem.

I mean, 100 mb. To be safe, i put finally 400mb.

Phillip Susi (psusi) on 2014-10-24
affects: ubiquity (Ubuntu) → partman-auto (Ubuntu)
summary: - Installer Crashes With Large Memory And Small Disk
+ partman-auto prefers to give disk to swap, leaving root too small
Changed in partman-auto (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
dann frazier (dannf) wrote :

This is no longer an issue post-xenial, since we now default to swap files.
For xenial, a low-touch solution might be to just cap the minimum swap size at 2G, as per this attached patch.

Changed in partman-auto (Ubuntu Xenial):
status: New → In Progress
assignee: nobody → dann frazier (dannf)
importance: Undecided → Medium
dann frazier (dannf) wrote :

I've tested 3 cases so far in QEMU, using the installer here:
http://ppa.launchpad.net/dannf/diswap/ubuntu/dists/xenial/main/installer-arm64/20101020ubuntu451.20+capminswap.1/
(Sorry it's arm64 only - the amd64 one FTBFS for an unrelated issue)

All tests are with the "All files in one partition" option, whose recipe is configured to use a min of 100% RAM.

80G disk, 2048M RAM
 - 2G swap
80G disk, 1024 RAM
 - 944.8MB swap
20G disk / 30000M RAM
 - No "All files in one partition" option presented (can't meet the min)

tags: added: patch
Dimitri John Ledkov (xnox) wrote :

The patch proposed is good, but is incomplete. Our default recipe, takes between 100% and 200% of ram, with a default suggestion of 512M. However only the min boundary is updated, but not the max one.

Imho, instead of capping min/max calculations, they should be left as is. Instead, we should cap as to what we consider to be 100%, aka cap the RAM calculation to 1GB, to thus have swap file between total RAM and 2GB, with no more than 2GB.

And imho it should be a question if we cap the RAM or not, with an option to pressed unlimited. Will implement this shortly, based on the partman-swapfile code.

And thus 20G disk / 30000M RAM -> should work and install correctly.

Changed in partman-auto (Ubuntu Xenial):
assignee: dann frazier (dannf) → Dimitri John Ledkov (xnox)
milestone: none → ubuntu-16.04.4
importance: Medium → Critical
description: updated
Changed in partman-auto (Ubuntu):
importance: Medium → Critical
assignee: nobody → Dimitri John Ledkov (xnox)
milestone: none → ubuntu-18.02
Łukasz Zemczak (sil2100) wrote :

This has been accepted and needs verification (the script failed while writing the bug info).

Changed in partman-auto (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-xenial
Changed in partman-auto (Ubuntu):
status: Triaged → Fix Released
status: Fix Released → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-auto - 134ubuntu8

---------------
partman-auto (134ubuntu8) bionic; urgency=medium

  * Introduce partman-auto/cap-ram, to allow capping RAM size as used for
    swap partition calculations. This allows us to effectively cap the
    swap partitions size to maximum of 2*CAP. Default is set to 1024, thus
    capping swap partitions to 2GB maximum. LP: #1351267

 -- Dimitri John Ledkov <email address hidden> Fri, 23 Feb 2018 13:53:15 +0000

Changed in partman-auto (Ubuntu):
status: Fix Committed → Fix Released
Dimitri John Ledkov (xnox) wrote :

Using netboot installer, with apt-setup/proposed=true boot command line, I have verified that partman-auto 134ubuntu1.2 is getting pulled into the install.

The VM has 8GB ram, and 8GB hard drive.

At the partitioning disks screen, I selected "Guided - use entire disk and set up LVM" and continued the installation.

The install was successful, resulting in a 1GB swap volume.

tags: added: verification-done verification-done-xenial
removed: verification-needed verification-needed-xenial
dann frazier (dannf) wrote :

Netboot installer here as well, with apt-setup/proposed=true boot command line and verified partman-auto_134ubuntu1.2 is getting pulled in.

On an arm64 system, with a 240.1 GB disk and 256 GiB of memory, "Guided - use entire disk" proposes a 1GB partition:

  │ SCSI8 (0,0,0) (sdm) - 240.1 GB ATA INTEL SSDSC2BB24 ▒ │
  │ > 1.0 MB FREE SPACE ▒ │
  │ > #1 536.9 MB B F ESP ▒ │
  │ > #2 238.5 GB f ext4 / ▒ │
  │ > #3 1.0 GB f swap swap ▒ │
  │ > 597.5 kB FREE SPACE ▒ │

I expected this scenario to propose a 2GB swap, since there's plenty of disk space. I don't feel strongly about 2GB vs 1GB though so, assuming this is by design, works for me.

Also a 1GB swap on the same system with a 15.5GB disk:

  │ SCSI3 (0,0,0) (sdb) - 15.5 GB ADATA USB Flash Drive │
  │ > 1.0 MB FREE SPACE ▒ │
  │ > #1 536.9 MB B F ESP ▒ │
  │ > #2 14.0 GB F ext4 / │
  │ > #3 1.0 GB F swap swap ▒ │
  │ > 507.4 kB FREE SPACE ▒ │

Finally, with "Use entire disk and set up LVM", I also see 1 GB swap on the larger disk:

  │ LVM VG starbuck-vg, LV root - 238.0 GB Linux device-mapper (linea │
  │ > #1 238.0 GB K ext4 / ▒ │
  │ LVM VG starbuck-vg, LV swap_1 - 1.0 GB Linux device-mapper (linea ▒ │
  │ > #1 1.0 GB K swap swap ▒ │

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-auto - 134ubuntu1.2

---------------
partman-auto (134ubuntu1.2) xenial; urgency=medium

  * Introduce partman-auto/cap-ram, to allow capping RAM size as used for
    swap partition calculations. This allows us to effectively cap the
    swap partitions size to maximum of 2*CAP. Default is set to 1024, thus
    capping swap partitions to 2GB maximum. LP: #1351267

 -- Dimitri John Ledkov <email address hidden> Fri, 23 Feb 2018 16:59:11 +0000

Changed in partman-auto (Ubuntu Xenial):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for partman-auto has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

dragon788 (dragon788) wrote :

Did this somehow get enabled by default? There is a recently opened issue where on 18.04 a previously working preseed with the partman-auto/recipe select atomic is creating a tiny 1GB swap on systems with 16GB-32GB of RAM, preventing the ability to hibernate.

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1767299

phanky5 (phanky5) wrote :

I find it a very questionable decision to release an installer that focuses on uncommon high-memory systems while the average user is screwed over with a way too low swap partition. It should be the other way around: Normal setups should take precedence over unusual high-memory setups.

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

Other bug subscribers