"Bootloader install failed" cannot be closed

By the way, this is grub's entry in syslog:

Dec 8 04:13:50 ubuntu 50mounted-tests: debug: /usr/lib/linux-boot-probes/mounted/40grub2 succeeded
Dec 8 04:13:50 ubuntu linux-boot-prober: debug: linux detected by /usr/lib/linux-boot-probes/50mounted-tests
Dec 8 04:13:50 ubuntu grub-installer: info: Installing grub on '/dev/mapper/mainlvm-ubuntu1104'
Dec 8 04:13:51 ubuntu grub-installer: info: grub-install supports --no-floppy
Dec 8 04:13:51 ubuntu grub-installer: info: Running chroot /target grub-install --no-floppy --force "/dev/mapper/mainlvm-ubuntu1104"
Dec 8 04:13:53 ubuntu grub-installer: /usr/sbin/grub-probe: error: no such disk.
Dec 8 04:13:53 ubuntu grub-installer: Auto-detection of a filesystem of /dev/mapper/mainlvm-ubuntu1104p1 failed.
Dec 8 04:13:53 ubuntu grub-installer: Please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <email address hidden>
Dec 8 04:13:53 ubuntu grub-installer: error: Running 'grub-install --no-floppy --force "/dev/mapper/mainlvm-ubuntu1104"' failed.
Dec 8 04:13:58 ubuntu activate-dmraid: No Serial ATA RAID disks detected
Dec 8 04:14:08 ubuntu ubiquity[8874]: switched to page partman

I have the same problem, with the difference that the Ok button is always clickable (though nothing will happen). My root partition is formated with btrfs and I tried to install grub to /dev/sda9 (I have no lvm on my hard drive).
As far as I can tell the error causing the bootloader install to fail is Bug #703009.

We can confirm this with Natty 11.04 amd64 final on /ext4. The installation stops with failure to install Grub to /sda. The installer textbox choices e.g. install to /sdb or cancel the installation had no effect. After a reboot we performed a reinstall with Grub manually set to /sdb without issues.

I have yet another variant of the same problem with final release 11.04. No matter what drive I select to install GRUB to, RAID or non-RAID, I always receive the message "Executing 'grub-install /dev/sda' failed. This is a fatal error." It always attempts /dev/sda independent of my choice in previous menus. Then I reach the dialog the above users have been having trouble with. I click an option and then click OK and...nothing happens. If I reboot and try a fresh install again, sometimes it will let me select the "Continue without a bootloader" option, but then Ubiquity crashes and I am left with almost nothing in the home folder of my new installation. Therefore right now I cannot install Natty until this is resolved.

Exactly the same problem here.

Trying to install 11.04 to Nvidia RAID 0 system /dev/mapper/nvidia
Even though I selected the nvidia drive it will still try to go to /dev/sda although it does not exist.

Cant even install ubuntu now.

I managed to install Ubuntu onto my Intel Matrix RAID 0 using the alternative install disk after some further experimentation.

Using Gparted I created a new MSDOS / MBR partition table and formatted the drives. Using an MBR partition table is important because GPT partition tables require the kpartx application to map the partitions. To my knowledge kpartx is not pre-installed in the altenative installation disk and programs cannot be installed on the fly like they can with live disks. I then booted into the alternative installation disk and manually formatted partitions as usual. Thankfully the alternative installer does not seem to have any problem installing GRUB.

natty have reached EOL now

Still there for 15.10
After doing anything in "Bootloader install failed" dialog, the OK button is always clickable however nothing will happen...

I can confirm the bug is still here in Ubuntu 15.10
Nothing happens when I click the OK button, whichever option I select

Bug still present in 16.04.

That report is now 6 years old !!! affecting 16 users (only)
Does that means these are corner cases with unusual supported tweaks ?

Anyway, the actual valid ubiquity is not the same as the one reported here. So if you wish to get devs attention for a fix, report the full details with your own report.
Closing that one that will never get attention now.

Reopening.

@dino99 (#12) What do you mean with "the actual valid ubiquity is not the same as the one reported here". Just above your comment there is a confirmation that this bug is still present in 16.04.

> corner cases with unusual supported tweaks

As can be read in the issue description, this is from a *plain live disk*, with 1 package installed (lvm). There cannot be any "unusual tweaks" you are talking about, and it's unclear to me what you mean by "unsupported". This is a standard installation procedure.

> Closing that one that will never get attention now.

Changing the bug number won't do anything. Forcing the 14 "affects me too" people to subscribe to a new bug with exactly the same contents does something, but nothing positive.

Still there in Lubuntu 16.10 32-bit. I'm installing using a bog standard quad-core desktop, from DVD, but onto 40 GB IBM Thinkpad PATA harddisk (using a laptop-to-desktop PATA conversion cable. No other operating systems, no RAID, no encryption, etc. Using the default "Use Whole disk" in the installer. (The number of reports is small over many years, but maybe not everyone bothers to create an account.)

I was caught by this yesterday with an amd64 16.04.1 DVD install to a BIOS+GPT custom ("Something Else") configuration where I had forgotten to create the GPT BIOS Boot Partition for GRUB's core.

The Bootloader Error dialog is modal with only a GtkButton "gtk-ok". Reading the ubiquity Python code and XML user interface description files it looks as if the OK button is disabled if *any* changes are made to the device GtkComboBox where the user-selected device is invalid (which is checked by the grub_verify_loop() handler.

In my case there was no alternative valid option so once I'd interacted with the GtkComboBox the OK button was disabled and I couldn't close the modal dialog.

So the issue seems to be that once the OK button has been disabled it is never re-enabled when selecting other valid options.

I spent quite some time trying to understand and track the execution flow but didn't get to the point of testing my bug-fix hypothesis due to lack of time but it is detailed at the end of this comment if anyone cares to test it.

/use/lib/ubiquity/ubiquity/frontend/gtk_ui.py::Wizard.run(): (line ~718)

        # Auto-connecting signals with additional parameters does not work.
        self.grub_new_device_entry.connect(
            'changed', self.grub_verify_loop, self.grub_fail_okbutton)

This connects a signal from the device GtkComboBox to the grub_verify_loop() function.

/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py::Wizard.grub_verify_loop() (line ~1706)

    def grub_verify_loop(self, widget, okbutton):
        if widget is not None:
            if validation.check_grub_device(widget.get_child().get_text()):
                okbutton.set_sensitive(True)
            else:
                okbutton.set_sensitive(False)

Which will disable the OK button if the device is not valid.

/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py::bootloader_dialog(): (line ~1775)
...
        response = self.bootloader_fail_dialog.run()
        self.bootloader_fail_dialog.hide()
        if response == Gtk.ResponseType.OK:
            if self.grub_new_device.get_active():
                return self.grub_new_device_entry.get_child().get_text()
            elif self.grub_no_new_device.get_active():
                return 'skip'
            else:
                return ''
        else:
            return ''

because bootloader_fail_dialog.run() blocks and never returns the subsequent .hide() and response handling never occurs.

In /usr/share/ubiquity/gtk/ubiquity.ui the OK button id is "grub_fail_okbutton" and it is attached to:

 <action-widget response="-5">grub_fail_okbutton</action-widget>

The XML also defines a "toggled" signal attached to each of the radio buttons that calls the toggle_grub_fail() handler.

/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py::Wizard.toggle_grub_fail() (line ~1761)

    def toggle_grub_fail(self, unused_widget):
        if self.grub_no_new_device.get_active():
            self.no_grub_warn.show()
            self.grub_new_device_entry.set_sensitive(False)
            self.abort_warn.hide()
        elif self.grub_fail_option.get_active():
            self.abort_warn.show()
            self.no_grub_warn.hide()
            self.gru...

Still present in 18.04.2

Appears to be present in 19.10 too.
I found this bug from a xubuntu live session, during a failed install.
The bug is 10 years old and TJ's comment #15 contains a proposed fix,
that's gotten zero attention in 2 years.

This is fucking insane!

still ocurring in 20.04.1 - I needed to install ubuntu alongside an existing partitioned gpt lvm thin pool disk.

could not install grub on selected disk, now I can't get past the error, as I can't select any other disk nor choose "continue without a bootloader" because the OK button does absolutely nothing.

this is enormously frustrating. I had to delete the curses I wrote first. why is this an issue in 2020?

does anyone from canonical read or care about this issue?

because if not, just fucking tell us or fucking write a faq entry on installation wiki

Just hit this in 22.04. Very frustrating. I had to kill ubiquity, and now I have no idea what state it has left things in. (in my case the button remained enabled but failed to recognize input regardless of selection as per #3 above)