Ubuntu
grub-installer package

ISST-LTE: Ubuntu15.04: Boot loader installation is failing

Bug #1415918 reported by bugproxy
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)
Fix Released
Critical
Mathieu Trudel-Lapierre
Trusty
Fix Released
Undecided
Mathieu Trudel-Lapierre

Bug Description

== Comment: #0 - Sowmya G. Parvathi <email address hidden> - 2015-01-23 04:26:08 ==
I am trying to install ubuntu 15.04 in one of the lpar, most of the file sets will be installed but boot loader installation is failing with below error:

   ??????????????????? [!] Continue without boot loader ????????????????????
   ? ?
   ? No boot loader installed ?
   ? No boot loader has been installed, either because you chose not to or ?
   ? because your specific architecture doesn't support a boot loader yet. ?
   ? ?
   ? You will need to boot manually with the /boot/vmlinux kernel on ?
   ? partition /dev/sda2 and root=/dev/sda2 quiet passed as a kernel ?
   ? argument. ?
   ? ?
   ? <Continue> ?
   ? ?
   ?????????????????????????????????????????????????????????????????????????

And I have choosen single path disks for installation.

Please let me know for more information.

Contact: <email address hidden>

== Comment: #4 - Sowmya G. Parvathi <email address hidden> - 2015-01-23 12:01:12 ==

For disk selection, i choose "Use Entire Disk" option:

  ?????????????????????????? [!!] Partition disks ???????????????????????????
  ? ?
  ? The installer can guide you through partitioning a disk (using ?
  ? different standard schemes) or, if you prefer, you can do it ?
  ? manually. With guided partitioning you will still have a chance later ?
  ? to review and customise the results. ?
  ? ?
  ? If you choose guided partitioning for an entire disk, you will next ?
  ? be asked which disk should be used. ?
  ? ?
  ? Partitioning method: ?
  ? ?
  ? Guided - resize SCSI3 (0,1,4), partition #1 (sdj) and use freed s ?
  ? Guided - resize SCSI3 (0,1,5), partition #1 (sdk) and use freed s ? ?
  ? Guided - use entire disk ?
  ? Guided - use the largest continuous free space ? ?
  ? Guided - use entire disk and set up LVM ?
  ? ?
  ? <Go Back> ?
  ? ?
  ???????????????????????????????????????????????????????????????????????????

Next, i choose a disk from the list and proceed with installation.

I also observed, when boot loader installation was not successful, i tried the same again from the Main menu and installation was successful.

The scenario u mentioned might be true: the installer may just think that no bootloader has been selected. So it could be a problem with the installer dialogs, that you were not prompted for this but should have been.

== Comment: #5 - David Heller <email address hidden> - 2015-01-23 14:42:18 ==
Hmm. It could be confused about which disk to install the boatloader to... or perhaps it installed the OS to a disk other than sda and for some reason, only knows to install the bootloader to sda... or some variation of that theme. I.e. it's confused by multiple disks in the system.

Is it possible to install to a system with only one disk online, as a sanity check?

In either case I think you will have to provide some log information to be sure. At the point it fails, can you please "execute a shell" from within the installer, and search the latter part of /var/log/syslog for pertinent errors; or attach the file here

== Comment: #6 - Sowmya G. Parvathi <email address hidden> - 2015-01-28 06:26:37 ==
I tried installation on two lpars.

1. On one lpar with multiple disks, boot loader installation is failing.

logs: /var/log/syslog
Jan 28 09:48:44 grub-installer: info: Identified partition label for /dev/sda2: gpt
Jan 28 09:48:44 kernel: [ 4184.838418] sdd: sdd1 sdd2 sdd3
Jan 28 09:48:44 kernel: [ 4184.847047] sde: sde1 sde2 sde3
Jan 28 09:48:44 kernel: [ 4184.858556] sdf: sdf1 sdf2 sdf3
Jan 28 09:48:44 kernel: [ 4184.867589] sdg: sdg1 sdg2 sdg3
Jan 28 09:48:44 kernel: [ 4184.876261] sdh: sdh1 sdh2 sdh3
Jan 28 09:48:44 kernel: [ 4184.884164] sdi: sdi1 sdi2 sdi3
Jan 28 09:48:44 kernel: [ 4184.892658] sdj: sdj1 sdj2 sdj3
Jan 28 09:48:45 kernel: [ 4185.148993] sdd: sdd1 sdd2 sdd3
Jan 28 09:48:45 kernel: [ 4185.217318] sde: sde1 sde2 sde3
Jan 28 09:48:45 kernel: [ 4185.489753] sdh: sdh1 sdh2 sdh3
Jan 28 09:48:45 grub-installer: info: Wiping PReP partition
Jan 28 09:48:45 grub-installer: dd: invalid number ''
Jan 28 09:48:45 main-menu[352]: (process:9397): File descriptor 3 (pipe:[2083]) leaked on lvdisplay invocation. Parent PID 10145: /bin/sh
Jan 28 09:48:45 main-menu[352]: (process:9397): File descriptor 4 (/dev/hvc0) leaked on lvdisplay invocation. Parent PID 10145: /bin/sh
Jan 28 09:48:45 main-menu[352]: (process:9397): File descriptor 5 (/dev/hvc0) leaked on lvdisplay invocation. Parent PID 10145: /bin/sh
Jan 28 09:48:45 main-menu[352]: (process:9397): File descriptor 6 (/dev/hvc0) leaked on lvdisplay invocation. Parent PID 10145: /bin/sh
Jan 28 09:48:45 main-menu[352]: (process:9397): Volume group "sda" not found
Jan 28 09:48:45 main-menu[352]: (process:9397): Skipping volume group sda
Jan 28 09:48:45 main-menu[352]: (process:9397): blockdev: can't open '': No such file or directory
Jan 28 09:48:45 main-menu[352]: WARNING **: Configuring 'grub-installer' failed with error code 1
Jan 28 09:48:45 main-menu[352]: WARNING **: Menu item 'grub-installer' failed.
Jan 28 09:49:26 main-menu[352]: INFO: Modifying debconf priority limit from 'high' to 'medium'
Jan 28 09:49:26 debconf: Setting debconf/priority to medium
Jan 28 09:50:07 main-menu[352]: INFO: Menu item 'di-utils-shell' selected

2. On lpar with one disk, installation is successful, but in installer "Main Menu" i still get option, "Continue without bootloader":

   ??????????????????? [!] Continue without boot loader ????????????????????
   ? ?
   ? No boot loader installed ?
   ? No boot loader has been installed, either because you chose not to or ?
   ? because your specific architecture doesn't support a boot loader yet. ?
   ? ?
   ? You will need to boot manually with the /boot/vmlinux kernel on ?
   ? partition /dev/sda2 and root=/dev/sda2 quiet passed as a kernel ?
   ? argument. ?
   ? ?
   ? <Continue> ?
   ? ?
   ?????????????????????????????????????????????????????????????????????????

== Comment: #8 - David Heller <email address hidden> - 2015-01-28 20:10:43 ==

I don't see any major errors in syslog before it failed. There are a few "couldn't mount" errors early on but I'm guessing that's part of the disk detection. What looks odd though, is that grub seems to be looking at /dev/sda2:

Jan 28 09:48:44 grub-installer: info: Identified partition label for /dev/sda2: gpt
Jan 28 09:48:45 grub-installer: info: Wiping PReP partition
Jan 28 09:48:45 grub-installer: dd: invalid number ''

And it probably should be looking at /dev/sda1 instead:

root@pole2lp2:~# parted -l
Model: IBM 2810XIV (scsi)
Disk /dev/sda: 34.4GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
 1 1049kB 8389kB 7340kB prep
 2 8389kB 32.9GB 32.9GB ext4
 3 32.9GB 34.4GB 1460MB linux-swap(v1)

In fact, it's actually /dev/sdf that has the root partition here:

root@pole2lp2:~# mount | grep sd
/dev/sdf2 on / type ext4 (rw,errors=remount-ro)

But this drive is partitioned the same way: the prep partition is the 1st partition:

Model: IBM 2810XIV (scsi)
Disk /dev/sdf: 34.4GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
 1 1049kB 8389kB 7340kB prep
 2 8389kB 32.9GB 32.9GB ext4
 3 32.9GB 34.4GB 1460MB linux-swap(v1)

So, it kind of looks like it's having trouble finding the correct partition to install to.

Revision history for this message
bugproxy (bugproxy) wrote : syslog file from installer

Default Comment by Bridge

tags: added: architecture-ppc64le bugnameltc-120779 severity-critical targetmilestone-inin---
Dave Heller (hellerda)
affects: ubuntu → grub-installer (Ubuntu)
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2015-01-30 18:18 EDT-------
*** Bug 121222 has been marked as a duplicate of this bug. ***

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-02-04 16:44 EDT-------
*** Bug 121377 has been marked as a duplicate of this bug. ***

Revision history for this message
Dave Heller (hellerda) wrote :

Hi Canonical,

Please address this with high priority, we have several bugs that are dups of this and it is blocking our test.

We are fairly certain this is not related to the missing ibmvfc driver (bug 1416001) as we get a partial install but then fail at the install bootloader stage. This issue here tends to happen when there is >1 disk in the system and the target is a drive other than sda. (or it's possible it could happen to a target sda and we just have not seen that yet).

Let us know if more info is required. Thanks!

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-02-07 02:35 EDT-------
*** Bug 121377 has been marked as a duplicate of this bug. ***

Breno Leitão (breno-leitao)
Changed in grub-installer (Ubuntu):
status: New → Confirmed
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-02-09 18:39 EDT-------
David,

Besides that the message shows sda2, the wipping function from grub-installer uses [1] an auxiliary program called prep-bootdev to search for the PReP partition.

It seems that prep-bootdev is not returning the PReP partition:

Jan 28 09:48:45 grub-installer: info: Wiping PReP partition
Jan 28 09:48:45 grub-installer: dd: invalid number ''

Can I test it using pole2lp2?

[1] http://bazaar.launchpad.net/~ubuntu-core-dev/grub-installer/ubuntu/view/head:/grub-installer#L485
[2] http://bazaar.launchpad.net/~ubuntu-core-dev/grub-installer/ubuntu/view/head:/prep-bootdev.c

Steve Langasek (vorlon)
Changed in grub-installer (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

I've been testing this in a virtual machine for powerpc64el; and I seem to be able to install successfully with multiple disks attached.

How are you doing the two installs described in the description? Are any parts preseeded? How is the second install (lpar with single disk), how are you getting the main menu if the installation is successful? Or does this mean you are getting this dialog at the end of the installation automatically?

I've installed with 4 disks so far, no issues even with multiple prep partitions on different disks, things appear to be working properly. I have yet to try a single-disk install. One remaining difference though is that these have no been done with disks connected over the emulex fibre channel adapter as it seems to be the case as per syslog.

Changed in grub-installer (Ubuntu):
status: Confirmed → Incomplete
importance: Undecided → Critical
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

One piece of information that would be really useful is the output of parted for all the devices connected.

Could you please run 'sudo parted -l' in a separate VT on the system during installation, at the point where it asks about the bootloader (or anywhere just before rebooting on the installed system). We may be running into a case where there are no partitions marked as prep partitions for some reason.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-02-12 18:09 EDT-------
Installation went smoothly after wiping up disks with 'dd' command.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-02-12 19:30 EDT-------
Ok, good news. So I'm going to put this in REJECTED UNREPRODUCIBLE state, but will not close it just yet as you said you wanted to run one more test.

This is common, that the installers get confused by stale data on the disks. It could in fact be a bug, if the installer is supposed to clear the disks but fails to do so. But if we don't have a reproduce, it is hard to say for sure.

Canonical: thank you for investigating this. If we find the sequence that led to this we will report back here. Otherwise, just for your awareness for now.

Revision history for this message
bugproxy (bugproxy) wrote : Logs collected when hit with the issue

------- Comment on attachment From <email address hidden> 2015-02-13 06:33 EDT-------

These logs are collected uisng "Save debug logs" option from installer menu main

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla
Download full text (4.9 KiB)

------- Comment From <email address hidden> 2015-02-13 17:52 EDT-------
Hi Canonical. Some recent comments were made private by mistake. Catching you up...

Installation of Boot loader failed again, so the reason here might be stale data on disk.

------- Comment From <email address hidden> 2015-02-13 17:54 EDT-------
(In reply to comment #22)
>
> How are you doing the two installs described in the description? Are any
> parts preseeded? How is the second install (lpar with single disk), how are
> you getting the main menu if the installation is successful? Or does this
> mean you are getting this dialog at the end of the installation
> automatically?
>
> I've installed with 4 disks so far, no issues even with multiple prep
> partitions on different disks, things appear to be working properly. I have
> yet to try a single-disk install. One remaining difference though is that
> these have no been done with disks connected over the emulex fibre channel
> adapter as it seems to be the case as per syslog.

1. No parts are preseeded ,i am trying single disk installation, and when i hit with the boot loader issue, there is a option <GO BACK/CONTINUE> which will take us to Main Menu, even at the end of installation we have that option, so it is easy to navigate to Main Menu.

??????????????????? [!] Continue without boot loader ????????????????????
? ?
? No boot loader installed ?
? No boot loader has been installed, either because you chose not to or ?
? because your specific architecture doesn't support a boot loader yet. ?
? ?
? You will need to boot manually with the /boot/vmlinux kernel on ?
? partition /dev/sda2 and root=/dev/sda2 quiet passed as a kernel ?
? argument. ?
? ?
? <Continue> ?
? ?
?????????????????????????????????????????????????????????????????????????
On Press of <continue>

????????? [!!] Install the GRUB boot loader on a hard disk ??????????
? ?
? Installation step failed ?
? An installation step failed. You can try to run the failing item ?
? again from the menu, or skip it and choose something else. The ?
? failing step is: Install the GRUB boot loader on a hard disk ?
? ?
? <Continue> ?
? ?
?????????????????????????????????????????????????????????????????????
On Press of <continue>

???????????????? [?] Ubuntu installer main menu ????????????????
? ?
? Choose the next step in the install process: ?
? ...

Read more...

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Seems like a bug -- the installer *should* be wiping the partitions it needs to deal with, provided they are marked to be wiped.

As mentioned in a previous comment, could you get the output of the command 'sudo parted -l' from the installation when it shows the bootloader dialog? You will need to switch to another VT to do this. Seeing all the partitions for all disks maybe we can find what the stale data is. The information is already in the partman log, but quite a lot harder to decipher than looking at parted output.

One thing I can think of right now, is that grub-installer is still failing, so that's one place I'm still looking for hints of what might be wrong. I will comment again here once I have another thing to look at; and work in parallel on reproducing the issue on the hardware I have.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-02-15 09:23 EDT-------
(In reply to comment #39)
> Seems like a bug -- the installer *should* be wiping the partitions it needs
> to deal with, provided they are marked to be wiped.
>
> As mentioned in a previous comment, could you get the output of the command
> 'sudo parted -l' from the installation when it shows the bootloader dialog?
> You will need to switch to another VT to do this. Seeing all the partitions
> for all disks maybe we can find what the stale data is. The information is
> already in the partman log, but quite a lot harder to decipher than looking
> at parted output.

I tried to get "'sudo parted -l" output, when i was hit with issue, by dropping into shell from installer menu:

~ # sudo parted -l
/bin/sh: sudo: not found

~ # parted -l
/bin/sh: parted: not found

Tried df command:

df
Filesystem 1K-blocks Used Available Use% Mounted on
none 518336 4032 514304 1% /run
devtmpfs 2544960 0 2544960 0% /dev
/dev/sda2 31483800 1134112 28727316 4% /target
/dev/sda2 31483800 1134112 28727316 4% /dev/.static/dev
devtmpfs 2544960 0 2544960 0% /target/dev

parted_devices
/dev/sda 34359738368 IBM 2810XIV
/dev/sdb 34359738368 IBM 2810XIV
/dev/sdc 34359738368 IBM 2810XIV
/dev/sdd 34359738368 IBM 2810XIV
/dev/sde 34359738368 IBM 2810XIV
/dev/sdf 34359738368 IBM 2810XIV
/dev/sdg 34359738368 IBM 2810XIV
/dev/sdh 34359738368 IBM 2810XIV
/dev/sdi 34359738368 IBM 2810XIV
/dev/sdj 34359738368 IBM 2810XIV

And for installation i selected "dev/sda" disk.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-02-17 16:31 EDT-------
Hi Canonical,

We once again find this issue unreproducible. We will reopen if we find a reproducible case. Thanks again for your investigation.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Well, that issue appears to be caused by stale data on the disk, and that's probably something like that pre-existing PReP partitions aren't being handled properly.

Could you try to just manually wipe /dev/sdX1 (replacing X with whatever device you choose to install on), using 'dd if=/dev/zero of=/dev/sdX1', see if just this is sufficient to let the installer complete successfully?

I still don't know why this might be happening, but I've also built a version of grub-installer in my PPA that ignores the failure to wipe a PReP partition and carries on with the installation: https://launchpad.net/~mathieu-tl/+archive/ubuntu/installer-dev/+packages. That package will need to be installed manually before the installer reaches the point where it would install the bootloader.

I'm still waiting to get access to a proper LPAR to do better testing on this, so as soon as that is available I'll update here and do my own testing as well to try and reproduce the issue here.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Scratch that about my PPA packages, they wouldn't be built for ppc64el; that will need some more work.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-02-19 04:34 EDT-------
Hi Canonical,

Please use pole2lp2, for testing.

Thanks.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

How can I get to that system? You can send me the details at <email address hidden>; assuming they are sensitive.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-02-23 12:26 EDT-------
Hi Mathieu,

I'm afraid that this machine doesn't have external access so you are not able to connect into it. Currently it's marked as "UNREPRODUCIBLE" internally as you can see in comment 10.

From my point of view, prep-bootdev (a script from grub-installer) is failing to find the PReP partition for some reason:

Jan 28 09:48:45 grub-installer: info: Wiping PReP partition
Jan 28 09:48:45 grub-installer: dd: invalid number ''

The error above is where grub-installer is finding the PReP partition number in order to wipping its content [1] so I don't believe that it's a problem with the wipe action but a little before.

[1] http://bazaar.launchpad.net/~ubuntu-core-dev/grub-installer/ubuntu/view/head:/grub-installer#L485

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Indeed, these messages have to do with prep-bootdev not finding the PReP partition to wipe, but this should have been initialized by partman-prep -- the fact that it wasn't and that this bug isn't happening when the disks are wiped before doing the install still point to something being wrong in either how partman-prep sets up the prep partition (or fails to do so) or how prep-bootdev searches for the PReP partition. This is why I asked to see the output of parted (without realizing that it might not be available as such). As a next step should this need to be further investigated I would try to see whether clearing just one disk's partition 1 might let grub complete its installation. I suspect a stale prep partition from a previous install that can't be matched because it's not on the disk we pass as a parameter to prep-bootdev, so it can't be wiped, can't be used by grub-installer and grub so the resulting install may not be bootable.

Leaving this as Incomplete so it can be picked back up later should it be possible to reproduce it again (as per comment #10).

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub-installer - 1.78ubuntu27

---------------
grub-installer (1.78ubuntu27) vivid; urgency=medium

  [ Mauricio Faria de Oliveira ]
  * grub-installer: Use 'p' (not '-part') as multipath disk-partition
    separator. This fixes the check of whether the boot file system is on
    multipath (i.e., $disc_offered is a multipath partition). (LP: #1430074)
  * Better handle PReP partitions on ppc64el: (LP: #1415918)
    - prep-bootdev: add '-l' option to list all PReP partitions. With this,
      it's possible to do more things to select a PReP partition.
    - grub-installer [ppc64el]: bootdev/wipe_bootdev: prefer PReP partition in
      the same disk as the boot file system partition ($disc_offered).
 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 17 Mar 2015 00:25:13 -0400

Changed in grub-installer (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

I've closed this bug with the latest grub-installer upload because I expect the changes for multipath (and specifically, selecting the same device as the one being installed on for the PReP partition) to help a lot. Let's reopen the bug (set it back to New) if it's still a problem after further testing.

bugproxy (bugproxy)
tags: added: targetmilestone-inin1504
removed: targetmilestone-inin---
Mathieu Trudel-Lapierre (cyphermox)
Changed in grub-installer (Ubuntu Trusty):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
status: New → In Progress
Revision history for this message
Adam Conrad (adconrad) wrote : Please test proposed package

Hello bugproxy, or anyone else affected,

Accepted grub-installer into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub-installer/1.78ubuntu20.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in grub-installer (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Mauricio Faria de Oliveira (mfo) wrote :

grub-installer is verified OK on trusty-proposed; tags changed.

The install on a multipath device correctly uses the 'p' partition separator, and chooses the mpath disk, rather than any underlying disk (which actually show up before in the introduced prep_bootdev -l command).

 ~ # /usr/lib/grub-installer/prep-bootdev -l
 /dev/sda1
 /dev/mapper/mpath10p1
 /dev/sdz1

 ~ # grep grub-install.*success /var/log/syslog
 Jul 27 16:07:28 grub-installer: info: grub-install ran successfully

 ~ # grep grub-install /var/log/syslog
 Jul 27 15:46:27 anna[3639]: DEBUG: retrieving grub-installer 1.78ubuntu20.2
 Jul 27 15:46:29 anna[3639]: 2015-07-27 15:46:29 URL:http://ports.ubuntu.com/ubuntu-ports//pool/main/g/grub-installer/grub-installer_1.78ubuntu20.2_ppc64el.udeb [198958/198958] -> "/var/cache/anna/grub-installer_1.78ubuntu20.2_ppc64el.udeb" [1]
 Jul 27 16:07:16 main-menu[2024]: INFO: Menu item 'grub-installer' selected
 Jul 27 16:07:16 grub-installer: info: architecture: ppc64el/chrp_ibm
 Jul 27 16:07:16 grub-installer: info: Mounting /proc into /target
 Jul 27 16:07:20 grub-installer: info: Identified partition label for /dev/mapper/mpath0p2: unknown
 Jul 27 16:07:21 grub-installer: info: Wiping PReP partition /dev/mapper/mpath0p1
 Jul 27 16:07:27 grub-installer: info: Installing grub on '/dev/mapper/mpath0p1'
 Jul 27 16:07:27 grub-installer: info: grub-install does not support --no-floppy
 Jul 27 16:07:27 grub-installer: info: Wiping PReP partition /dev/mapper/mpath0p1
 Jul 27 16:07:27 grub-installer: info: Running chroot /target grub-install --force "/dev/mapper/mpath0p1"
 Jul 27 16:07:27 grub-installer: Installing for powerpc-ieee1275 platform.
 Jul 27 16:07:28 grub-installer: Installation finished. No error reported.
 Jul 27 16:07:28 grub-installer: info: grub-install ran successfully

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub-installer - 1.78ubuntu20.2

---------------
grub-installer (1.78ubuntu20.2) trusty; urgency=medium

  * grub-installer: Use 'p' (not '-part') as multipath disk-partition
    separator. This fixes the check of whether the boot file system is on
    multipath (i.e., $disc_offered is a multipath partition). (LP: #1430074)
  * Better handle PReP partitions on ppc64el: (LP: #1415918)
    - prep-bootdev: add '-l' option to list all PReP partitions. With this,
      it's possible to do more things to select a PReP partition.
    - grub-installer [ppc64el]: bootdev/wipe_bootdev: prefer PReP partition in
      the same disk as the boot file system partition ($disc_offered).

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 17 Jul 2015 13:12:57 -0400

Changed in grub-installer (Ubuntu Trusty):
status: Fix Committed → Fix Released
Revision history for this message
Adam Conrad (adconrad) wrote : Update Released

The verification of the Stable Release Update for grub-installer has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.