PPC: LiveCD installation window vanishes during installation

Bug #1256588 reported by Keith Rogers on 2013-12-01
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)

Bug Description

I attempted to install from the 20131130 PPC LiveCD via usb flash drive. I used the erase entire drive option.

The installation window proceeds until where the slide show would begin. At that point, there is a blank area where the first slide would normally be. The progress text reads copying files.

After about 30 seconds, the entire installation window vanishes, and all that is left is the spinning gear. After 90 minutes, the installation never finished. I ran ubuntu-bug ubiquity from a terminal, and then I did a forced shutdown from the power button on the computer. I could not get to a console.

Examining the hard drive, the installer looks to have partitioned the drive, but only installed three folders: /etc., /lost+found, and /media.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ubiquity 2.17.0
ProcVersionSignature: Ubuntu 3.11.0-3.5-powerpc-smp 3.11.3
Uname: Linux 3.11.0-3-powerpc-smp ppc
ApportVersion: 2.12.7-0ubuntu1
Architecture: powerpc
CasperVersion: 1.336ubuntu1
CurrentDesktop: LXDE
Date: Sat Nov 30 20:04:41 2013
LiveMediaBuild: Lubuntu 14.04 "Trusty Tahr" - Alpha powerpc (20131130)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

I have been able to repeat this bug.

For my most recent attempt, I ran "ubiquity -d" in the terminal. It reported back, "Segmentation fault (core dumped)".

The live session functions normally, except for the two network icons in the tray, so I can easily get logs.

I attached the "dmesg" log. Any others I should attach?

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing

Attached are some more logs.

Changed in ubiquity (Ubuntu):
importance: Undecided → High

This bug is still present in PPC 20131215 iso. This time the installation window vanished shortly after the account registration process screen. I was able to shutdown from a console.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Lars Noodén (larsnooden) wrote :

I see the bug, too. It completely prevents a successful installation. Depending on the options it may also destroy any existing functioning systems, thus leaving the machine completely unusable. If it crashed before partitioning, it would be less severe.

This bug is still present using the 20140307 Live CD.

Lars Noodén (larsnooden) wrote :

Still present in the 20140319 Live CD

Adam Smith (adamsmith) wrote :

Lars, are you sure this is the same error as back in December? The logs in your duplicate bug report give more information to go on. If you know python (which I don't) I think you would be able to do some investigating of the problem. It looks like it is caused by an empty string.

Lars Noodén (larsnooden) wrote :

The symptoms seem to be the same. Though I have not checked what was actually put on the HD. It does get partitioned and formatted though, which is a big deal since that usually wipes out the existing system. No python here either otherwise I would give it a try.

Adam Smith (adamsmith) wrote :

Hmm... I have no way of testing this. Not until just before the release date which will be too late. Looking online at the code it is hard to see what the problem is. The offending files don't seem to have changed for a long time. Is this a ubiquity bug, or a debconf bug, or has something changed in python3 revealing an endian issue with strings????

From your ubiquitysyslog the error is being generated when the progress bar is being set. You could try commenting out one of the offending lines. For example, before you run ubiquity, open /usr/share/ubiquity/install.py and comment out (put a # before it) the line

self.db.progress('SET', 10 + copy_progress)

Run ubiquity and see if it works. It may then fail on another self.db.progress line.

Lars Noodén (larsnooden) wrote :

Thanks. You may have found it. Ubiquity gets about one step further, showing "copying files", but then crashes like before.
But from the MAr 19 log it looks like "/usr/lib/python3/dist-packages/debconf.py", line 83, is where the first problem manifests.

FWIW The version of python on the CD is not 3.x it is 2.7.6

Adam Smith (adamsmith) wrote :

You should have a package called python3 according to the manifest.

Does it actually copy the files with the line removed? Do you see "Almost finished copying files..."? If you do then it may be crashing on the line

self.db.progress('SET', 100)

and we can say the 'set' command is the problem.

If not then it is probably crashing on

                                    'INFO', 'ubiquity/install/copying_minute')

You can look at the log to check.

The template files (which store the messages to print) have not changed for a long time, so it's not them.

Debconf is presumably used by the debian installer and according to your iso logs that works.

It is hard to understnad how ubiquity and debconf interact. My hunch is that it is something before the copying phase that knocks it all out of sync. I haven't done programming in years, so it is hard to work out. I would need to add a load of print messages to the debconf function to check what it is doing.

Adam Smith (adamsmith) wrote :

Ignore that bit about files not changing - they have. Argh...I don't understand launchpad....

Adam Smith (adamsmith) wrote :

The other thing you or Keith could do is install old packages of ubiquity (or debconf) to see when the bug started


Download the deb files you want into a folder. 'cd' into that folder and

sudo dpkg -i *.deb

Lars Noodén (larsnooden) wrote :
Download full text (6.2 KiB)

Ok. I tried the following.

I got ubiquity_2.15.9_powerpc.deb ubiquity-frontend-debconf_2.15.9_powerpc.deb ubiquity-frontend-gtk_2.15.9_powerpc.deb ubiquity-ubuntu-artwork_2.15.9_all.deb from http://ftp.tu-chemnitz.de/pub/linux/ubuntu-ports/pool/main/u/ubiquity/ and installed them forcibly, after installing the dependencies python3-pyicu and python3-oauthlib. Here is the output:

# dpkg --force-all -i ubiquity_2.15.9_powerpc.deb ubiquity-frontend-debconf_2.15.9_powerpc.deb ubiquity-frontend-gtk_2.15.9_powerpc.deb ubiquity-ubuntu-artwork_2.15.9_all.deb
dpkg: warning: downgrading ubiquity from 2.17.10 to 2.15.9
(Reading database ... 119659 files and directories currently installed.)
Preparing to unpack ubiquity_2.15.9_powerpc.deb ...
Unpacking ubiquity (2.15.9) over (2.17.10) ...
dpkg: warning: downgrading ubiquity-frontend-debconf from 2.17.10 to 2.15.9
Preparing to unpack ubiquity-frontend-debconf_2.15.9_powerpc.deb ...
Unpacking ubiquity-frontend-debconf (2.15.9) over (2.17.10) ...
dpkg: warning: downgrading ubiquity-frontend-gtk from 2.17.10 to 2.15.9
Preparing to unpack ubiquity-frontend-gtk_2.15.9_powerpc.deb ...
Unpacking ubiquity-frontend-gtk (2.15.9) over (2.17.10) ...
dpkg: warning: downgrading ubiquity-ubuntu-artwork from 2.17.10 to 2.15.9
Preparing to unpack ubiquity-ubuntu-artwork_2.15.9_all.deb ...
Unpacking ubiquity-ubuntu-artwork (2.15.9) over (2.17.10) ...
Setting up ubiquity-ubuntu-artwork (2.15.9) ...
dpkg: ubiquity: dependency problems, but configuring anyway as you requested:
 ubiquity depends on python3-pyicu (>= 1.0); however:
  Package python3-pyicu is not installed.
 ubiquity depends on reiserfsprogs; however:
  Package reiserfsprogs is not installed.

Setting up ubiquity (2.15.9) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
dpkg: ubiquity-frontend-debconf: dependency problems, but configuring anyway as you requested:
 ubiquity-frontend-debconf depends on ubiquity (= 2.15.9).

Setting up ubiquity-frontend-debconf (2.15.9) ...
dpkg: ubiquity-frontend-gtk: dependency problems, but configuring anyway as you requested:
 ubiquity-frontend-gtk depends on ubiquity (= 2.15.9).
 ubiquity-frontend-gtk depends on gir1.2-gnomekeyring-1.0; however:
  Package gir1.2-gnomekeyring-1.0 is not installed.
 ubiquity-frontend-gtk depends on python3-oauthlib; however:
  Package python3-oauthlib is not installed.

Setting up ubiquity-frontend-gtk (2.15.9) ...
Processing triggers for desktop-file-utils (0.22-1ubuntu1) ...
Processing triggers for mime-support (3.54ubuntu1) ...
Processing triggers for man-db (2.6.6-1) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for hicolor-icon-theme (0.13-1) ...
root@lubuntu:/home/lubuntu/Downloads# dpkg --force-all -i ubiquity_2.15.9_powerpc.deb ubiquity-frontend-debconf_2.15.9_powerpc.deb ubiquity-frontend-gtk_2.15.9_powerpc.deb ubiquity-ubuntu-artwork_2.15.9_all.deb
dpkg: warning: downgrading ubiquity from 2.17.10 to 2.15.9
(Reading database ... 119662 files and directories currently installed.)
Preparing to unpack ubiquity_2.15.9_powerpc.deb ...
Unpacking ubiquity (2.15.9)...


Adam Smith (adamsmith) wrote :

2.15.9 is a bit old. It is from the middle of saucy. 2.15.26 should work since it is the version from saucy (which I think passsed?). 2.17.0 was the first trusty release and is what is on this bug report. So I would start with those two versions.

You seem to have the right idea. If it complains about a dependency then just install it. It can be a bit of a fiddle because apt doesn't like broken packages and won't install others until they are fixed. I often end up upgrading the broken package, install dependency, then downgrade package again. I'm sure there must be a more effiecient way...

Lars Noodén (larsnooden) wrote :

2.15.19 was the newest I could find in that repository that was still before 2.17.0. However, since it failed too I think something is wrong with my method or else the problem is outside of ubiquity.

Adam Smith (adamsmith) wrote :

If you use the link in comment 18, click on the version you want, then click the powerpc build link you'll get something like this


That has all the powerpc.deb files. The _all.deb files can be found by following the i386 build link.

However, there are 2.15.26 builds in your ftp.tu-chemnitz.de link.

What do you mean it failed? Does it have the same error message as your logs from bug 1294813?

Lars Noodén (larsnooden) wrote :

# dpkg -l 'ubiquity*'
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
ii ubiquity 2.15.26 powerpc Ubuntu live CD installer
un ubiquity-artwo <none> <none> (no description available)
ii ubiquity-caspe 1.339 all Configuration hooks for live inst
un ubiquity-front <none> <none> (no description available)
ii ubiquity-front 2.15.26 powerpc debconf frontend for the Ubiquity
ii ubiquity-front 2.15.26 powerpc GTK+ frontend for Ubiquity live i
un ubiquity-slide <none> <none> (no description available)
ii ubiquity-slide 80 all Ubiquity slideshow for Lubuntu
ii ubiquity-ubunt 2.15.26 all Ubuntu artwork for Ubiquity live
un ubiquity-ubunt <none> <none> (no description available)

Adam Smith (adamsmith) wrote :

Okay thanks Lars. I think we can discount ubiquity as the problem then. Would it be possible to do the same for debconf please?


(There are only three vesions.)

Lars Noodén (larsnooden) wrote :

This is what I get when swapping out debconf alone.

# wget http://ftp.tu-chemnitz.de/pub/linux/ubuntu-ports/pool/main/d/debconf/debconf_1.5.50ubuntu1_all.deb
# dpkg --force-all -i debconf_1.5.50ubuntu1_all.deb

# tail -n 15 /var/log/syslog
Mar 30 18:27:16 lubuntu kernel: [ 1018.515478] ubiquity[4635]: unhandled signal 11 at 00000007 nip 09744b34 lr 09745f34 code 30001
Mar 30 18:28:07 lubuntu /install.py: Exception during installation:
Mar 30 18:28:07 lubuntu /install.py: Traceback (most recent call last):
Mar 30 18:28:07 lubuntu /install.py: File "/usr/share/ubiquity/install.py", line 733, in <module>
Mar 30 18:28:07 lubuntu /install.py: install.run()
Mar 30 18:28:07 lubuntu /install.py: File "/usr/share/ubiquity/install.py", line 135, in run
Mar 30 18:28:07 lubuntu /install.py: self.copy_all()
Mar 30 18:28:07 lubuntu /install.py: File "/usr/share/ubiquity/install.py", line 482, in copy_all
Mar 30 18:28:07 lubuntu /install.py: self.db.progress('SET', 10 + copy_progress)
Mar 30 18:28:07 lubuntu /install.py: File "/usr/lib/python3/dist-packages/debconf.py", line 62, in <lambda>
Mar 30 18:28:07 lubuntu /install.py: lambda *args, **kw: self.command(command, *args, **kw))
Mar 30 18:28:07 lubuntu /install.py: File "/usr/lib/python3/dist-packages/debconf.py", line 83, in command
Mar 30 18:28:07 lubuntu /install.py: status = int(status)
Mar 30 18:28:07 lubuntu /install.py: ValueError: invalid literal for int() with base 10: ''
Mar 30 18:28:07 lubuntu /install.py:

Adam Smith (adamsmith) wrote :

Hmm.... unless it is the package debconf-i18n which should be on the lubuntu iso too, then I have no idea. Well actually I do, it is probably a bug in python. Trusty has a package python3.4. Saucy has a package python3.3.

Thanks for testing my ramblings Lars.

Adam Smith (adamsmith) wrote :

Similar-ish - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/882882

So it might not be anything powerpc specific, but caused by debconf being locked by something else.

Adam Smith (adamsmith) wrote :

This may sound crazy, but does it work if you use the yaboot parameter snd_powermac.blacklist=true? I'm just trying to think of things that you did in saucy, and I know both Lars and Keith needed this. The "Fixing recursive fault" bug was always a bit random, and maybe that is causing the debconf lockup?

Adam Smith (adamsmith) wrote :

We've also been ignoring Keith's debug error messages

(ubiquity:2723): dconf-CRITICAL **: unable to create directory '/root/.cache/dconf': Permission denied. dconf will not work properly.

just a bit before ubiquity fails

Adam Smith (adamsmith) wrote :

Apparantly (according to other bug reports) the error in comment 33 is nothing to worry about.

Adam Smith (adamsmith) wrote :

You might get a bit further if you encrpyt your home folder....

Adam Smith (adamsmith) wrote :

I can't get it to work. If you choose encrytion of the home folder it gets a bit further and copies something like 30-50% according to the logs. If you don't do anything at the user setup page then it will copy 100% of the files, but still fail. Attaching the logs of the latter...

Adam Smith (adamsmith) wrote :
Adam Smith (adamsmith) wrote :
Adam Smith (adamsmith) wrote :

Marking this a duplicate of 996568 since it sounds the same.

Brian Murray (brian-murray) wrote :

This doesn't look the same to me - notice the following in the syslog from comment #37

Apr 3 21:11:11 lubuntu kernel: [ 4058.465844] ubiquity[32493]: unhandled signal 11 at 00000007 nip 09744b34 lr 09745f34 code 30001

Also the first dmesg posted to this bug contains the following:

[ 54.604261] ------------[ cut here ]------------
[ 54.604272] WARNING: at f33eae30 [verbose debug info unavailable]
[ 54.604277] Modules linked in: rtc_generic(F) snd_aoa_codec_tas(F) snd_aoa(F) snd_powermac(F) bnep(F) snd_pcm(F) uio_pdrv_genirq(F) rfcomm(F) snd_page_alloc(F) bluetooth(F) uio(F) snd_seq_midi(F) snd_seq_midi_event(F) snd_rawmidi(F) snd_seq(F) snd_seq_device(F) snd_timer(F) snd(F) soundcore(F) squashfs(F) overlayfs(F) isofs(F) dm_mirror(F) dm_region_hash(F) dm_log(F) hid_generic(F) usbhid(F) hid(F) usb_storage(F) firewire_ohci(F) sungem(F) sungem_phy(F) firewire_core(F) crc_itu_t(F) aic7xxx(F) scsi_transport_spi(F) uninorth_agp(F)
[ 54.604367] CPU: 0 PID: 28 Comm: kworker/0:1 Tainted: GF 3.11.0-3-powerpc-smp #5-Ubuntu
[ 54.604399] Workqueue: events device_change_handler [snd_powermac]
[ 54.604404] task: ef9bbf40 ti: ef9fe000 task.ti: ef9fe000
[ 54.604409] NIP: f33eae30 LR: c005c2e0 CTR: f33eadf0
[ 54.604414] REGS: ef9ffdc0 TRAP: 0700 Tainted: GF (3.11.0-3-powerpc-smp)
[ 54.604418] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 42f62128 XER: 00000000
[ 54.604434]
[ 54.604434] GPR00: c005c2e0 ef9ffe70 ef9bbf40 f33f0780 00000000 ef9fe000 0000649a 0305e000
[ 54.604434] GPR08: f33f0784 00000001 00000001 00001032 42f62122 00000000 c00640b0 ef8c3df8
[ 54.604434] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c39f3380
[ 54.604434] GPR24: c09f0000 00000001 00000000 c39f6500 c39f3180 00000000 c7f19800 00000000
[ 54.604493] NIP [f33eae30] device_change_handler+0x40/0x290 [snd_powermac]
[ 54.604510] LR [c005c2e0] process_one_work+0x158/0x3cc
[ 54.604514] Call Trace:
[ 54.604526] [ef9ffe70] [00000001] 0x1 (unreliable)
[ 54.604535] [ef9ffe90] [c005c2e0] process_one_work+0x158/0x3cc
[ 54.604542] [ef9ffec0] [c005cc60] worker_thread+0x134/0x3fc
[ 54.604553] [ef9ffef0] [c0064164] kthread+0xb4/0xb8
[ 54.604562] [ef9fff40] [c0017140] ret_from_kernel_thread+0x5c/0x64
[ 54.604566] Instruction dump:
[ 54.604572] 7c0802a6 7d800026 90010024 bf810010 9181000c 3d20f33f 83c90790 2f9e0000
[ 54.604588] 419e0244 83fe0178 7fe90034 5529d97e <0f090000> 2f890000 409e022c 813f003c
[ 54.604604] ---[ end trace 4932ece8b480c22e ]---

Brian Murray (brian-murray) wrote :

This is likely a duplicate of bug 1296386.

Adam Smith (adamsmith) wrote :

This isn't a duplicate of bug 1296386 (although it would be nice if that and it's fellow sound bugs were fixed). The snippet in #40 would only be produced on computers that used to use snd-powermac, but now should be using snd-aoa (the code to deprecate snd-powermac has not been written yet). On computers that have used snd-aoa for years (i.e. they have a fabric layout), snd_powermac is just unloaded. However, they still suffer from this bug. It is definitly slideshow related and has the same symptoms as 996568.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers