Ubiquity takes a very long (>20 minutes) time to remove langpacks on the Edubuntu image

Bug #667243 reported by Stéphane Graber on 2010-10-27
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Canonical Foundations Team
Canonical Foundations Team

Bug Description

Binary package hint: ubiquity

As discussed at UDS, ubiquity takes over 20 minutes removing language packs and fonts from a standard Edubuntu install.
In comparison, on the same machine, the actual install part of ubiquity usually takes less than 15 minutes.

The dpkg log can be found here: http://www.stgraber.org/download/dpkg-maverick-edubuntu.log

Stéphane Graber (stgraber) wrote :

Moving importance to high as it's one of the main goals for Edubuntu 11.04.
Marking as incomplete as i (or someone else) still need to provide a debug log (ubiquity -d) so we can check what's exactly happening with the blacklist.

Changed in ubiquity (Ubuntu):
importance: Undecided → High
status: New → Incomplete
assignee: nobody → Stéphane Graber (stgraber)
Jonathan Carter (jonathan) wrote :

I performed an installation in debug mode, log attached.

Changed in ubiquity (Ubuntu):
status: Incomplete → Confirmed
Jonathan Carter (jonathan) wrote :

Attached is the syslog from the debug mode installation

Stéphane Graber (stgraber) wrote :

Evan, here's the two log files in debug mode you requested at UDS.
I can't find any clear mention to the blacklist in there.

I marked the bug as triaged and high as it's targeted for Edubuntu alpha-1 on our roadmap and it's causing a 20 minutes increase in install time.

Please let me know if you need any more information.


Changed in ubiquity (Ubuntu):
status: Confirmed → Triaged
milestone: none → natty-alpha-1
assignee: Stéphane Graber (stgraber) → nobody
Changed in ubiquity (Ubuntu Natty):
milestone: natty-alpha-1 → none
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Colin Watson (cjwatson) wrote :

Unfortunately, I'm not actually seeing anything obvious that ubiquity is doing wrong, but merely an accumulation of little things. The blacklist is operating fine (look for "Not copying" lines in syslog). What the blacklist does is to avoid copying certain files when it knows that the package is going to be removed anyway, so it speeds up the file-copying phase substantially but doesn't help (much) with the package removal phase.

I've only done eyeball inspection so far rather than anything systematic, but the only specific things I've seen beyond sheer volume of packages are:

 * Some font packages cause roughly ten seconds per package of updating the fontconfig cache. Some don't. I think the ones that do are those that still use defoma.
 * There's an odd minute of inactivity after removing xfsprogs. Stéphane's dpkg.log shows lots of "status installed" lines, i.e. calls to modstatdb_note. I don't know quite what's going on here. This seems to be essentially just dpkg checking the status of all the packages it's about to remove, but why is it taking so long?

A hack does come to mind where we take special care when copying /var/lib/dpkg/status to ensure that blacklisted packages are not even registered as installed after copying. However, I'd be worried about that leading to subtle inconsistencies.

The obvious thing to consider here is whether it's really worth you having all of these language packs and such on the live filesystem on your DVD, or whether it would make sense to have most of the packages as .debs on the DVD instead. The latter would be much quicker.

Jonathan Carter (jonathan) wrote :

Thanks a lot for all that feedback, Colin. I guess what we'll end up doing is installing language packs as selected from the gfxboot menu just before launching the gnome-session. The live CD session will be a bit slower to start if English isn't selected, but at least installation will be a lot faster for everyone.

We'll look into this a bit further for Alpha 2 and possible poke you for some advice. Thanks again!

Colin Watson (cjwatson) wrote :

OK. I'm going to mark this Won't Fix for the time being, then - but obviously do ask if you need help, or if it turns out that your alternative approach is infeasible.

Changed in ubiquity (Ubuntu Natty):
status: Triaged → Won't Fix
Changed in ubiquity (Ubuntu):
status: Triaged → Won't Fix
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

Bug attachments