Inconsistent behaviour between 2 ways of launching Ubiquity

[Dariusz Gadomski]

I need to perform a partially automated installation of a desktop Ubuntu trusty. The partitioning part should be fully automated creating a entire-disk encrypted lvm.

While debugging my preseeding script I have encountered an inconsisted behaviour of ubiquity.

In both cases I use the same image of desktop CD with a preseed file added to the CD.

Scenario 1:
1. Launch desktop live CD
2. Select "Try Ubuntu"
3. Load my preseed file with:
# debconf-set-selections /cdrom/preseed/ubuntu2.seed
4. Start ubiquity:
# ubiquity -d --automatic
5. Select language
6. Continue after the internet connection check and drive space check.

With Secnario 1 everything works fine - the partitioning is fully automated.

Scenario 2:
1. Boot a customized entry in isolinux/txt.cfg passing the preseed file in the kernel command line
label live-install-test
  menu label ^Install Ubuntu (test)
  kernel /casper/vmlinuz.efi
  append debug-ubiquity file=/cdrom/preseed/ubuntu2.seed boot=casper only-ubiquity initrd=/casper/initrd.lz quiet splash
2. Select language
3. Continue after the internet connection check and drive space check.

With Scenario 2 I'm getting an error dialog:
"No modifications can be made to the device Encrypted volume (sda5_crypt) for the following reasons: In use by LVM volume group ubuntu-vg."

Please find the provided preseed files and the logs from the failing case.

Note: this contains a patch included in #1386113 to get pass the keyfile generation error.

[Colin Watson (cjwatson)]

I *think* that this has not much to do with the different ways you're launching ubiquity - the debug log shows that the preseed file has definitely been applied successfully by casper - and a lot to do with the second scenario having been run after the first on a disk that's no longer blank. lvm2's udev rules are going to have brought up all the LVM volumes they can find on the system, and nothing in ubiquity takes care to bring them down again before partitioning. (Of course it's also possible that there's some kind of race that means the two ways of starting ubiquity behave a bit differently, but it doesn't look like anything very fundamental.)

Try something like this as a workaround?

  d-i partman/early_command string vgchange -a n

[Dariusz Gadomski (dgadomski)]

Colin, thanks for the hint.

I have made sure that the disk is clear (all partitions erased, no VGs or LVs present) before running scenario 2.

Unfortunately the workaround did not change the outcome.

[Dariusz Gadomski (dgadomski)]

syslog from the 2nd attempt (with workaround).

[Dariusz Gadomski (dgadomski)]

/var/log/installer/debug from the 2nd attempt (with workaround).

[Dariusz Gadomski (dgadomski)]

There is a line in the syslog:
> Dec 17 18:00:28 ubuntu log-output: No volume groups found

and then a couple of seconds later:
> Dec 17 18:00:39 ubuntu partman-lvm: Physical volume "/dev/mapper/sda5_crypt" successfully created
> Dec 17 18:00:39 ubuntu partman-lvm: Volume group "crypt" successfully created
> Dec 17 18:00:39 ubuntu partman-lvm: Logical volume "root" created
> Dec 17 18:00:39 ubuntu partman-lvm: Logical volume "swap_1" created

so clearly there is a race of some kind present during the installation, but I have no idea what causes it.

[Dariusz Gadomski (dgadomski)]

syslog with set -x added to partman-base/choose_partition/partition_tree/do_option

[Mathieu Trudel-Lapierre (cyphermox)]

I've been testing this in qemu, with two different virtual machines (built with the same default settings), one doing Scenario 1, then Scenario 2, one the other way around.

I'm using the same preseed; with the exception that "d-i partman-auto/choose_recipe select boot-crypto" is commented out (it shouldn't be necessary, but I also testing without commenting it), and using /dev/vda rather than /dev/sda as a target device.

I'm unable to get precisely the message "No modifications can be made to the device Encrypted volume (sda5_crypt) for the following reasons: In use by LVM volume group ubuntu-vg." when installing with scenario 2 if I follow your steps precisely. I do get a message about creating the key file, followed by a "An error occurred while configuring encrypted volumes. The configuration has been aborted.". I am then left at the partman dialog. In indeed appears to happen independently of any previous installation artefacts on the disk.

However, if I re-run the same installer step for Scenario 2 (ie. fully automated), but with the addition of "automatic-ubiquity" which behaves the same as passing --automatic to ubiquity in Scenario 1, then the installation completes successfully.

Could you please try again, with adding 'automatic-ubiquity' for scenario 2; and report here whether it solves the problem?

Thanks!

[Mathieu Trudel-Lapierre (cyphermox)]

I should have mentioned, my tests were run with ubuntu-14.04.1-desktop-amd64.iso; so it was also for a Trusty desktop installation.

[Dariusz Gadomski (dgadomski)]

Mathieu: I forgot to mention it in the descripiton. To observe this problem you first need to apply Colin's patch for bug #1386113 (https://launchpadlibrarian.net/188412508/fix-keyfile-error.patch).

Thanks for looking at this!

[Launchpad Janitor (janitor)]

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]