Page MenuHomeLubuntu Development

Erase Disk fails with existing partition scheme
Closed, ResolvedPublic


This is an absolutely critical thing for us to resolve in some way or another for 20.04.

tl;dr, if there's an existing partition scheme, the Erase Disk option will fail trying to create the new partition table. See Launchpad bug.

If we have to, we may be able to work around this with a shellprocess doing one of two things after somehow detecting that Erase Disk has been chosen:

  1. Temporarily moving/renaming os-prober after the partition selection and reverting it at the end.
  2. Arguably more dangerous and would require us knowing the target device: checking for an existing partition table and removing it before the installation process starts.

Hopefully upstream gets to it first.

Event Timeline

wxl triaged this task as Unbreak Now! priority.Feb 9 2020, 11:12 PM
wxl created this task.
wxl added a parent task: T100: Lubuntu 20.04.

Although I find it really circumstantial and fails to explain why we suddenly had this problem nor why renaming os-prober seems to work around the issue, upstream sees the problem to be the way we're calling things. Apparently just running sudo calamares "solves" the problem and while I'm skeptical of that, it does seem to work. Subsequently, upstream has changed the docs to reflect this fact.

So edit the desktop file to change the exec to call some script, let's say /home/lubuntu/script then create that file, make it executable and replace it with:

#!/usr/bin/env bash

export BROWSER='sudo -H -u lubuntu firefox'
sudo -E calamares

Then run the desktop file and see what happens.

You could also just change the Exec key back to sudo -E calamares (or just run that in terminal) but the links (e.g. donate, support, etc) on the welcome page won't work.

@guiverc including you here because I know you've experienced this.

Nevermind the above, I got it to fail anyways.

So crazy scripted the installs and had failures both ways but had less failures with the script. It seems more appropriate to do things that way, anyways. Someone want to drum that up?

Just tagging @Leok on this one since he discovered the issue originally.

Upstream indicates the new version fixes some of this issue. I have packaged the new version and uploaded. I think we should also incorporate the startup shell script but that needs to go in cala settings.

And now we have a new upstream bug linked. tl;dr it's calling the wrong path to udevadm.

wxl claimed this task.

Finally resolved in