ubiquity crashed with OSError in copy_all()

Can you please retry with the latest daily live CD:
http://cdimage.ubuntu.com/daily-live/current/

I believe the problem you were seeing was caused by the code that would normally clear such conflicting files off the partition being temporarily disabled while a serious bug was fixed. Please follow up regardless of the outcome so we'll know whether to close this bug or mark it at a higher priority.

Thanks!

I have just hit this problem using the release version of Kubuntu.

From the comment above about a non-empty filesystem, I have looked at the partitions and it appears that despite telling the installer to format them, it has failed to do so, as there are many old files still there.

I noticed during the install that there were a large number of messages in /var/log/syslog like:

Nov 1 16:09:40 ubuntu python: Not copying <email address hidden>/chrome/it.jar

which is probably indicative of something.

I will now try again after manually emptying the relevant filesystems. If that fails, I'll have to restore from my backups. I'll try to report back here when I have a working system again.

I've tried several times and the installer crashes every time, leaving me with an unusable system. It makes no difference if I clean out the install partitions before installing, or get ubiquity to clear them or even leave them with old files in them.
The last message in /var/log/syslog, which seems to be significant is:
Nov 2 12:31:57 ubuntu ubiquity[8103]: OSError: [Errno 21] Is a directory: '/target/usr/local/man
This suggests to me that the installer doesn't like the fact that I'm telling it to use such partitions as /usr/local.

Next attempt: only configure the most basic of partitions.

Successfully installed by not telling the installer about the partitions I wanted to keep. So then I had to re-edit /etc/fstab to put them back and delete all the stuff the installer put in the directories I was going to mount over.

Luckily I know Unix well; this would have defeated a lot of users.

Still ongoing in 9.04 beta. Problem only with /usr/local. Other kept partitions fine, /home and nonstandard /mp3 and /data , just the second level directory structure of /usr/local it seems. /etc/fstab redited and working fine.

This bug is in the golden Ubuntu 9.04, very bad.
I suspect the bug is related to having more then a few partitions, or partitions
where the installer did not expect them. This prevents using Ubuntu for
serious installs (servers, robust work stations, etc.).
  FYI I have now seen this bug in both the i386 and amd64 architectures.

Duh, I should give you the set of partitions that caused todays failure.

This is a test system, so it's simple. One 250GB SATA drive, and in todays case the install was off of USB key, but I have seen the same off of CD-ROM.

  Here are the partitions I made that caused it to fail:

Partition
        Size in MB
                  Mount point (most are ext3)
p1 8192 /
p2 4096 (spare, not used)
p3 4096 swap
p4 extended (rest)
l5 32678 /usr
l6 8192 /tmp
l7 4096 /var
l8 4096 /var/cache
l9 4096 /var/log
l10 4096 /var/spool
l11 4096 /var/spool/mail
l12 rest /home

  I did not make /srv or /opt as it was just a test system. Do something like that and you will be able to reproduce this crash.

Thanks to Tony Green and StealthBanana, had the same problem on installing a 9.04 keeping a Slack's /usr/local (ot to be formatted). No problem with other partitions, /tmp, /var, /home, seems to be relative to the second level directory structure as said StealthBanana.

This bug affect me also with Mythbuntu 9.10 (RC).
So my original bug #458980 get closed as duplicate of this one.
The question if for me, did I really hit a bug that is so old (reported 2008-02-04)?
Or more important for me, what can i do to workaround this bug? Since it let me not install Mythbuntu after many attempts.

The workaround that got me through was simply to not specify the offending partition during the install then to manually add it to /etc/fstab once I'd finished.

I believe we fixed this in the final Ubuntu 9.10 release CDs. I would greatly appreciate anyone who is still getting this error with the CDs that will be released today to run `sudo apport-collect 188976` after the installer crashes.

If this bug is fixed for you, please report back as well.

Thanks a bunch!

Architecture: amd64
DistroRelease: Ubuntu 9.10
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
Package: ubiquity 2.0.8
PackageArchitecture: amd64
ProcEnviron:
 PATH=(custom, no user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
Uname: Linux 2.6.31-14-generic x86_64
UserGroups:

XsessionErrors:
 (gnome-settings-daemon:3448): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:3448): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:3545): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:3569): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (gnome-panel:3544): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 24

Architecture: i386
DistroRelease: Ubuntu 9.10
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Package: ubiquity 2.0.8
PackageArchitecture: i386
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
Uname: Linux 2.6.31-14-generic i686
UserGroups:

XsessionErrors:
 (gnome-settings-daemon:3599): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:3599): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:3660): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:3685): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:23858): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed

ust got the problem while installing Ubuntu 9.10. Not specifying /usr/local got me past this bug (I could specify an existing /home without any problem).

I can confirm that this issue still exists in the Installer of Ubuntu 9.10 , on an AMD64 system.
I tried to install on an already existing 9.10 installation, I used that partition as the root partition for my
installation attempt.
Looks like it does not like the already existing /opt folder in the target partition that would end up as / :

PythonArgs: ['/usr/lib/ubiquity/bin/ubiquity', '--only']
Traceback:
 Traceback (most recent call last):
   File "/usr/lib/ubiquity/bin/ubiquity", line 457, in <module>
     main(oem_config)
   File "/usr/lib/ubiquity/bin/ubiquity", line 444, in main
     install(query=options.query)
   File "/usr/lib/ubiquity/bin/ubiquity", line 245, in install
     ret = wizard.run()
   File "/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py", line 465, in run
     self.progress_loop()
   File "/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py", line 975, in progress_loop
     (ret, realtb))
 RuntimeError: Install failed with exit code 1
 Traceback (most recent call last):
   File "/usr/share/ubiquity/install.py", line 2430, in <module>
     install.run()
   File "/usr/share/ubiquity/install.py", line 367, in run
     self.copy_all()
   File "/usr/share/ubiquity/install.py", line 754, in copy_all
     os.mkdir(targetpath, mode)
 OSError: [Errno 17] File exists: '/target/opt'

OK now, there is no doubt now - in the manual partitioning mode, If there is a (dead) symlink named 'opt' onte partition that is supposed to be the root partition of the new installations, ubuquitty fails with the errors in the last comment.

I remoded the link and installation went just fine.

I'm got the problem while installing Ubuntu 9.10 on the disk with old partition /home.

As Bug #512634 is marked as duplicate of this one I add this comment here: I faced the problem of regularly crashing installation attempts, too. After some web search I found a comment that this problem was related with the chosen file systems. After a new try I can confirm, that while crashing when installing with ext2 the installation succeeded smoothly with ext4.
The needed system information is attached to #512634.

I know what you did, HughDaniel: You tried to partition your drive by not only making their mount points high-level directories but also mounting other partitions as their subdirectories (also known as tree-partitioning). Ubiquity cannot handle this, and so the "OSError" will result.

Can this be confirmed as the cause of this error? Has anyone used different partitioners to see if the bug is repeatable? I'm marking this incomplete for now, because it seems like we need a little more info to proceed.

Installing Mythbuntu 10.4 beta1 over Ubuntu 9.10 after contaminating original O/S with Lucid Lynx files.

In trying to preserve the original user files, I re-used the / partition without formatting it and re-used the swap partition. The other partition on the disk and the one on another drive were ignored.

depending on what the first "this" means, this bug is potentially still viable as of 10.4 release / Lucid Lynx

I just logged bug 573220 (which I can't flag as dupe right now because of it's dupe bug 573218 that's a result of impatient clicking and is unable to be accessed (with OOPS-1582B2194 )).

Basically that bug boiled down to comment 6, /usr/local already existing and attempting to be kept intact. Not configuring /usr/local during manual partitioning let me complete without crash. I've yet to reboot though. :-)

I'd also (I presume) likely to have run into comment 30 "tree-partitioning" issues having /usr/local and /usr/local/iso-image both mounted.

I had /usr/local symlinked to /local/usr/local (on a different disk from /).
I guess the installer had trouble because / is mounted as /target, and there is no /local.

There's further traffic on bug 573220 that I posted but can't properly file as a dupe of this one because of some internal launchpad silliness as near as I can tell.

This problem affects Linux Mint, Kubuntu and Ubuntu. I have had the same problem on all three flavors. I have been using the manual partitioning.

Crash log from /var/log/installer/debug:
  File "/usr/share/ubiquity/install.py", line 2566, in <module>
    install.run()
  File "/usr/share/ubiquity/install.py", line 353, in run
    self.copy_all()
  File "/usr/share/ubiquity/install.py", line 741, in copy_all
    os.unlink(targetpath)
OSError: [Errno 21] Is a directory: '/target/usr/local/man'

Traceback (most recent call last):
  File "/usr/lib/ubiquity/bin/ubiquity", line 524, in <module>
    main(oem_config)
  File "/usr/lib/ubiquity/bin/ubiquity", line 509, in main
    install(args[0], query=options.query)
  File "/usr/lib/ubiquity/bin/ubiquity", line 242, in install
    ret = wizard.run()
  File "/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py", line 513, in run
    self.process_step()
  File "/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py", line 1179, in process_step
    self.progress_loop()
  File "/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py", line 1062, in progress_l:

Encountered this on Linux Mint. The installer fatally crashed without even leaving the option to use the automatic reporting tool. Manually doing rm -rf /target/usr/local/share/* allows the installer to complete, because only removing the man directory makes the installer create a symlink and it will still crash, just with a different error.

This bug was fixed in the package ubiquity - 2.9.19

---------------
ubiquity (2.9.19) precise; urgency=low

  * Install pixmaps/windows_square.png in ubiquity-frontend-gtk.
  * Make it possible to run the test suite against installed packages, and
    add a DEP-8 control file for this.
  * Refactor copy_all to be more robust, handle some more cases, and be
    testable and tested. It can now:
    - copy a directory over an existing non-directory (LP: #891711);
    - copy device nodes and sockets over existing non-directories
      (LP: #495217);
    - handle all cases of copying a non-directory over an existing empty
      directory;
    - copy a symlink over a non-empty directory by attempting to move the
      directory to the symlink target (LP: #188976);
    - if all else fails, copy a non-directory over an existing non-empty
      directory by moving the target aside to a backup location.
  * Ignore all failures to set timestamps (LP: #411307, #654929).
  * Update translations from Launchpad.
  * Update imported translations from gtk+3.0 3.3.14-0ubuntu2 and
    gnome-panel 1:3.3.5-0ubuntu2.
 -- Colin Watson <email address hidden> Wed, 15 Feb 2012 17:52:19 +0000