Huge number of installation issues

[khanson679]

First, the results of the physical install.

Background:
- Using a 2015 Lenovo X250, with a Core-i5 5200U, 4 GB RAM, 240GB SSD (OS), and 500GB HDD (data)
- Burned live DVD to an very fast flash drive, a SanDisk Extreme.
- Mint 17.3 is installed on separate root and home partitions, and Kubuntu 16.04 beta will be installed likewise (partitioned in advance).
- Was not at home, so tethered to Android phone for internet. Consequently, I left checkbox for updating packages unchecked. Also did not install 3rd party packages

Results follow.

Same lag at the beginning of the install process. (!)

Starts to download language packs (!), then other unidentified packages (!!!).
- I did not expect the installer to download a bunch of surprise data with updates and 3rd party packages disabled. What on earth is it downloading when my language is American English and I'm using the English live DVD??
- "Copying files" begins after a while and proceeds very slowly, then downloads resume.
- After 250mb of downloaded data as identified on my phone and no end in sight, I forcibly ended the installation.
- I tried again with the debug log enabled, but couldn't figure out what it was downloading, only that updates were indeed disabled.

Tried again from the beginning. Restarted the live system and disabled the network connection before starting installation.
- This time installation went without a hitch and was blazingly fast, as it should have been considering the source and target disks.

Plasma also crashed at some point in there, so it definitely is not just flaky in VMs. I haven't spent much time running 16.04 yet, but I also have Plasma 5.5 in Kubuntu 15.10 (via the Kubuntu updates PPA) and that rarely crashes, so I'm increasing suspicious that the live system is at fault.

[khanson679]

Now for the VM tests I've completed. At first, using same VM as before (2 core, 1 GB, boot/root/home partitions), and still disabling Akonadi before starting installation.

1. Don't install updates, disabled network connection after starting installer (because I had forgotten to do it beforehand).
- No change from earlier VM experience. Extremely long lag, as before. Aborted and restarted.

2. Don't install updates, disable network before starting installer.
- Lag at beginning of unpacking disappears, and installation (unpacking and configuration) proceeds to completion at a normal pace, comparable with VM installations I've done in the past.

So it seems that the installer tries to download the language packs and mystery packages if it thinks it has a network connection (though it isn't terribly smart about checking this once you've started), and this is the root of the bad behavior.

From here I started to change up some variables with the VM configuration, both to confirm the above and also to see if anything else changes.

3. Disabled swap space, and erased the partition table on the install disk, then did guided installation, simulating a completely fresh install. Still disabling Akonadi, but now leaving network enabled. Now things get interesting.
- I discovered that the installer activates the new swap partition for use during installation. This explains a lot about my experience with manual partitioning -- this way there can be no trouble disabling an existing swap partition, and the formatting step allocates a full 1GB, giving the installer plenty of leeway.
- No lag before "copying files", which proceeds smoothly as in the last test. But then it begins the downloading of mystery files and language packs, which takes an absurdly long time as with the previous VM test (on a desktop connected to ~30mbps DSL via ethernet) and on the laptop (over cellular HSPA).
- System monitor in both the host and VM showed very little network utilization during much of this, but it's worth noting that I almost never have internet problems on these connections.
- One thing that I did differently that I only realized afterward: I had let the "copying files" complete before I finished the last configuration screen. Commentary below.

At this point it seems that the installer can perform (a) unpacking from the install disk and (b) the problematic downloads in a variable order, and will do the unpacking first if it decides it's ready before the user has entered all the settings. Alternatively, doing the guided installation might have caused the ordering to change. Since this is the first time I've done guided, I can't really say.

In either case, I think this at least confirms that the download process in the broadest sense (prep, language packs, mystery files, configuration) is the problem, because when it was either circumvented (by disabling the network) or delayed (as in test #3 here), everything goes very smoothly.

This is as far as I've gotten. At a minimum, I'd like to do see if I can reproduce test #3's results with manual partitioning, and test with Akonadi left on, to confirm that memory/disk size and partitioning are not the root of the issue, but rather the behavior of the installer, which I think is very bad, more so in this way than any other.

I'd be curious to know if anyone has heard of this or similar problems, either in Kubuntu 16.04, older versions, or other Ubuntu editions.

[mparillo]

It already sounds to me as if this is more likely to be core ubiquity behavior than kubuntu, but once you think you have it narrowed down, I would ping cjwatson on IRC:
https://webchat.freenode.net/?channels=#ubuntu
And he could probably point you to the correct component for a bug report.

But if I had to guess, I would post your bug report here: https://bugs.launchpad.net/ubuntu/+s...quity/+filebug