Ubuntu

ubiquity crashed with InstallStepError in configure_bootloader()

Reported by Brian Burch on 2008-08-21
This bug affects 118 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Undecided
Unassigned
Nominated for Karmic by Kjow

Bug Description

Binary package hint: ubiquity

This is probably a duplicate of closed/dormant bug 71984, but I have opened a new one because it occurred on Intrepid alpha 4 and I want to be sure you have an up-to-date set of documentation.

I suspect the crash is caused by my choice of an install that has fallen outside the validation box. I was trying to install a standalone intrepid system on a new partition of a multiboot machine. However, in manual partitioning I did NOT mount the existing grub partition as /boot. I guess the install was confused when trying to install another grub boot loader. I will retry the installation with the existing /boot mounted.

ProblemType: Crash
Architecture: i386
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
InterpreterPath: /usr/bin/python2.5
Package: ubiquity 1.9.9
ProcAttrCurrent: unconfined
ProcCmdline: /usr/bin/python /usr/lib/ubiquity/bin/ubiquity gtk_ui
ProcEnviron: Error: [Errno 13] Permission denied: '/proc/8007/environ'
PythonArgs: ['/usr/lib/ubiquity/bin/ubiquity', 'gtk_ui']
SourcePackage: ubiquity
Title: ubiquity crashed with InstallStepError in configure_bootloader()
Uname: Linux 2.6.26-5-generic i686
UserGroups:

Brian Burch (brian-pingtoo) wrote :

My suspicion was wrong. It failed again when the grub partition was
mounted. I then tried using the alternate cd, but the install of grub
failed, although I couldn't see why.

Finally, I tried to recover the system using the alternate CD and
update-initramfs. I manually added the new kernel to
/boot/grub/menu.list and rebooted...

The "new" grub menu showed me the new image, but when I tried to boot it
it failed with "Error 2: Bad file or directory type".

I found this handy tutorial:

http://www.linuxplanet.com/linuxplanet/tutorials/6480/1/

... and tune2fs showed me that the inode size on my new partition was
256 bytes. I booted the intrepid alternate CD and checked the version of
grub - 0.97. Bingo! This version of grub does not support the 256 byte
inodes created by the version of mke2fs used by the intrepid install CD.

I reformatted the target partition with 128 byte inodes and ran the
installation again from the intrepid desktop CD, using manual
partitioning but preventing the root partition from being formatted....
the install crashed again!!

I booted the alternate CD and went to recover the broken system... the
inode size was still 128. I setup and ran update-initramfs again. I
edited /boot/grub/menu.list to put the new UUID into the appropriate
entries.

Try to boot the new partition... grub error 15: file not found.
Discovered a typo in menu.list - the root for the new system should have
been the shared /boot partition, but I had pointed it at the new
intrepid partition. Try again...

The intrepid system booted OK from the grub menu. Problem bypassed.

conclusion... IF intrepid is going to use grub 0.97, then it had better
format partitions with 128 byte inodes or there will be a lot of
heartaches when ordinary people start using it!

over and out.

Brian

Colin Watson (cjwatson) wrote :

Actually, we added 256-byte inode support to grub a while back:

grub (0.97-29ubuntu19) hardy; urgency=low

  [ David Futcher ]
  * debian/presubj: Fixed spelling mistake (LP: #177540)

  [ Tormod Volden ]
  * debian/update-grub: use >> instead of > when writing to existing files
    so that the script continues to work if noclobber is set. LP: #155423

  [ Steve Langasek ]
  * debian/patches/ext3_256byte_inode.diff: new patch cherry-picked from
    Debian to support 256-byte inodes in ext3, for compatibility with recent
    e2fsprogs upstream defaults. Thanks Stefan Lippers-Hollmann.

 -- Steve Langasek <email address hidden> Wed, 19 Mar 2008 12:12:40 -0700

I suspect this is actually something else. I notice a chain of errors in your syslog starting with this:

Aug 21 08:34:43 ubuntu ubiquity: Package `linux-image-2.6.26-5-generic' is not installed and no info is available.
Aug 21 08:34:43 ubuntu ubiquity: Use dpkg --info (= dpkg-deb --info) to examine archive files,
Aug 21 08:34:43 ubuntu ubiquity: and dpkg --contents (= dpkg-deb --contents) to list their contents.
Aug 21 08:34:43 ubuntu ubiquity: /usr/sbin/dpkg-reconfigure: linux-image-2.6.26-5-generic is not installed.

In other words, the kernel package that should correspond to what's on the live CD wasn't copied onto the hard disk! It's not clear to me why this might be happening; perhaps some kind of file-copying problem, and perhaps Alpha 4 was just hosed in some way I've forgotten about. Can you reproduce this with Alpha 5?

Brian Burch (brian-pingtoo) wrote :

Colin Watson wrote:
> Actually, we added 256-byte inode support to grub a while back:
>
> grub (0.97-29ubuntu19) hardy; urgency=low
>
> [ David Futcher ]
> * debian/presubj: Fixed spelling mistake (LP: #177540)
>
> [ Tormod Volden ]
> * debian/update-grub: use >> instead of > when writing to existing files
> so that the script continues to work if noclobber is set. LP: #155423
>
> [ Steve Langasek ]
> * debian/patches/ext3_256byte_inode.diff: new patch cherry-picked from
> Debian to support 256-byte inodes in ext3, for compatibility with recent
> e2fsprogs upstream defaults. Thanks Stefan Lippers-Hollmann.
>
> -- Steve Langasek <email address hidden> Wed, 19 Mar 2008
> 12:12:40 -0700
>
> I suspect this is actually something else. I notice a chain of errors in
> your syslog starting with this:
>
> Aug 21 08:34:43 ubuntu ubiquity: Package `linux-image-2.6.26-5-generic' is not installed and no info is available.
> Aug 21 08:34:43 ubuntu ubiquity: Use dpkg --info (= dpkg-deb --info) to examine archive files,
> Aug 21 08:34:43 ubuntu ubiquity: and dpkg --contents (= dpkg-deb --contents) to list their contents.
> Aug 21 08:34:43 ubuntu ubiquity: /usr/sbin/dpkg-reconfigure: linux-image-2.6.26-5-generic is not installed.
>
> In other words, the kernel package that should correspond to what's on
> the live CD wasn't copied onto the hard disk! It's not clear to me why
> this might be happening; perhaps some kind of file-copying problem, and
> perhaps Alpha 4 was just hosed in some way I've forgotten about. Can you
> reproduce this with Alpha 5?

Sorry that I took my eye off the ball, Steve. I've had other problems
that were more important to me, and, as you already noticed, I had
already found a bypass and moved on.

I see the intrepid beta is mow available, so I will try a clean install
on the same machine to see whether this problem can be closed. (I am
surprised that so many users are reporting duplicates of this problem,
so perhaps there is still something to discover from my efforts).

I'll be back to you in a couple of days - the iso is downloading now, so
I'll install as soon as I find enough free time.

Regards,

Brian

Sorry about calling you "Steve", Colin - I was in a hurry and must have
been thinking of the person I was going to play at squash as soon as I
finished the email!

The problem still exists with intrepid beta, but it looks as if the
details might have changed. At this stage, I don't think the hardware is
relevant, but I'm using an HP laptop with an intel P4 processor.

I tried to replicate my previous installation process.

1. Boot the intrepid CD live system and pre-define a new 6.5GB partition
with ext3. (tune2fs shows it has 256 byte inodes).

2. Start the installer from the object on the desktop. Choose manual
partitioning. Use the existing swap partition. Use the existing boot
partition (Hardy grub on ext3 with 128 byte inodes).

The installation fails at the end. Unfortunately, I was running without
a network connection and the crash report app failed. I didn't know how
to collect all of the usual files, so I have attached those that seem to
me to be most relevant.

I can see from the syslog that the original alpha 4 kernel copy problem
is not the direct cause of this current failure.

Grub hasn't been wrecked and so I can still boot my Hardy system and
work on the machine. I have the original (working) intrepid alpha 4
system and the new intrepid beta failed installation on two different
partitions.

What more can I do to help? If I've missed any important information
held on the new system disk, I can send it easily. If you would like me
to run the install again (with a network connection this time!), either
from the live or the alternate CD's, just let me know.

Regards,

Brian

linex83 (linex83) wrote :

I'll be also glad to test and send you any information you need.

I would love to see this fixed since I just cannot install Ubuntu otherwise. (BTW, Debian has this problem also.)

hjkopel (hjkopel) wrote :

I'm kinda new at this but I had a problem installing xubuntu beta 8.10. See bug # 285716. The file grub_0.97-29ubuntu36_i386.deb is not at http://archive.ubuntu.com/ubuntu/pool/main/g/grub/ .

Chazall1 (lishdigg) wrote :

I reformatted the target partition with 128 byte inodes and ran the
installation again from the intrepid desktop CD, using manual
partitioning but preventing the root partition from being formatted....
the install and all is functioning. This was my work around. I needed the 128
byte inodes in order to boot. I have a multi boot HD and the GRUB error is
from Intrepid E2fsprogs sett ing the inodes to 256.
I am using the RC Intrepid.

Filipe Sousa (natros) wrote :

I just download 8.10 (i386) and I cannot install it on a clean system. I tried twice and in both cases the installer crashed while trying to install the grub.

I can't believe this is happening, I was not expecting this bug on a final release.

ubuntu@ubuntu:~$ sudo fdisk -l /dev/mapper/isw_dahbjidgj_Volume0

Disk /dev/mapper/isw_dahbjidgj_Volume0: 640.1 GB, 640141230080 bytes
255 heads, 63 sectors/track, 77826 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00018214

                             Device Boot Start End Blocks Id System
/dev/mapper/isw_dahbjidgj_Volume0p1 1 76692 616028458+ 83 Linux
/dev/mapper/isw_dahbjidgj_Volume0p2 76693 77826 9108855 5 Extended
/dev/mapper/isw_dahbjidgj_Volume0p5 76693 77826 9108823+ 82 Linux swap / Solaris

Filipe Sousa (natros) wrote :
X3 (x3lectric) wrote :

Yes I found exact same issue further more upgrade from LTS also failed with dozens of errors.

So when I finally decided to do a clean install Grub failed to install and resulting in the reported error.

Also worth mentioning that installing from live session will never go past the loading partition utility and result in more errors.

8.10 is definitely worst now then it was when on Beta 2... In fact I would have thought this was at all not ready for release.

On a personal observation I could never while using beta 2 to a triple boot like I did with Hardy, I dont know what the devs did though theire hard work I feel sorry to report it needs more polishing.

Hi,

Thanks for your feedback.
Are you sure you found the exact same issue, cause this error message
("ubiquity crashed with InstallStepError in configure_bootloader") is
reported in many bugs but with different causes.
Actually I had also this problem with Hardy install, I was not able to set
up a dual boot with Gutsy (I am still running Gutsy now).

I suspect, though I have not tried yet, that install could work if I
overwrite my Gutsy install, instead of trying to install Intrepid on another
partition. What I cannot understand is why in this configuration, I have 2
/target mount points...

Jérôme.

2008/10/31 X3 <email address hidden>

> Yes I found exact same issue further more upgrade from LTS also failed
> with dozens of errors.
>
> So when I finally decided to do a clean install Grub failed to install
> and resulting in the reported error.
>
> Also worth mentioning that installing from live session will never go
> past the loading partition utility and result in more errors.
>
> 8.10 is definitely worst now then it was when on Beta 2... In fact I
> would have thought this was at all not ready for release.
>
> On a personal observation I could never while using beta 2 to a triple
> boot like I did with Hardy, I dont know what the devs did though theire
> hard work I feel sorry to report it needs more polishing.
>
> --
> ubiquity crashed with InstallStepError in configure_bootloader()
> https://bugs.launchpad.net/bugs/260001
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in "ubiquity" source package in Ubuntu: New
>
> Bug description:
> Binary package hint: ubiquity
>
> This is probably a duplicate of closed/dormant bug 71984, but I have opened
> a new one because it occurred on Intrepid alpha 4 and I want to be sure you
> have an up-to-date set of documentation.
>
> I suspect the crash is caused by my choice of an install that has fallen
> outside the validation box. I was trying to install a standalone intrepid
> system on a new partition of a multiboot machine. However, in manual
> partitioning I did NOT mount the existing grub partition as /boot. I guess
> the install was confused when trying to install another grub boot loader. I
> will retry the installation with the existing /boot mounted.
>
> ProblemType: Crash
> Architecture: i386
> DistroRelease: Ubuntu 8.10
> ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
> InterpreterPath: /usr/bin/python2.5
> Package: ubiquity 1.9.9
> ProcAttrCurrent: unconfined
> ProcCmdline: /usr/bin/python /usr/lib/ubiquity/bin/ubiquity gtk_ui
> ProcEnviron: Error: [Errno 13] Permission denied: '/proc/8007/environ'
> PythonArgs: ['/usr/lib/ubiquity/bin/ubiquity', 'gtk_ui']
> SourcePackage: ubiquity
> Title: ubiquity crashed with InstallStepError in configure_bootloader()
> Uname: Linux 2.6.26-5-generic i686
> UserGroups:
>

limpha (dawson-fnal) wrote :

Hello,
Is this really the place for bugs to go? I haven't seen anyone from Ubuntu give any comment and this bug went right on through to the final release.
This is a critical bug for me. I cannot install Ubuntu with this bug. I have to have it on a different partition from the other linux system. I also want my grub to be on that other drive, not the main drive. I haven't seen any solution or work around at all other than wipe out my main linux distro which I cannot do.
I hate saying "this other distro does it", but RedHat and Fedora have been able to do this for years.

linex83 (linex83) wrote :

I can't believe it this bug hasn't been fixed before the release. It makes the newest release worthless for me.

Brian Burch (brian-pingtoo) wrote :

I have just spent the last 3 hours trying different installation paths using the intrepid desktop CD released yesterday. So far, each install has failed with the same superficial symptoms (reported in the title of this bug).

However, to my surprise, the inode=128 bytes bypass did NOT work for me this time. There seems to be a conflict between the "production" grub boot partition and a self-contained intrepid beta partition with its own grub. I have just done some housekeeping and will try again. If it fails, I will attach the latest logs to this bug.

hjkopel (hjkopel) wrote :

I don't understand these bug reports and how they are grouped. Has anyone gotten the same error message as I on installing Grub and the file "grub_0.97-29ubuntu36_i386.deb ". See Bug #285716.
"Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/g/grup/grub_0.97-29ubuntu36_i386deb" .
To me the install is either looking for the wrong file or the file is not where is should be. I googled the file and it does exist on other locations.
Confused but hopeful...

Brian Burch (brian-pingtoo) wrote :

Well... the housekeeping didn't help - the install still crashed. I guess the failure is due to trying to use an existing grub boot partition. I have some crash reports to append tomorrow.

I have just run a successful install onto an inode=128 partition, but it was necessary to let the installer put /boot on the same partition as the rest of the system. Obviously, that has orphaned my multiboot configuration, so I need to go away and get intrepid booting off my original boot partition next.

X3 (x3lectric) wrote :

Here is how I resolved this issue.

I am runnig a triple boot environment on one HDD I have XP PRO/Vista Ultimate SP1 with a modivied BCD (vista boot loader alomost like grub really) Vista want to take control and Ubuntu wants to take control... its a battle. Ubuntu resides on the secondary slave drive with it s own swap space.

Previously with no issues I altered the Vista BCD to include XP/Vista/Ubuntu hardy and when I slected hardy i was passed to the grub loader. all was fine.

enter IBEX

Upgrading in my case failed miserably CD had no errors and all was fine, fresh install failked as well with this error so determined I decided to win I had to let UBUNTU grub do the job I also had a sata drive which I unplugged for some reason IDE/sata mix during install for me is a no no.

I proceeded to formats the slave HDD completley and then install with a completly pre formated HDD, result no errors, Except now I have to boot Linux by default and loog at that ugly grub menu (regardless of what you do its still ugly and clumbsy) now I boot all 3 but made the slave drive be the first bootable device in bios, had I not done that, selecting UBUNTU form the vista bcd load the grub for dos with anerro and shows a grub>

Never got that why...

I got mine working at last though disapointed since openoffice is stil 2.4 not 3.0 and TBH besides a few fixes I rather have staid with 8.4.0.1LTS and you really dont have that much else going for it nothing looks inovative....

Sorry for the offtopic bit.

D Koranek (dkoranek) wrote :

I resolved the issue, as well, but I'm not sure how.

Originally, my system configuration was a triple boot environment (Vista, XP, Ubuntu 7.10), but my XP partition went corrupted, so I bought a new hard drive to install XP and Ubuntu 8.10 on.

In anticipation of how my hard drive was going to be laid out, I created two NTFS partitions on my new hard drive (80 GB apiece) and installed Windows XP on the first partition because Intrepid hadn't been released yet.

I tried to install Hardy on the second NTFS partition (formatting it to ext3) but Hardy failed during the installation process, saying that there had been an error in setting up grub. When Intrepid was released, it produced the same error during install.

Having had some experience setting up grub during a previous grub failure, I tried setting up grub manually; however, grub consistently was unable to find /boot/grub/stage1 (producing errors 15 and 17). Even with a grub boot disk, grub refused to set up a bootloader.

I noticed an error documented in some forums regarding 128-byte/256-byte inode compatibility with grub. I formatted the partition using 128-byte inodes and retried installing Ubuntu without reformatting the partition. Ubuntu failed again due to the same grub error.

The last thing I tried was letting Ubiquity re-partition the partition that I had originally intended to install on (splitting the partition in the process, creating 77 and 3 Gb partitions). When it finished setup, it installed grub on the disk without any problem.

I don't know what might have caused this, but I hope it's helpful.

Brian Burch (brian-pingtoo) wrote :

I know it is off-topic, but a lot of people are coming here because they are suffering from this bug. I have attached a quick-n-dirty checklist on how to get back to your multi-boot setup after a successful install of intrepid as a self-contained system.

Brian Burch (brian-pingtoo) wrote :

The crash reports for my failed installations. Is the problem related to the boot partition having been setup under hardy (0.97-29ubuntu21) while intrepid install is using 0.97-29ubuntu45?

ForeverNoob (yoav-benyosef) wrote :

Just had that crush when trying to install Interpid. I created a 8GB ReiserFS (/dev/sdb1) on my second HD for / partition, a 20GB ReiserFS (/dev/hdb2) for /home and directed bootloader to install on /dev/sdb1.

I didn't have a problem installing Hardy using same partitioning except that I used ext3 and not ReserFS.

a2d2 (a2d205) wrote :

new final intrepid xubuntu install cd, 2.6.27.7 from yesterday crashed during hd-install, just starting installing grub. got same error, using late beta version of intrepid ubuntu 8.10. read in ubuntuusers.de, error is solved and recognized, it's still alive.
what to do, now ???

use 4 systems on my samsung laptop R50, SIDUX, Xubuntu 8.04, XP and new xubuntu 2.6.27.7, which is now unusable within GRUB.

...have a nice weekend :)

ForeverNoob (yoav-benyosef) wrote :

Tried installing again with the same partitioning scheme, only now I used ext3 instead of ReiserFS. It worked fine.

luvr (luc-vanrompaey) wrote :

Looks to me like GRUB doesn't want to be installed onto the Boot Block of a partition; it wants to be installed onto the Master Boot Block of a disk.

Now, when you manually install GRUB onto the Boot Block of a partition (using the GRUB "setup" command), it displays a warning about being unable to write some stuff out (I believe it's a message about stage 1.5, for which there is no room when you install it onto a Boot Block), but it clearly states that this failure is not fatal.

Perhaps the installer picks up this warning and "promotes" it into an error?

Anyway, I have now been able to install Intrepid Ibex, with GRUB going to the Master Boot Record of what this Ubuntu release calls "(hd0)" in GRUB terms. My BIOS, however, sees it as the second (NOT the first) harddisk. This disagreement has the fortunate side-effect that my EXISTING Master Boot Record wasn't touched; UNfortunately, though, booting the 8.10 system is now somewhat clumsy, since I have to select the second harddisk as the boot disk whenever I want to run Ubuntu 8.10.

Having said that, I would now like to install GRUB onto the Boot Block of the 8.10 root partition, so I can continue to make my main GRUB (installed onto the Master Boot Block of my first harddisk) link to it via chainloading.

luvr (luc-vanrompaey) wrote :

My suspicion that GRUB won't install onto the Boot Block of a partition, doesn't turn out to hold water.

I did a reinstall with GRUB on the Boot Block of the root partition, and this time it worked fine.
The difference: This time I installed everything into one single partition; I did not configure "/home" to go onto a separate partition.

So, the first scenario that I tried, did not work: Setting up a root partition with a separate "/home" partition, and installing GRUB onto the Boot Block of the root partition.

Two other scenarios did work:
(1) Install everything into one single partition (no separate "/home"), and installing GRUB onto the Master Boot Record of (what Ubuntu 8.10 sees as) my first harddisk.
(2) Install everything into one single partition (no separate "/home"), and installing GRUB onto the Boot Block of the root partition.

***A LITTLE BACKGROUND INFORMATION ON MY HARDDISK CONFIGURATION***

There are four harddisks in this computer: One IDE, and three S-ATA drives.

The IDE drive is in the "slave" position on the IDE cable (the "master" is my DVD-RW).
Both the BIOS and Ubuntu 8.04 consider it to be the FIRST harddisk.
Ubuntu 8.04 calls it "/dev/hdb". Ubuntu 8.10, on the other hand, considers it to be the FOURTH (last) harddisk, and calls it "/dev/sdd".
Since the BIOS considers this to be the FIRST harddisk, the system will boot from the Master Boot Record of this disk by default.

My Ubuntu root partition sits on the first S-ATA drive.
Both the BIOS and Ubuntu 8.04 consider this to be the SECOND harddisk.
Ubuntu 8.10 considers it to be the FIRST harddisk.
Both Ubuntu releases will call it "/dev/sda".
Since Ubuntu 8.10 considers it to be the FIRST harddisk, it will set up GRUB on the Master Boot Record of this disk by default. In this scenario, I will have to select this disk as my boot disk (from the BIOS boot screen) whenever I want to run Ubuntu 8.10.

My Ubuntu "/home" partition (which I am currently not using) sits on the second S-ATA drive.
Ubuntu 8.04 considers this to be the THIRD harddisk.
Ubuntu 8.10 considers this to be the SECOND harddisk.
Both Ubuntu releases will call it "/dev/sdb".
(I believe, that BIOS considers it to be the FOURTH drive, but I would have to verify to be sure.)
The "/home" partition is actually the second partition on this disk; the first one is a 2-GB Linux swap partition. There's also empty space following the partitions.

The third S-ATA drive ("/dev/sdc" for both Ubuntu releases) currently only has a 2-GB Linux swap partition; the rest of the space is empty.

Slash Network (slash-network) wrote :

I've tried installing intrepid 64 bit in one partion but it failed (I have hardy installed in an other one).
I've resized the inode size from 256 to 128 and it fail again.
What it can be done now ?

Duplicated bug with attachement in Bug #293280.

Brian Burch (brian-pingtoo) wrote :

So far as I know, the inode=256 issue is no longer significant. It was the way to deal with the problem when I first encountered it on intrepid alpha 4.

With the intrepix release, again as far as know, there is ONLY one way to go forward. You must install a self-contained intrepid partition, complete with its own /boot with grub installed. This zaps your partition table so only intrepid (and perhaps windoze) will boot. You then have to manually re-activate the multi-boot partiton that you used previously and merge the intrepid entries into menu.lst. (refer to my attachment http://launchpadlibrarian.net/19176065/multiBoot.txt).

a2d2 (a2d205) wrote :

hi, folks,
my experience from actual testing is:

install x(ubuntu) 8.10 final as OEM version (think its F4). I created a reiserfs system.
...and it works really successful, installing GRUB - without any ubiquity bug...

greets from germany....and god bless obama !!!

Joao Clemente (jpcl) wrote :

How about the statement from Jerome G
"What I cannot understand is why in this configuration, I have 2 /target mount points..."
I actually noticed that in my case I had 3 /target mount points mounted at the same time, to different partitions...
Could it be commin that all of us are using multiboot environments, or at least multiple partitioned environments? Me personally have a setup with some 10 partitions, 4 of them being each one with its one version of 8.04 desktop, 8.04 server, 8.10 server and now I was setting up 8.10 desktop....
As a sidenote, the 8.10 server installed fine with the same number of partitions.
Regards

Brian Burch (brian-pingtoo) wrote :

Joao - this has been my assumption from the outset. I've done several intrepid alpha installs as self-contained systems because it was the only way I could install it. I've tried multi-boot installs on 3 different machines so far and hit the same problem. I think that is why we are the only people suffering - those doing upgrades or clean installs are not seeing this bug.

a2d2 - that is strange, but I admit I've only tried ext3 installs because I don't want reiserfs. I see above that you have a multi-boot system, but I don't understand how switching to a different root filesystem could impact the setup of grub on your existing boot partition, which is presumable ext3.

Brian Burch (brian-pingtoo) wrote :

I think this problem might be caused by the existing grub multiboot partition being back-level compared to the expectations of the intrepid installer, but I don't know enough to investigate further.

I noticed that when I merged the intrepid grub menu.lst boot lines back into my existing hardy-based grub boot partition, then intrepid would not boot. The grub boot error was because intrepid uses the "new" UUID grub statement, but the hardy grub does not recognise it and so cant boot the intrepid image. I simply reverted the intrepid statements to the "old" syntax and intrepid multi-boots fine.

luvr (luc-vanrompaey) wrote :

In my case, it cannot be a question of "the existing grub multiboot partition being back-level," because I install GRUB into the root partition that I'm creating. I even install the GRUB boot loader ("stage1") into the Boot Block of the root partition (NOT in the Master Boot Block--I use a custom-compiled GRUB as my Master Boot Loader, and let it chainload to whichever partition that I want to boot.

In my case, the problem is that I'm trying to set up "/home" as a separate partition--that won't work either.

It seems to me that intrepid will fail unless you install EVERYTHING into one partition--including "/boot", "/home", and whichever locations for you might wish to use a separate partition.

Anyway, I have circumvented the problem by initially setting up a single, self-contained root partition, and afterwards moving "/home" into its own partition.

MichiGreat (michi20091979) wrote :

Hi everyone!

I tried the hint from a2d2, but with no success. Ubiquity crashed and was not impressed by reiserfs.

However, I worked around this problem by doing the following: In VMware (under Win XP), I installed Ubuntu 8.10 x64 in a virtual machine. Then I copied the initrd.img file to the host, booted into my working Ubuntu 8.04, and copied the initrd.img file to the parition of Ubuntu 8.10. Then I modified my menu.lst and voilà... Ubuntu 8.10 boots!

If anyone is interested in my initrd.file, I published it here:

http://temp.mkcs.at/linux/initrd.img-2.6.27-7-generic

I guess it should work for all Ubuntu 8.10 x64 installations.

MichiGreat (michi20091979) wrote :

Ooops, I have just seen that the IIS reports a 404 on the file because it doesn't know the file "extension". I now put one to it:

http://temp.mkcs.at/linux/initrd.img-2.6.27-7-generic.bin

So, if anyone downloads this file, be aware of removing the ".bin" at the end of the filename!

I would be happy about feedback on my solution.

1 comments hidden view all 101 comments
Slash Network (slash-network) wrote :

Exellent MichiGreat ! Great job ! I was desesperate, I trayed many solutions but failed every time. The issue was fixed for me. Thank you very much, I hope that the file will be available as long as possible :)

Jérôme G (jgoudey) wrote :

I managed to install Intrepid at last using the Alternate CD on my multi-boot configuration.
Grub installs fine, and all my systems are properly detected and bootable (Win XP, Hardy, Intrepid).
Still had no solution with the standard desktop CD.

Herman Felderhof (herman543) wrote :

I have made several installs in the same computer with the Intrepid 'Desktop' CD.
I used one partition for / every time, with the Reiser File System.
Every time I allow GRUB to be installed to (hd0) everything works fine.
Every time I select to have GRUB installed to /dev/sda2, ( I want to chainload it from my dedicated GRUB partition), I have this problem, (crash in ubiquity at grub-install).

For me it's a minor nuisance but nothing difficult to deal with.
I just perform a direct boot from GRUB's Command Line Interface, http://users.bigpond.net.au/hermanzone/p15.htm#First_method:_direct_kernel_boot.
Then when Intrepid is up and running run 'sudo update-grub' to make a menu.lst automatically, and install GRUB to the boot sector of the partition.

I have read of one person not having an initrd.img, another way that can be fixed using the 'Desktop' Live CD to chroot into the installation and running 'mkinitramfs', as in this link, http://ubuntuforums.org/showthread.php?t=979311&highlight=Cannot+boot+Ibex-ubiquity+crash+during+install&page=2

tags: added: apport-crash
removed: rapport-crash
21 comments hidden view all 101 comments
mlmartin (michael-mlmartin) wrote :

I ran with the no-migration-assistant and it again did not work. I again ran with the -d debug option.

Find attached my log files from /var/log/syslog and /var/log/installer/debug.

ricardisimo (ricardisimo) wrote :

"I reinstalled with the alternate CD, same error message, then was able
to install lilo (its the next option that comes up after grub fails)."

So, did you somehow complete installation? How did you get past the installation shut-down and the LiveCD session?

I do appear to have a Linux partition and swap on the new disk, just no GRUB. How, when and where does one run grub-install? In a terminal during a Live session? Would it look like this: "grub-install hd0"?

ricardisimo (ricardisimo) wrote :

Indeed, perhaps the 1.5TB problem merits having it's own bug report.

Has anyone seen these pages:
http://www.gnu.org/software/grub/manual/html_node/Installing-GRUB-using-grub_002dinstall.html
and http://www.gnu.org/software/grub/manual/html_node/Device-map.html#Device-map

Although I'm a level 9 Thetan-noob, I'm still, in fact, a noob. So I would definitely need a step-by-step from one of the Party Elders. Also, I don't have ready access to a working Ubuntu comp so as to get a good look at what a functioning GRUB is supposed to look like. Any help? Thanks.

ricardisimo (ricardisimo) wrote :

By the way, the exact line is:
sudo ubiquity --no-migration-assistant
I'm going to try it right now. Wish me luck!

ricardisimo (ricardisimo) wrote :

SUCCESS!!!

Either the third time really is a charm (unlikely) or disabling migration assistant does the job. Good luck to everyone else. Let me know if you need me to upload anything.

The alternate cd doesn't actually crash, it gives you the same error
message but instead of completely halting, it sends you to a text
message with the option to install lilo instead (which works) or
continue without any boot-loader.

ricardisimo wrote:
"
> So, did you somehow complete installation? How did you get past the
> installation shut-down and the LiveCD session?
>

PsYcHoK9 (psychok9) wrote :

I've installed many times ubuntu on my "fake" Raid 0 Intel ICH10 (P5Q Deluxe).
Any time, i type on the terminal "sudo apt-get install dmraid", I click on Install and Ubiquity crash in the end of setup process.
I reboot my pc, again "sudo apt-get install dmraid"... and I do a manual installation of grub:
sudo apt-get install dmraid
ls /dev/mapper
sudo mkdir /target
sudo mount /dev/mapper/isw_daeghacjej_Raid2 /target
sudo mount --bind /dev /target/dev
sudo mount -t proc proc /target/proc
sudo mount -t sysfs sys /target/sys
sudo chroot /target
apt-get update
apt-get install dmraid
apt-get install grub --reinstall
mkdir /boot/grub
cp /usr/lib/grub/x86_64-pc/* /boot/grub
grub --no-curses

       [ Minimal BASH-like line editing is supported. For
         the first word, TAB lists possible command
         completions. Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub> device (hd0) /dev/mapper/isw_daeghacjej_Raid
grub> find /boot/grub/stage1
grub> root (hd0,1)
grub> setup (hd0)
grub> quit
quit

update-grub
nano /boot/grub/menu.lst
Changed the '# groot=(hd0,0)' to '# groot=(hd0,x)' (using the partition you found earlier, again).
update-grub

I hope that soon I can install Ubuntu WITHOUT this long process.

> update-grub
> nano /boot/grub/menu.lst
> Changed the '# groot=(hd0,0)' to '# groot=(hd0,x)' (using the partition you found earlier, again).
> update-grub
>
> I hope that soon I can install Ubuntu WITHOUT this long process.

Loose your hopes, it's many year bugs like this are open and nobody cares.

OS/2-User (fzf7a2c02) wrote :
Download full text (3.3 KiB)

With the little understanding I have so far of Linux, according to my SysLog this is where grub-install screws up (/sda8 & /sda9 being IBM's JFS):

######################################
Apr 29 04:55:06 ubuntu grub-installer: info: Installing grub on '/dev/sda9'
Apr 29 04:55:06 ubuntu grub-installer: info: grub-install supports --no-floppy
Apr 29 04:55:06 ubuntu grub-installer: info: Running chroot /target grub-install --no-floppy "/dev/sda9"
Apr 29 04:55:08 ubuntu grub-installer: Probing devices to guess BIOS drives. This may take a long time.
Apr 29 04:55:09 ubuntu grub-installer: Searching for GRUB installation directory ... found: /boot/grub
Apr 29 04:55:15 ubuntu grub-installer: Installing GRUB to /dev/sda9 as (hd0,8)...
Apr 29 04:55:16 ubuntu grub-installer:
Apr 29 04:55:16 ubuntu grub-installer: [ Minimal BASH-like line editing is supported. For
Apr 29 04:55:16 ubuntu grub-installer: the first word, TAB lists possible command
Apr 29 04:55:16 ubuntu grub-installer: completions. Anywhere else TAB lists the possible
Apr 29 04:55:16 ubuntu grub-installer: completions of a device/filename. ]
Apr 29 04:55:16 ubuntu grub-installer: grub> root (hd0,8)
Apr 29 04:55:16 ubuntu grub-installer: grub> setup --stage2=/boot/grub/stage2 --prefix=/boot/grub (hd0,8)
Apr 29 04:55:16 ubuntu grub-installer: Checking if "/boot/grub/stage1" exists... yes
Apr 29 04:55:16 ubuntu grub-installer: Checking if "/boot/grub/stage2" exists... yes
Apr 29 04:55:16 ubuntu grub-installer: Checking if "/boot/grub/jfs_stage1_5" exists... yes
Apr 29 04:55:16 ubuntu grub-installer: Running "embed /boot/grub/jfs_stage1_5 (hd0,8)"... 18 sectors are embedded.
Apr 29 04:55:16 ubuntu grub-installer: succeeded
Apr 29 04:55:16 ubuntu grub-installer: Running "install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0,8) (hd0,8)1+18 p (hd0,8)/boot/grub/stage2 /boot/grub/menu.lst"... failed
Apr 29 04:55:16 ubuntu grub-installer:
Apr 29 04:55:16 ubuntu grub-installer: Error 6: Mismatched or corrupt version of stage1/stage2
Apr 29 04:55:16 ubuntu grub-installer: grub> quit
Apr 29 04:55:16 ubuntu grub-installer: error: Running 'grub-install --no-floppy "/dev/sda9"' failed.
Apr 29 04:58:13 ubuntu python: log-output -t ubiquity umount /target/cdrom
Apr 29 04:58:13 ubuntu finish-install: Disabling CD in sources.list
Apr 29 04:58:13 ubuntu python: Exception during installation:
Apr 29 04:58:13 ubuntu python: Traceback (most recent call last):
Apr 29 04:58:13 ubuntu python: File "/usr/share/ubiquity/install.py", line 2225, in <module>
Apr 29 04:58:13 ubuntu python: install.run()
Apr 29 04:58:13 ubuntu python: File "/usr/share/ubiquity/install.py", line 435, in run
Apr 29 04:58:13 ubuntu python: self.configure_bootloader()
Apr 29 04:58:13 ubuntu python: File "/usr/share/ubiquity/install.py", line 1659, in configure_bootloader
Apr 29 04:58:13 ubuntu python: "GrubInstaller failed with code %d" % ret)
Apr 29 04:58:13 ubuntu python: InstallStepError: GrubInstaller failed with code 1
Apr 29 04:58:13 ubuntu python:
######################################

Why/how is this failure happening and what do I need to do, in order to ...

Read more...

Andrew Smart (andrew.j.smart) wrote :

If you are installing to a raid partition, heed this:

PsYcHoK9 said:
> I've installed many times ubuntu on my "fake" Raid 0 Intel ICH10 (P5Q Deluxe).
> Any time, i type on the terminal "sudo apt-get install dmraid", I click on Install and Ubiquity crash in the end of setup > process.
> I reboot my pc, again "sudo apt-get install dmraid"... and I do a manual installation of grub:
> sudo apt-get install dmraid
> ...
> I hope that soon I can install Ubuntu WITHOUT this long process.

Thanks PsYcHoK9, I forgot about that. I've been having this problem as well ever since I've used ubuntu, starting with Ubuntu 7.10.

The live install of Ubuntu 9.10 failed for me as well "ubiquity crashed with InstallStepError in configure_bootloader()".

It seems to me that a lot of people that have responded to this bug have tried to install to a raid partition. Others have not. Shouldn't there be separate bugs?

If you are trying to install to a raid array, see:
https://help.ubuntu.com/community/FakeRaidHowto

Also note:
https://help.ubuntu.com/community/FakeRaidHowto#Installing%20to%20RAID5%20array%20with%20Ubuntu%209.04%20Live%20CD
"Once dmraid is running, the live installer can handle installing to the raid. _Ubiquity will fail when installing grub_, and will not automatically add dmraid to the new installation."

Andrew Smart (andrew.j.smart) wrote :

In addition to my last comment, looks like the alternate install CD as of intrepid supports installing to a raid partition NOT the live CD:
https://help.ubuntu.com/community/FakeRaidHowto#Method%201

OS/2-User (fzf7a2c02) wrote :

I just found out, that my Jaunty installation problem is an exact déjà-vu of the 2007 bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/123102/comments/5 (which itself links back as early as 2005 to Bug #14010) in terms of the relevant grub-installer syslog section and I'm almost willing to bet, that it still has the very same, still unfixed cause as it did FOUR years ago.

Why does nobody seem to care to fix show-stopper bugs like this, preventing nothing but Ubuntu's installation itself?
Why does everybody seem to care only about the latest gimmicks and eye-candy being added to the desktop, while the foundation obviously is still partly made out of flaky plywood?

That btw. recalls fond memories of the Win-95 alleged luxury penthouse sitting on top of a flimsy DOS shack (cudos to c't computer magazine's editorial of that time) ;-)

How many decades more does it take, before finally someone in charge cares enough to take on this assignment and fixes this nasty bug for Ubuntu once and for all?

Colin Watson (cjwatson) wrote :

OS/2-User: because the things you say are largely not true; I understand your frustration but your comments do not help. There are of course a number of people working on eye-candy-type things in Ubuntu, but there are also lots of people like me working on the foundations (I don't do anything that you could remotely describe as eye-candy).

You are probably being misled by the fact that the automatic bug-duplication system is a bit oversensitive here. It's unlikely that your bug is actually the same as this one at all.

The fact that we have bug reports in which everybody heaves in enthusiastically to report their own different failure to install the boot loader is one reason why exactly those bug reports have trouble getting fixed! I can't wave a magic wand and make everyone's boot loader installation work. I *can* work on specific, targeted failures. But when you say "show-stopper bugs like this", what you're actually referring to is a horrifically long bug history with 73 comments which actually includes comments about many different individual failures, most of which only affect small numbers of people (though obviously they are show-stoppers for those individual people).

Frankly, at this point I have some trouble even making out whether the original reporter still has a problem that's identifiably a bug (as opposed to configuration mistakes with multiboot setups, such as trying to use a menu.lst that uses UUIDs with an older grub installation that doesn't). https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/260001/comments/33 suggests that it works fine provided that he either uses a version of grub new enough to understand the relevant menu.lst syntax, or reverts the menu.lst syntax to cope with the older version of grub. Most of the people who added comments to this bug do *not* have the same problem as the original report. It's sad but true: I stand a better chance of making real progress if I work on better-defined bugs.

I'll split your bug report back out from this one, and look at it separately.

Colin Watson (cjwatson) wrote :

I've asked the maintainer of the auto-duplication code to blacklist this bug, so we shouldn't get bug reports being automatically (and usually incorrectly) marked as duplicates of this one in future.

cdriga (cdriga) wrote :

When it crashed my first suspicion was about the root partition which was at the end of the disk (a 320Gb hdd). I was trying to install as a secondary ubuntu for testing and had space only at the end of disk.

I made space at the beginning of the disk (in the first 40Gb anyway) and i never encountered this error since then.

Thanks for your helpful comments, Colin.

I was the original poster and you are quite correct, my comment number
33 closed the issue as far as I was concerned. It didn't fix the bug,
but I reported an acceptable bypass as far as I was concerned.

There is something funny about installing a new intrepid/jaunty image on
an existing grub multiboot system where hardy LTS is the current
maintainer of the grub partition.

I'd like to help you, but I can't currently reproduce the problem. My
original system was NOT a raid installation - it was on a laptop.

I recently upgraded a hardy LTS raid1 system using the intrepid
alternate CD... I decided to do the upgrade direct, rather than as a
multiple boot. I simply powered off the mirror hard disks so that I
could instantly go back to Hardy if anything serious went wrong... the
upgrade worked well. Although I had a lot of minor issues to fix, the
grub upgrade worked perfectly, so I zapped the offline mirrors'
superblocks and added them back into the (intrepid) active/degraded arrays.

I think it is a good idea to split some of these "duplicates" into new
bugs, because I've reviewed quite a few that sounded fairly different.
However, I don't know where you would start, so I thought I would mark
your comment and mine as the end of a chapter (at least).

Regards,

Brian

regomodo (regomodo) wrote :

I'm having the same issue. System setup
Trying to install 9.04 amd64 from livecd onto nvraid, raid0.
Root partition is ext4 and home partition is xfs on the same disk within an extended partition.

Ubiquity seems to crash after the "scanning the mirror" section of the install.

David (david-myers57) wrote :

My setup is 2 x 1TB SATA disks configured as Raid 1. 500GB primary partition has Vista Ultimate 64bit installed. I wanted the rest of the volume for Ubuntu 9.04 amd64, but couldn't get it to install via ubiquity without crashing. I have got it to work ok using the Alternate CD. This recognises the raid set up, and it installs with no problem. Afterwards, though, I had to edit /etc/grub/menu.lst to add Windows as an option on boot up.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of regomodo
Sent: 25 May 2009 19:54
To: <email address hidden>
Subject: [Bug 260001] Re: ubiquity crashed with InstallStepError in configure_bootloader()

I'm having the same issue. System setup
Trying to install 9.04 amd64 from livecd onto nvraid, raid0.
Root partition is ext4 and home partition is xfs on the same disk within an extended partition.

Ubiquity seems to crash after the "scanning the mirror" section of the
install.

--
ubiquity crashed with InstallStepError in configure_bootloader()
https://bugs.launchpad.net/bugs/260001
You received this bug notification because you are a direct subscriber
of the bug.

Status in “ubiquity” source package in Ubuntu: New

Bug description:
Binary package hint: ubiquity

This is probably a duplicate of closed/dormant bug 71984, but I have opened a new one because it occurred on Intrepid alpha 4 and I want to be sure you have an up-to-date set of documentation.

I suspect the crash is caused by my choice of an install that has fallen outside the validation box. I was trying to install a standalone intrepid system on a new partition of a multiboot machine. However, in manual partitioning I did NOT mount the existing grub partition as /boot. I guess the install was confused when trying to install another grub boot loader. I will retry the installation with the existing /boot mounted.

ProblemType: Crash
Architecture: i386
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
InterpreterPath: /usr/bin/python2.5
Package: ubiquity 1.9.9
ProcAttrCurrent: unconfined
ProcCmdline: /usr/bin/python /usr/lib/ubiquity/bin/ubiquity gtk_ui
ProcEnviron: Error: [Errno 13] Permission denied: '/proc/8007/environ'
PythonArgs: ['/usr/lib/ubiquity/bin/ubiquity', 'gtk_ui']
SourcePackage: ubiquity
Title: ubiquity crashed with InstallStepError in configure_bootloader()
Uname: Linux 2.6.26-5-generic i686
UserGroups:

linex83 (linex83) wrote :

It's fine, no one cares, the time of a few hundreds Ubuntu users is not important at all, let's waste it and never fix this bug.

regomodo (regomodo) wrote :

I managed to fix it.
Booted into my Gentoo box.
Changed my menu.lst to include Ubuntu's setup.
Rebooted into Ubuntu. For some f***ing reason Ubiquity never pulled in dmraid into the install despite being able to see the nvraid setup.
Rebooted into my Gentoo setup.
Chrooted into the Ubuntu partition.
apt-get update/upgrade (no idea why Ubiquity didn't do this in the install. Debian Etch even did that.)
Installed dmraid.
Reboot.
Presto. It works! Except now Firefox continously wants to restart and Zydas wireless support is very flaky. God knows how Ubuntu manages it.
Close enough I guess. At least this is the first of 5 machines that doesn't have pulseaudio issues.

RenHoek (ivo-palli) wrote :

Installing on a 1.5TB SATA disk, Ubuntu 9.04, installer crashed.

Running from the commandline:

root@ubuntu:/target/boot/grub# grub-install --root-directory=/target /dev/sda
grub-probe: error: Cannot open `/boot/grub/device.map'
[: 494: =: unexpected operator
The file /target/boot/grub/stage1 not read correctly.

root@ubuntu:/target/boot/grub# chroot /target
root@ubuntu:/# grub-install /dev/sda
Searching for GRUB installation directory ... found: /boot/grub
The file /boot/grub/stage1 not read correctly.

stage1 file exists.. I'm trying to put the Linux partition in the last 30GB of the 1.5TB disk, I suspect it's a cylinder limit problem.

RenHoek (ivo-palli) wrote :

After poking about a bit, I found this. 'grub-install /dev/sda' calls grub:

/usr/sbin/grub --batch --device-map=/boot/grub/device.map
grub> dump (hd0,2)/boot/grub/stage1 /tmp/grubX4px17
Error 18: Selected cylinder exceeds maximum supported by BIOS

Which is weird, because I have a fairly top-of-the-line and recent Shuttle XPC. Only difference is that I now have a really large disk in there. LBA addressing should be on in the BIOS, I'll have to check, but maybe it's to big for even LBA?

Disk is set up like this btw.. [ntfs 1.4TB] [swap 512MB] [ext3 30GB]

I guess you could get around this by putting a '/boot' partition of say 64Mb or so on the beginning of the disk, but isn't there a way around this?

Kjow (antispammoni) wrote :

Ubiquity crashes in my system (Core i7 920 + Gigabyte EX58-Extreme [ICH10R] + Seagate 500Gb 7200.12 x2 [Raid0]).

To load the Ubuntu 9.04 Live CD/DVD I must hit F6 at boot menu and add to the end:

libata.ignore_hpa=0

so I can see my Raid0 and after reboot I haven't the Raid0 failure. (Without libata.ignore_hpa=0 I have the Raid0 Offiline).

I tried Ubuntu 9.10 Alpha3 but it crashes before load the splashscreen:

ata8.01: COMRESET failed (errno=-5)
ata8.01: reset failed, giving up
...
ata8.02: COMRESET failed (errno=-5)
ata8.02: reset failed, giving up
...
ata8.03: COMRESET failed (errno=-5)
ata8.03: reset failed, giving up
...

(see attachment)

so I can't try Ubuntu 9.10...

I'll try with manual installation and if it fail again... I'll use virtualbox on Win7 rc :(

Fuck off
Sent from my BlackBerry® wireless device

-----Original Message-----
From: Kjow <email address hidden>

Date: Wed, 02 Sep 2009 12:43:25
To: <email address hidden>
Subject: [Bug 260001] Re: ubiquity crashed with InstallStepError in
 configure_bootloader()

Ubiquity crashes in my system (Core i7 920 + Gigabyte EX58-Extreme
[ICH10R] + Seagate 500Gb 7200.12 x2 [Raid0]).

To load the Ubuntu 9.04 Live CD/DVD I must hit F6 at boot menu and add
to the end:

libata.ignore_hpa=0

so I can see my Raid0 and after reboot I haven't the Raid0 failure.
(Without libata.ignore_hpa=0 I have the Raid0 Offiline).

I tried Ubuntu 9.10 Alpha3 but it crashes before load the splashscreen:

ata8.01: COMRESET failed (errno=-5)
ata8.01: reset failed, giving up
...
ata8.02: COMRESET failed (errno=-5)
ata8.02: reset failed, giving up
...
ata8.03: COMRESET failed (errno=-5)
ata8.03: reset failed, giving up
...

(see attachment)

so I can't try Ubuntu 9.10...

I'll try with manual installation and if it fail again... I'll use
virtualbox on Win7 rc :(

** Attachment added: "Ubuntu9.10_Live_Error.JPG"
   http://launchpadlibrarian.net/31225459/Ubuntu9.10_Live_Error.JPG

--
ubiquity crashed with InstallStepError in configure_bootloader()
https://bugs.launchpad.net/bugs/260001
You received this bug notification because you are a direct subscriber
of the bug.

Status in “ubiquity” package in Ubuntu: New

Bug description:
Binary package hint: ubiquity

This is probably a duplicate of closed/dormant bug 71984, but I have opened a new one because it occurred on Intrepid alpha 4 and I want to be sure you have an up-to-date set of documentation.

I suspect the crash is caused by my choice of an install that has fallen outside the validation box. I was trying to install a standalone intrepid system on a new partition of a multiboot machine. However, in manual partitioning I did NOT mount the existing grub partition as /boot. I guess the install was confused when trying to install another grub boot loader. I will retry the installation with the existing /boot mounted.

ProblemType: Crash
Architecture: i386
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
InterpreterPath: /usr/bin/python2.5
Package: ubiquity 1.9.9
ProcAttrCurrent: unconfined
ProcCmdline: /usr/bin/python /usr/lib/ubiquity/bin/ubiquity gtk_ui
ProcEnviron: Error: [Errno 13] Permission denied: '/proc/8007/environ'
PythonArgs: ['/usr/lib/ubiquity/bin/ubiquity', 'gtk_ui']
SourcePackage: ubiquity
Title: ubiquity crashed with InstallStepError in configure_bootloader()
Uname: Linux 2.6.26-5-generic i686
UserGroups:

Kjow (antispammoni) wrote :

???

linex83 (linex83) wrote :

this bug also affects Ubuntu 9.10 Alpha 6 (amd64)

Kjow (antispammoni) wrote :

Idem to 9.10 RC... I think that this bug will never fixed...

Rob M (robert-mollard) wrote :

Nov 6 04:07:37 ubuntu grub-installer: info: Installing grub on '(hd0)'
Nov 6 04:07:37 ubuntu grub-installer: info: grub-install supports --no-floppy
Nov 6 04:07:37 ubuntu grub-installer: info: Running chroot /target grub-install --no-floppy "(hd0)"
Nov 6 04:07:40 ubuntu grub-installer: grub-probe: error: unknown filesystem
Nov 6 04:07:40 ubuntu grub-installer: Auto-detection of a filesystem module failed.
Nov 6 04:07:40 ubuntu grub-installer: Please specify the module with the option `--modules' explicitly.
Nov 6 04:07:40 ubuntu grub-installer: error: Running 'grub-install --no-floppy "(hd0)"' failed.
Nov 6 04:07:53 ubuntu python: log-output -t ubiquity umount /target/cdrom

oster (wichanburi) wrote :

I downloaded ubuntu 9.10 amd 64Bit, two times and checked the disc without any errors. At the time, installation is almost finished (94%), I become the error message --Can't install the grub-pc Packet in the /target/ folder.--
I had already a 9.10 amd 64 bit installed and everything worked fine, but now I have the same problem with Jaunty too.

Evan Dandrea (ev) wrote :

This is somewhat mitigated as of ubiquity 2.1.0 in lucid. On bootloader installation failure, the installer now presents a dialog allowing the user to retry grub installation on a different device.

linex83 (linex83) wrote :

I expected to get this problem with Ubuntu 10.04 beta1, but frankly it worked.

Oddround (oddround) wrote :

ubuntu@ubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
aufs 1005M 54M 952M 6% /
udev 1005M 256K 1005M 1% /dev
/dev/sr0 691M 691M 0 100% /cdrom
/dev/loop0 666M 666M 0 100% /rofs
none 1005M 100K 1005M 1% /dev/shm
tmpfs 1005M 16K 1005M 1% /tmp
none 1005M 88K 1005M 1% /var/run
none 1005M 4.0K 1005M 1% /var/lock
none 1005M 0 1005M 0% /lib/init/rw
/dev/mapper/nvidia_bjbibcia1
                      288G 2.2G 271G 1% /target
This /dev/mapper/nvidia_bjbibcia1 is a hardware RAID1 system and ubuntu 9.10 failed to install GRUB on this.
Hardware RAID mirror is HEALTHY.

Oddround (oddround) wrote :

Additional info. : may I suggest that possibly this is due to not having a full RAID card but using the on board RAID of my motherboard. PC is an Acer T180.
This bug appears to be consistent with this "FakeRAID" web-site (below) and following the instructions I was able to RAID my machine.

https://help.ubuntu.com/community/FakeRaidHowto

Hope this doesn't add confusion to the issue.

MichiGreat (michi20091979) wrote :

If someone encounters the missing initrd file in Ubuntu 11.04 Beta 1 x86 (like I did recently), here is the initrd-file to download (like I did with Ubuntu 8.10 x64):

http://temp.mkcs.at/linux/ubuntu-1104-natty/initrd.img-2.6.38-7-generic.bin

May be someone could submit the x64 version of the initrd (in case if there are differences).

HTH someone else

tags: added: ubiquity-1.10.10
tags: added: intrepid

Thank you for taking the time to report this bug and helping to make Ubuntu better. Reviewing your log files attached to this bug report it seems that there is a problem with your installation media (CD/DVD). Please retry your installation with new media and if it still fails I'd recommend testing your CD drive with other media. In the event that is is not in fact an error with your installation media please set the bug's status back to New. Thanks and good luck!

tags: added: media-error
Changed in ubiquity (Ubuntu):
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

Changed in ubiquity (Ubuntu):
status: Incomplete → Expired
Vadim Rutkovsky (roignac) wrote :

Reopening, see info in duplicate bug 893285

Changed in ubiquity (Ubuntu):
status: Expired → New

bug 893285 is not a duplicate and affects Linux Mint not Ubuntu.

Changed in ubiquity (Ubuntu):
status: New → Invalid
Displaying first 40 and last 40 comments. View all 101 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers