Ubiquity chooses which drive to install to with no user input

Bug #964331 reported by Jane Atkinson on 2012-03-25
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)
High
Unassigned

Bug Description

I was testing Precise beta 2 live ISO, using the "Install Ubuntu alongside" option.

I have two internals drives, and both of them have other systems on them.

Ubiquity didn't ask me to choose which drive. I got a message to the effect that it was installing to /dev/sdb but NO "Are you sure?" It just went ahead and started installing. The only way to stop that seems to be to reboot.

I would expect the user to be able to check that everything is OK before proceeding.

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:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/964331

tags: added: iso-testing
Jane Atkinson (irihapeti) wrote :

"Erase disk and install Ubuntu" *does* give the choice of which drive to use. Installing side-by-side should do the same.

Erick Brunzell (lbsolost) wrote :

Jane, I did a bunch of retesting - going back as far as Oneiric live CD's - and I think we're OK. Maybe more accurately we're where the ubiquity spec says we should be:

https://docs.google.com/View?id=dfkkjjcj_101gnkrpg5v#2.10.2

I've recently been testing the alternate and netboot images for totally unrelated reasons and the new ubiquity is certainly a departure from that level of simplicity.

You may find the info at bug 766265 useful.

Jane Atkinson (irihapeti) wrote :

Erick:
I'm not quite sure I follow. Are you saying that this is expected behaviour - that Ubuntu will start the install the moment you click on that option?

Erick Brunzell (lbsolost) wrote :

I'll try to explain a bit better. If you have two drives and neither drive has adequate free space (as little as 4.4GB for Ubuntu I believe) and you select Use entire drive another window opens that'll allow you to choose which drive you wish to use.

But if you have two or more drives and there is adequate free space on any drive (could even be an external drive or flash drive/card), and you select Install alongside then the installer just proceeds to use that free space. The only way to differentiate what is going to happen is the fact that the button in the lower right hand corner should change from "Continue" to "Install now".

If it says Continue when you click on it a new window should open allowing you to select which drive is going to be used and allowing you to move the "slider" to adjust partition size.

If it says Install now then as soon as you click on it the installation begins using the largest continuous available free space.

Quite simply, if it says Continue you should expect to be offered more options, but if it says Install Now it really means just that. Please see:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/766265/comments/34

Does that help explain things at all?

Changed in ubiquity (Ubuntu):
importance: Undecided → High
Jane Atkinson (irihapeti) wrote :

Still present in ISO of 20120419.1

Colin Watson (cjwatson) wrote :

I would like to redesign this for Q, since it's come up several times as a problem. However, it's been this way for a few releases, and we aren't going to be able to do anything about it for 12.04 at this point.

Colin Watson (cjwatson) wrote :

(It's kind of emergent behaviour from the fact that the underlying resize_use_free method in partman-auto only offers one disk, and I think the current documented design probably reflects that, but that doesn't make it ideal.)

tags: added: rls-p-nottracking
Changed in ubiquity (Ubuntu):
status: New → Triaged
Changed in ubiquity (Ubuntu):
status: Triaged → Confirmed
Diamond Luke (costineanpaul) wrote :

I can confirm something quite similar to this happened. It fully formatted my HDD to ext4 though, without any prompt, after clicking "Install alongside .. ".

Phillip Susi (psusi) wrote :

Please don't demote bug status from triaged back to confirmed.

Changed in ubiquity (Ubuntu):
status: Confirmed → Triaged
Jane Atkinson (irihapeti) wrote :

This is still happening in Eoan RC.

I was installing side-by-side to a VM. There was a USB stick inserted with a connection to the VM (from a previous test). Grub installed to the USB stick (/dev/sda, as distinct from /dev/vda for the main VM drive). There was no place where I could tell grub where I wanted it installed.

I think ubiquity should either install grub to the drive where the system is, or give the user the choice. Otherwise, someone who's accidentally left an external drive or USB stick connected is going to be very confused.

There's clearly something odd happening then, because I am unable to reproduce this on various hardware; installing from USB as I normally do.

How are the drives partitioned to begin with? I wonder if something is keeping grub from using the hard-drive on which it installed (as one certainly rightfully would expect it to).

Jane Atkinson (irihapeti) wrote :

When I do a side-by-side install, it's immediately after an entire-drive install. The existing install is on /dev/vda1 and there's nothing else on the drive. (The drive is virtIO.)

The USB stick is /dev/sda. I'm not installing from the USB stick, by the way. I'm using an ISO file as CDROM. I had simply forgotten to remove the stick and then wondered why the VM didn't boot into the new install.

I noticed a similar thing when I was doing a manual install. Grub wanted to install on /dev/sda. In this instance, I was able to get it to use the correct drive manually.

My suspicion, for what it's worth, is that Ubiquity is using alphabetical order to find the drive to install Grub to. Though I don't know why it would default to the correct drive for the actual install, and then change its mind, so to speak, for Grub install.

Unfortunately, I don't have a spare machine to do a bare-metal install to see if it does the same thing there.

I really don't think this is ubiquity's fault; more aiming to grub-installer, the d-i component we call as part of ubiquity.

And yes, it's not at all a new issue, but something that's been difficult to handle for a number of years. Install happens properly, but in some circumstances, grub-probe / grub-installer will pick a different drive on which to install the bootloader.

affects: ubiquity (Ubuntu) → grub-installer (Ubuntu)
Jarno Suni (jarnos) wrote :

So the original bug has been fixed, and the only issue is that grub may be installed in wrong drive, right?

Jane Atkinson (irihapeti) wrote :

Yes, the OS was installed where I wanted it to be, but grub was installed to the wrong drive.

I think the fact that the install drive was /dev/vda might have made a difference. That automatically put it at the end of an alphabetical list, which could have confused grub-install.

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

Other bug subscribers

Related blueprints