Installer crashed (xfs related?)

[Namzaj]

Traceback (most recent call last):
  File "/usr/bin/ubiquity", line 130, in ?
    install(sys.argv[1])
  File "/usr/bin/ubiquity", line 55, in install
    ret = wizard.run()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 266, in run
    self.process_step()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 741, in process_step
    self.mountpoints_to_summary()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 1029, in mountpoints_to_summary
    self.progress_loop()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 538, in progress_loop
    raise RuntimeError, ("Install failed with exit code %s; see "
RuntimeError: Install failed with exit code 1; see /var/log/installer/syslog and /var/log/syslog

[Namzaj (jasperkuiper)]

/var/log/syslog

[Namzaj (jasperkuiper)]

/var/log/installer/syslog

[Namzaj (jasperkuiper)]

/var/log/partman

[Namzaj (jasperkuiper)]

Crashed on AMD XP 1600+
multiple harddisks
dualboot WinXP en OpenSuse (working fine)
wanting to add third OS

Used different cd-media, burnt at lowest speed, crash keeps repeating, also on different system with only WinXP

[Namzaj (jasperkuiper)]

I just managed to install on my secondary computer. What did I change?
In prior attempts I was installing on xfs filesystem. Now I reformated to ext3 and it works....
Could this be it?

[Namzaj (jasperkuiper)]

I just confirmed on my primairy system that installing on ext3 instead of xfs does work, no installer crash anymore.

[annie_linux (fdfisher)]

I have a nearly identical bug, <a href="https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/49180">49180</a>, and I am installing on ext3 so maybe it fixed it for you, but I don't think xfs is the source of the bug directly.

[Dennis Kaarsemaker (dennis)]

XFS is the source of the bug, this has been reported quite often
already. Workaround: don't use ntfs for / or use a non-xfs /boot

[Denis (bibar)]

+1
Traceback (most recent call last):
  File "/usr/bin/ubiquity", line 130, in ?
    install(sys.argv[1])
  File "/usr/bin/ubiquity", line 55, in install
    ret = wizard.run()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 266, in run
    self.process_step()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 741, in process_step
    self.mountpoints_to_summary()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 1029, in mountpoints_to_summary
    self.progress_loop()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 538, in progress_loop
    raise RuntimeError, ("Install failed with exit code %s; see "
RuntimeError: Install failed with exit code 1; see /var/log/installer/syslog and /var/log/syslog

I already have Kubuntu on the first HD, and wanted to install Ubuntu on the second one. I had a error (without details) regarding the hda1 partition (24 mo the boot of Kubuntu). But no NTFS on my system.

[Denis (bibar)]

/var/log/syslog
/var/log/partman
/varlog/installer/syslog

[Benoit (benoit-helaine)]

I have the same bug. The installer crashed at the end of the installation (grub installation).
I have a Toshiba laptop M60-173 and Windows XP on the first partition (NTFS).

Traceback (most recent call last):
  File "/usr/bin/ubiquity", line 130, in ?
    install(sys.argv[1])
  File "/usr/bin/ubiquity", line 55, in install
    ret = wizard.run()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 266,
in run
    self.process_step()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 741,
in process_step
    self.mountpoints_to_summary()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 1029,
in mountpoints_to_summary
    self.progress_loop()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 538,
in progress_loop
    raise RuntimeError, ("Install failed with exit code %s; see "
RuntimeError: Install failed with exit code 1; see /var/log/installer/syslog and
/var/log/syslog

[Jim Michmerhuizen (jamzen)]

The same trace as above. I am installing onto a WinBook A730, to dualboot w/MSXP.

[Dennis Kaarsemaker (dennis)]

Benoit, Jim:

In this case the same trace can mean a different bug. Please file
separate bugs for your problems to make Colins life easier.

[GeorgeAmbrose (aklaing)]

related to my comment above

[GeorgeAmbrose (aklaing)]

It seems my traceback isn't up yet, I'll post it in a second.

[GeorgeAmbrose (aklaing)]

I'll post traceback next.

[GeorgeAmbrose (aklaing)]

GeorgeAm's Traceback:

Traceback (most recent call last):
  File "/usr/bin/ubiquity", line 130, in ?
    install(sys.argv[1])
  File "/usr/bin/ubiquity", line 55, in install
    ret = wizard.run()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 311, in run
    self.process_step()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 734, in process_step
    self.mountpoints_to_summary()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 1047, in mountpoints_to_summary
    self.progress_loop()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/kde-ui.py", line 524, in progress_loop
    raise RuntimeError, ("Install failed with exit code %s; see "
RuntimeError: Install failed with exit code 1; see /var/log/installer/syslog and /var/log/syslog

I wanted to format one partition and keep all the others. I don't use xfs or ntfs. This is what went wrong.

[Peter Joseph (kneecaps-shockpulse)]

Have had this exact same error. Single HDD...root partition on XFS. Will try installing with root as ext3

[GeorgeAmbrose (aklaing)]

In my case xfs and ntfs had nothing to do with the bug. It had everything to do with trying to use an
old /var partition. For some reason the installer only wants to work on cleanly formatted system
partitions like '/', and '/var'.

In my case I was trying to reuse an old '/var' (which had my web pages inside /var/www), and kubuntu
would have none of it. So I used a different idle partition as a new '/var', and formatted it, and it
worked. That was the only thing that changed between it not working and then beginning to work.

[GeorgeAmbrose (aklaing)]

BTW I got the idea that this might work from a comment online (found with google) by the author
of Ubiquity. To give credit where it is due. He said something like he should make it warn the
user rather than crash or something like that.

[Jim Michmerhuizen (jamzen)]

On Tue, 2006-06-13 at 23:05 +0000, GeorgeAmbrose wrote:
> In my case xfs and ntfs had nothing to do with the bug. It had everything to do with trying to use an
> old /var partition. For some reason the installer only wants to work on cleanly formatted system
> partitions like '/', and '/var'.
>
> In my case I was trying to reuse an old '/var' (which had my web pages inside /var/www), and kubuntu
> would have none of it. So I used a different idle partition as a new '/var', and formatted it, and it
> worked. That was the only thing that changed between it not working and then beginning to work.
>
Yes, in fact my circumstances were identical to what you just described.
I was trying to reuse an old /var partition.

The crash happened very late in the whole installation, and I already
had a 386-platform Dapper that had been running flawlessly for several
months. So I booted the old installation, and
revised /boot/grub/menu.lst to point to the new AMD64-platform
installation. That worked.

But the more I thought about the consequences of trying to share a /var
partition, the less I liked what I was imagining. So I made a new
installation from scratch, without referencing the old /var partition.
And this time the installer didn't crash.

The only difference was the /var partition, just as you observed.

[TraxTech (linux-niaouli)]

GeorgeAmbrose: I'm afraid you're talking of an another bug. In my case, the installer crashed when installing the boot loader on an XFS partition, and the partitions layout did not contained a /var (only a swap and a root, all previously formated)

[Dennis Kaarsemaker (dennis)]

George: File a new bug please. This bug report is getting very messy
this way.

[Phil Miller (ubuntu-millenix)]

I've experienced this crash, with the same traceback, when I tried to use xfs for / and /home partitions. I haven't tried it with a different filesystem setting, because something went wrong with the Windows installation on that system after the crashed install, and recovering that is currently more important to me.

I'm posting this to request that, at the very least, this issue be added to the 'Known Issues' section of the Release Notes. I'm an experienced Linux user (Debian on the desktop for 3+ years, various servers for longer), and this caught me by surprise. Seeing a comment in the code asking 'why is this crashing' when I investigated the traceback did not inspire confidence. Preferable would be fixing this and uploading a revised image to resolve it, but I don't know if that's feasible now, after the release.

[GeorgeAmbrose (aklaing)]

I have filed mine seperately as #49764. However I believe it has probably
been filed by someone else before me (couldn't find it on searching just
now). I
know because I did get the idea to format all *system* partitions from
another
posting on launchpad.

GeorgeAm

[Colin Watson (cjwatson)]

Thanks for your report. Due to some reliability problems with GRUB and XFS, you need to use a non-XFS root filesystem or create a non-XFS /boot filesystem. Bug 47848 is filed to note that the partitioner should warn you about this up-front.

Phil: Perhaps you should check the release notes again, because this issue is already mentioned there. They say "A number of problems have been reported with the installer on the Desktop CD; the list of known issues in Ubiquity outlines some of these that can easily be avoided or worked around"; "list of known issues in Ubiquity" is a link to http://wiki.ubuntu.com/DapperReleaseNotes/UbiquityKnownIssues, and the third item there is this problem. The comment in the code that you found does not indicate the kind of idiocy on my part that you seem to think; it simply indicates that extracting the traceback from a crashing Python subprocess is difficult (I have a hacky way to deal with that which I'll include in Edgy).