Comment 7 for bug 810145

Hi David,

Thanks for looking at this report!

We do automated testing on a bunch of laptops, which are all network-installed using a preseed file which contains this line in the late_command:

in-target sudo -u ubuntu gconftool-2 --set --type bool /desktop/gnome/interface/accessibility true

The reason for this was to enable testing using mago, which requires the accessibility framework to be enabled.

So we don't actually need a11y specifically, but that's how we came across this problem.

In principle, disabling it makes things work correctly; in practice, however, I've found that using gconftool-2 on Oneiric gives weird results. If, after installing with the aforementioned command in the preseed, I go into "Universal Access" it shows everything as "Off" but the problem still occurs. However, if I toggle (On, then Off) the screen reader, accessibility gets disabled correctly and the panel stops crashing.

Steps to reproduce:

1- Install from an Oneiric Alpha 3 image using the attached preseed file. I created a custom CD image replacing the /preseed/ubuntu.seed file with the one I'm attaching. Note that this preseed file minimally modifies the stock one, just adding the gconftool-2 command as mentioned above.
2- When prompted for the user's data, the username should be "ubuntu", as that's the user the preseed file modifies.
3- Once the install completes, and upon logging in, you'll notice elevated CPU usage from the constant dying/respawning of unity-panel-service.
4- from the Unity app lens, launch gnome-terminal to witness how it shrinks due to the panel respawning.

This happens on every system I've tested Oneiric in, about 30 laptops, various makes/models, but more importantly, the test case I just gave works even on a virtual machine (I'm using VirtualBox 4 on Natty), so it's definitely not hardware-related. The systems where it did not happen, were the ones that were installed manually, hence, the gconftool command wasn't used.

Finally, I should mention that what hinted that accessibility was somehow related, was bug 798094 which describes a similar issue.

Thanks again!