[Bug 1796037] Re: [QEMU] When loading partman step, GNOME Shell vanishes, no more decoration and installer UI frozen

Didier Roche didrocks at ubuntu.com
Mon Oct 8 07:40:15 UTC 2018


Ah, interesting. I just checked cosmic GNOME Boxes configuration for an
ubuntu iso, and indeed, it configures 1GB of RAM. I think it used to
configure more? Maybe something we should change in GNOME Boxes upstream
so that people testing ubuntu aren't imapcted by it?

I don't know how Iain saw loop0/unsquahfs/snapd spiking in top as my VM
is exhausting its memory so quickly that I can't even do a vt switch.

However, I confirming that masking the snapd related services works.
I suggest there are 2 things to do:
* Having ubiquity warning if memory is under the memory spec (as the page was removed, I think it would dbe something for the new installer)
* Fixing GNOME Boxes default configuration for ubuntu to use 1.5/2GB (?) by default.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1796037

Title:
  [QEMU] When loading partman step, GNOME Shell vanishes, no more
  decoration and installer UI frozen

Status in ubiquity package in Ubuntu:
  New

Bug description:
  Following "Install (entire disk) in Ubuntu Desktop amd64 in Cosmic
  Daily" test case, on 20181003.1 desktop live image.

  Using Qemu (host is an up to date cosmic) and starting in ubiquity-only mode:
  - when clicking on continue on the <…> step, the UI is freezing for a minute, then GNOME Shell vanishes, no more decoration to ubiquity windows, black background (reproduced twice). See attached picture.
  - I was still able to proceed thus, but on the "who are you" page, no more control, the cursor is changing on text element to show the text cursor, but no caret.
  - no crash found in /var/crash, but the GNOME Shell process is marked as defunct.

  Can anyone reproduce it? I was able to reliably reproduce it on 3
  consecutive boots here.

  Note: there is also the fact that if I set focus to another window
  than qemu and going back to the qemu window, no way to type/click in
  ubiquity or live session. This may have an impact above on the cursor
  issue. Nevertheless, I have took great care to not change focus in the
  above use case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1796037/+subscriptions



More information about the foundations-bugs mailing list