(Virtualbox) Installing with no swap partition results in corrupted system, despite having high RAM

Bug #1615363 reported by mnader on 2016-08-21
32
This bug affects 11 people
Affects Status Importance Assigned to Milestone
virtualbox (Ubuntu)
High
Unassigned

Bug Description

Image: ubuntu-mate-16.04.1-desktop-amd64.iso

DISCLAIMER: I did this in a Virtualbox VM (5.1.2, and then tried 5.1.4) with 2GB of RAM running on a Windows 8.1 64-bit host. I am not able to test this natively, due to lack of appropriate hardware, but I don't think it matters that it's in a VM.

Reproduction steps:
1) Create a VirtualBox VM with standard options. Change RAM to 2GB. Set network cable to unplugged (doesn't affect reproduction, but will make the process faster)
2) Start the installer, and select "Install Ubuntu MATE". Go through default options, except when specified.
3) At the Installation Type step (partition dialog), select Something Else
4) Configure a single partition table with a single primary/logical partition mounted on root (ie the default settings), then select Install Now. Accept the warning saying you have not selected any swap space. Write the changes to disk, and proceed.
5) When installation has completed, reboot the system as instructed
6) When the system boots, you will get completely corrupted (see attachment mate-corrupted-graphics.png)

Observations:
-If I install and use the default partitioning scheme ("Erase disk and install Ubuntu MATE"), which does contain a swap partition, then the OS boots just fine
-If I select "Try Ubuntu MATE" during install, I get a working, high-res desktop

mnader (mnader-mtl) wrote :
summary: - Installing with no swap partition results in corrupted system, despite
- having high RAM
+ (Virtualbox) Installing with no swap partition results in corrupted
+ system, despite having high RAM
description: updated
mnader (mnader-mtl) on 2016-08-21
description: updated
description: updated

I reproduced this in Virtualbox using a Ubuntu MATE 16.04 LTS host:

Same iso: ubuntu-mate-16.04.1-desktop-amd64.iso
Same VM settings: 2GB RAM, No network connector.
Same partition layout: no swap, only "/" partition using entire 16GB dynamic size disk

ouroumov@Box:~/Desktop$ apt-cache policy virtualbox
virtualbox:
  Installed: 5.0.18-dfsg-2build1
  Candidate: 5.0.24-dfsg-0ubuntu1.16.04.1
  Version table:
     5.0.24-dfsg-0ubuntu1.16.04.1 500
        500 http://fr.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 Packages
 *** 5.0.18-dfsg-2build1 500
        500 http://fr.archive.ubuntu.com/ubuntu xenial/multiverse amd64 Packages
        100 /var/lib/dpkg/status

See attachment for graphics bug screenshot.

Note: Switching to tty1 using (left control key + F1) then using "sudo systemctl restart lightdm.service" allows me to work around this issue and lands me on the correct login screen.

Mario Figueiredo (marfig) wrote :

Can't reproduce in Virtual Box 5.0.26 using the pre-point-release image:

iso: ubuntu-mate-16.04-desktop-amd64.iso
VM settings: 1.7GB, no network connection, PAE/PX enabled on processor
Partition: no swap, full primary / partition (13GB)

no longer affects: ubuntu-mate

I was not able to reproduce this on metal.
I tried using ubuntu-mate-16.04.1-desktop-i386.iso on a 32 Bit machine and using the ubuntu-mate-16.04.1-desktop-amd64.iso on a 64Bit machine.

Looks like the issue is limited to installations inside VirtualBox.

Alistair Buxton (a-j-buxton) wrote :

I reproduced this in VirtualBox on 16.04 host using ubuntu-16.04.1-desktop-amd64.iso and ubuntu-mate-16.04.1-desktop-amd64.iso

Easy workaround: press right-ctrl F1, right-ctrl F7.

Alistair Buxton (a-j-buxton) wrote :

Interesting discovery:

I reinstalled and told the installer to make a swap partition. As expected the bug did not occur when I booted.

Next I deleted the swap partition with fdisk and rebooted. This caused systemd to wait for 1 minute 30 seconds during boot. The bug did not happen.

Next I removed the swap partition definition from /etc/fstab and rebooted. systemd did not wait during boot, and the bug happened.

Therefore this looks like a race condition.

Launchpad Janitor (janitor) wrote :

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

Changed in virtualbox (Ubuntu):
status: New → Confirmed
Changed in virtualbox (Ubuntu):
importance: Undecided → High
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:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1615363

tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers