Ubuntu14.04 .3 RAID installation fails on firestone

[bugproxy]

[Impact]
Users installing on ppc64el with RAID enabled, doing manual or guided partitioning are unable to complete the installation because the multiple passes of partitioning required to apply the initial partitions on disk (PReP partitions and all) and the next set of partitions on RAID or LVM cause the initial PReP flags to be lost.

[Test case]
1) Start installation on a ppc64el system with two or more disks.
2) Use manual partitioning to add a PReP partition on one of the disks. It should have a size of 8MB, at the beginning of the disk. It can be followed by free space or a single partition to be used as space for RAID.
3) Create a RAID volume, using RAID1 (2 partitions, 0 spaces), add the RAID partition previously created and the free space from another disk.
4) End partitioning, confirming everything.

The installation should complete successfully.

[Regression potential]
This is limited to the handling of PReP partitions, so only applies to ppc64el systems. Possible regressions may be failure to allow a valid setup of partitions while preparing the install on ppc64el, or failure of the installation on an invalid (but not immediately detected) partition setup, at the point where grub-installer will try to install the bootloader on the system.

---

Problem Description
=======================
Installation goes smoothly, until it reaches grub installation, and fails with fatal error there.

Machine Type = pio-firestone

---boot type---
QEMU direct boot kernel/initrd

---Kernel cmdline used to launch install---
kexec -l /root/vmlinux.venkat -i /root/initrd.gz.venkat
kexec -e

== Comment: # - Venkat R. B <email address hidden> - 2015-08-14 08:08:41 ==
I am trying to install Ubuntu14.04 on the firestone machine on a RAID1 array, configured with software raid.
Installation goes on smoothly till its reaches grub loader and fails. Below I have pasted the error.

             ?? [!!] Install the GRUB boot loader on a hard disk ??
  ???????????? ? ?????????
  ? ? Unable to install GRUB in /dev/md0p1 ? ?
  ? ? Executing 'grub-install /dev/md0p1' failed. ? ?
  ? ? ? ?
  ? Running "? This is a fatal error. ? ?
  ? ? ? ?
  ???????????? <Go Back> <Continue> ? ?????????
             ? ?
             ??????????????????????????????????????????????????????

== Comment: # - Mauricio Faria De Oliveira <email address hidden> - 2015-08-20 09:31:11 ==
grub-installer pieces from syslog

Aug 19 11:07:43 grub-installer: info: Installing grub on '/dev/md0p1'
Aug 19 11:07:43 grub-installer: info: grub-install does not support --no-floppy
Aug 19 11:07:43 grub-installer: info: Running chroot /target grub-install --force "/dev/md0p1"
Aug 19 11:07:43 grub-installer: Installing for powerpc-ieee1275 platform.
Aug 19 11:08:01 grub-installer: grub-install: error: failed to copy Grub to the PReP partition.
Aug 19 11:08:01 grub-installer: error: Running 'grub-install --force "/dev/md0p1"' failed.

and the "error:" message 'failed to copy Grub to the PReP partition.' is not generated by the grub-installer script itself [1], so probably coming down from grub2.

I'd suggest to either involve our grub2 guy (not sure if available), or mirroring to Canonical.

[1] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/grub-installer/trusty-updates/view/head:/grub-installer

[bugproxy (bugproxy)]

Default Comment by Bridge

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1487365/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2015-08-27 15:48 EDT-------
Venkat,

Please detail your partitioning steps, and the daily build used.

I cannot create a PReP partition on the RAID1 device with the 0826 build, hitting a partitioner error, but according to your logs you could successfully create it.

Thanks!

For the record, I did read and tried [1] :) adapting for powerpc, which requires a PReP partition.
The change of bootable flag is not working.

Here's what I got:

Steps to reproduce
------------------

QEMU/KVM with 2 drives (sda/sdb).
wily ppc64el daily ISO of 0826.

At Partitioner dialog..

Select sda
Create new empty partition table: Yes
Select sda's free space
Automatically partition free space

Select sdb
Create new empty partition table: Yes
Select sdb's free space
Automatically partition free space

Select Configure Software RAID
Changes written to storage devices: Yes

Create MD Device
RAID 1
Number of active devices for RAID1 array: 2
Number of spare devices for RAID1 array: 2
Select sda1 and sdb1
Continue
Write changes: Yes

Create MD Device
RAID 1
Number of active devices for RAID1 array: 2
Number of spare devices for RAID1 array: 2
Select sda2 and sdb2
Continue
Write changes: Yes

Create MD Device
RAID 1
Number of active devices for RAID1 array: 2
Number of spare devices for RAID1 array: 2
Select sda3 and sdb3
Continue
Write changes: Yes

Select Finish (instead of Create MD Device)

Under RAID1 device #0 - 7.3 MB, Select #1
Use as: PowerPC PReP Partition

Boom:
????? [!!] Partition disks ?????
? ?
? ??? ??? ?
? ?
? <Go Back> <Continue> ?
? ?
????????????????????????????????

Here I stopped to collect the logs, as below.
Go Back
Go Back
Go Back
Execute a shell

On another installation I tried to go without creating a PReP partition, and the installer refuses to proceed, as required.

????????????? [!!] Partition disks ?????????????
? ?
? No PowerPC PReP boot partition is found. ?
? ?
? Go back to the menu and resume partitioning? ?
? ?
? <Go Back> <Yes> <No> ?
? ?
????????????????????????????????????????????????

If I try to create the PReP partition, the error above always happen, and the 'Finish partitioning and write changes to disk' always loop back to the same partitioning main dialog.

The logs indicate a fatal error in parted-server, as the output fifo to it is not available anymore.

~ # sed -n "/Menu item 'partman-base' selected/,\$ p" /var/log/syslog
Aug 27 15:21:02 main-menu[243]: INFO: Menu item 'partman-base' selected
Aug 27 15:21:02 kernel: [ 87.706971] ntfs: driver 2.1.32 [Flags: R/O MODULE].
Aug 27 15:21:02 kernel: [ 87.743448] Btrfs loaded
Aug 27 15:21:02 kernel: [ 87.764176] JFS: nTxBlock = 2036, nTxLock = 16293
Aug 27 15:21:02 kernel: [ 87.794723] SGI XFS with ACLs, security attributes, realtime, no debug enabled
Aug 27 15:21:02 md-devices: mdadm: No arrays found in config ...

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2015-09-07 08:19 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2015-09-08 15:25 EDT-------

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2015-09-08 22:10 EDT-------
It seems grub2 doesn't support RAID arrays of this sort (which it handles as 'diskfilter'), at least not for writing (which is required by grub-install).

It fails here, in grub-install.c:

if (write_to_disk (ins_dev, imgfile))
grub_util_error ("%s", _("failed to copy Grub to the PReP partition"));

write_to_disk() fails in

err = grub_disk_write (dev->disk, 0, 0,
core_size, core_img);

grub_disk_write() fails in

if ((disk->dev->write) (disk, transform_sector (disk, sector),
n, buf) != GRUB_ERR_NONE)
goto finish;

and disk->dev->write() fails in

return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
"diskfilter writes are not supported");

That is also present upstream:
http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/disk/diskfilter.c#n908

That module (diskfilter.c) states in its heading:

/* diskfilter.c - module to read RAID arrays. */

So, to /read/ RAID arrays.. not /write/.

Here's a gdb session with a unstripped binary that I took from the package build and put in the installer's /target/usr/sbin/grub-install:

The pkg build path / binary (not stripped)
# file obj/grub-ieee1275/grub-install
obj/grub-ieee1275/grub-install: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=1b326c701ee38d75d8e8739062a79046eb5ddfad, not stripped

The gdb session:

# gdb
...
(gdb) file /usr/sbin/grub-install
Reading symbols from /usr/sbin/grub-install...done.
(gdb) b grub_disk_write
Breakpoint 1 at 0x1013660c: file ../../grub-core/lib/disk.c, line 61.
(gdb) run --force /dev/md0p1
Starting program: /usr/sbin/grub-install --force /dev/md0p1
...
Installing for powerpc-ieee1275 platform.
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found

Breakpoint 1, grub_disk_write (disk=0x101e4a30, sector=0, offset=0,
size=96212, buf=0x10d99960) at ../../grub-core/lib/disk.c:61

(gdb) b transform_sector
Breakpoint 2 at 0x10134b00: transform_sector. (2 locations)
(gdb) c
Continuing.

Breakpoint 2, transform_sector (disk=0x101e4a30, sector=34)
at ../../grub-core/lib/../kern/disk_common.c:45
(gdb) s
46 in ../../grub-core/lib/../kern/disk_common.c

(gdb) s
grub_diskfilter_write (disk=0x101e4a30, sector=34, size=187,
buf=0x10d99960 "\177ELF\001\002\001")
at ../../grub-core/disk/diskfilter.c:821

(gdb) s
grub_error (n=GRUB_ERR_NOT_IMPLEMENTED_YET,
fmt=0x10194d10 "diskfilter writes are not supported")
at ../../grub-core/kern/err.c:41

(gdb) fin
Run till exit from #0 grub_error (n=GRUB_ERR_NOT_IMPLEMENTED_YET,
fmt=0x10194d10 "diskfilter writes are not supported")
at ../../grub-core/kern/err.c:41
0x0000000010159ffc in grub_diskfilter_write (disk=0x101e4a30, sector=34,
size=187, buf=0x10d99960 "\177ELF\001\002\001")
at ../../grub-core/disk/diskfilter.c:821

Value returned is $1 = GRUB_ERR_NOT_IMPLEMENTED_YET

(gdb) s
823 in ../../grub-core/disk/diskfilter.c
(gdb) s
grub_disk_write (disk=0x101e4a30, sector=34, offset=0, size=96212,
buf...

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2015-09-07 08:19 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2015-09-08 15:25 EDT-------

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2015-09-09 04:09 EDT-------
Hi Mauricio,

First of all its blocking two of our test-cases. One which explicitly says to install OS on Raid and other test case, also needs to be installed OS on Raid and one of the drive to be hot-pluged and data(OS should be up and running) should be intact.

And, this being firestone machine, which has only two SATA drive and no adaptor is present to access these drives, So it become even more critical, that we test this scenario. As customer may obviously want to install OS on RAID1 rather than installing on just a plain drive, for obvious reasons.

Thanks,
Venkat.

[Mathieu Trudel-Lapierre (cyphermox)]

Mauricio, thanks for doing the debugging, this is very helpful and saving me a lot of time :)

This is exactly the problem I expected, and I believe we should be able to workaround it in grub-installer.

Marking the bug as Triaged; I'll reproduce this setup and experiment a bit with changes to grub-installer to come up with a way to fix this.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2015-09-17 13:48 EDT-------
Mathieu,

> Mauricio, thanks for doing the debugging, this is very helpful and saving me
> a lot of time :)

You're welcome!

> This is exactly the problem I expected, and I believe we should be able to
> workaround it in grub-installer.

Great.
I haven't looked further yet, but know this works on at least one other distro.
So, I suspected grub2 perhaps took a wrong function path somewhere.

I'm curious about what your approach to fix this is, as a newcomer to grub2 code.

> Marking the bug as Triaged; I'll reproduce this setup and experiment a bit
> with changes to grub-installer to come up with a way to fix this.

Thanks. So, I'll leave it with you now.
Of course, if you need any other help w/ this bug, just let me know.

[Mathieu Trudel-Lapierre (cyphermox)]

Any idea which distro you saw supported this? Upstream grub explicitly does not support diskfilter writes (in other words, writing directly to /dev/md* devices, LVM, etc), but rather expects one to write to the underlying device, because there are just too many different cases in which writing directly to the top layer might break things.

My workaround (I'm still testing) would be to have grub-installer pick the underlying devices to install to.

[Mauricio Faria de Oliveira (mfo)]

Got it; the other distro doesn't put the PReP partition on the RAID/md device itself -- it uses the (non-RAID) partition on /one/ of the underlying block devices.

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 7M 0 part
├─sda2 8:2 0 9.3G 0 part /boot
├─sda3 8:3 0 921.3G 0 part
│ └─md127 9:127 0 921.1G 0 raid1 /
├─sda4 8:4 0 1K 0 part
└─sda5 8:5 0 952M 0 part [SWAP]
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 921.3G 0 part
  └─md127 9:127 0 921.1G 0 raid1 /

[Mathieu Trudel-Lapierre (cyphermox)]

Are you building the recipe for installation manually or is this install done with the use of a pre-made recipe?

I'm afraid automatic recipes won't properly identify the PReP partition when it comes up on a RAID (md) device; while it may work properly in the installer, it would likely not be detected correctly by the system when booting.

[Mauricio Faria de Oliveira (mfo)]

@mathieu-tl

Manually.
Attaching installation steps performed (single RAID device on top of single partition-pair of the 2 scsi disks).

[Steve Langasek (vorlon)]

There are multiple related issues here.

 - partman-md does not support assembling a RAID1 array out of a set of whole disks; it only supports assembling an array out of partitions. It *should* support using whole disks, so that you have the option of partitioning the RAID array and having those partitions show through on the underlying block devices in a way that is meaningful to the firmware.
 - in the absence of such support in partman-md, users are led down the garden path *thinking* they're creating arrays out of the disks when they're actually creating full-disk partitions on the component disks and RAIDing those. partman-prep should warn the user *early* (i.e., at the partitioning stage) that they've created themselves an impossible-to-boot partition layout, and guide them to go back to fix it.
 - grub-installer should support installing to multiple PReP partitions in parallel for proper full redundancy in the face of a disk failure. This can be achieved in one of two ways:
  - the user can create a RAID1 of two partitions on different disks (e.g. /dev/sda1+/dev/sdb1 -> /dev/md0), and grub-installer can support installing to this as a PReP partition; or
  - grub-installer can detect multiple PReP partitions (possibly requiring the user to manually specify each one that they want to use) and install the necessary boot record to each of them in turn.

The 2nd and 3rd issues should be relatively straightforward to fix. The first issue is going to require some redesign of partman-md and is not something we'll want to take on for 15.10.

[Mauricio Faria de Oliveira (mfo)]

@vorlon

> - the user can create a RAID1 of two partitions on different disks (e.g. /dev/sda1+/dev/sdb1 -> /dev/md0),
> and grub-installer can support installing to this as a PReP partition; or

IIUIC this (grub-install to a PReP on /dev/md) is not supported by grub2 (LP comment #6), and is worked around w/ a PReP partition that is not a member of a /dev/md device (LP comment #14)

[Steve Langasek (vorlon)]

On Wed, Oct 14, 2015 at 04:27:07PM -0000, Mauricio Faria de Oliveira wrote:
> > - the user can create a RAID1 of two partitions on different disks (e.g. /dev/sda1+/dev/sdb1 -> /dev/md0),
> > and grub-installer can support installing to this as a PReP partition; or

> IIUIC this (grub-install to a PReP on /dev/md) is not supported by grub2
> (LP comment #6), and is worked around w/ a PReP partition that is not a
> member of a /dev/md device (LP comment #14)

Correct, this is currently not supported; I argue that it should be, though
extending grub to support this is not necessarily the top priority.

[Mauricio Faria de Oliveira (mfo)]

Ok, thanks for clarifying it.

[Mathieu Trudel-Lapierre (cyphermox)]

The obvious initial step for this is to enforce the partitioning scheme that we do support (ie. PReP can't be on RAID), and I've been testing a partman-prep update with this.

There's also a big part in grub-installer; I'm preparing a proper fix for this there, pending testing to make sure the firmware understands the way the disks are set up in the case of RAID 1 (because we can't support other RAID levels).

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-prep - 31ubuntu1

---------------
partman-prep (31ubuntu1) wily; urgency=medium

  * Enforce the fact that the PReP partition can't be on RAID; also update
    the templace accordingly. (LP: #1487365)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 15 Oct 2015 11:13:01 -0400

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2015-10-19 14:37 EDT-------
Hi @mathieu-tl,

> There's also a big part in grub-installer; I'm preparing a proper fix for
> this there, pending testing to make sure the firmware understands the way
> the disks are set up in the case of RAID 1 (because we can't support other
> RAID levels).

Can you clarify how this fix to grub-installer works?

I thought the problem was exclusively w/ the partition layout (PReP partition not part of a RAID device), and that since grub2 doesn't support writing to a PReP partition in a RAID device, there wasn't much to do on the grub components of the installer. (i.e., the partition layout would get a non-RAID PReP partition and go on normally from there.)

Thanks!

[Mathieu Trudel-Lapierre (cyphermox)]

There may be a way to make this work, but only for RAID mirrors (level 1), in a particular version of the mdadm format, since both disks should have the same layout and look identical to non-mirrored disks, but it needs more work.

In the meantime, it seems like the supported partition layout should be appropriately enforced by partman-prep on installs. So, indeed one will have to make sure not to install a prep on a RAID device, but there isn't an automated partitioning setup which allows this to be done automatically -- it always either involves a couple of steps to set up RAID and then the partitioning on top, or full automation via preseed (which would be something out of the control of the installer -- up to the user to fix).

[bugproxy (bugproxy)]

------- Comment on attachment From <email address hidden> 2016-01-12 08:12 EDT-------

Hi Canonical @mathieu-tl,

Here's a patch for partman-prep for basic support to Software RAID1 devices.

- It allows for manual and guided partitioning with a PReP partition in one of the component devices (not in the RAID array, which is currently not support by grub2), which is enough for our needs at this time.
- The current limitation is, for guided partitioning only, after the partitions are created in the RAID device, it's required to select the PReP partition in the component device (and just exit w/ Done setting up this partition), to make sure the 'method' file contains 'prep' (autopartitioning renames that to 'method-old', and I didn't find a safe/quick method to rename that back in the correct PReP partition... ideas welcome :- ).

This is the error fixed for Manual partitioning (see patch):

    ~ # tail /var/log/syslog
    <...>
    <...> clear_partitions: Considering /,/dev/sda1.
    <...> main-menu[1679]: (process:12610): mount: mounting /dev/sda1 on /tmp/tmp.VVjm38 failed: Invalid argument
    <...> main-menu[1679]: (process:12610): umount: can't umount /tmp/tmp.VVjm38: Invalid argument
    <...> main-menu[1679]: (process:12610): mount: mounting /dev/sda1 on /mnt/tmpmount failed: Invalid argument

Tested with Trusty jan/12 daily build, in this scenario:
- 2 disks (sda, sdb)
- PReP partition in sda1
- Software RAID1 in 'sda free space #2' (after PReP partition) and 'sdb free space #1' (entire disk)

... with the following partitioning methods:
1) manual partitioning
2) guided partitioning
3) guided partitioning w/ LVM

All have successfully installed and booted.

For reference, the relevant parts of the installer's syslog, and post-install/post-boot partitions/LVs used:

~ # grep 'prep_sync_flag\|grub-installer' /var/log/syslog
<...> anna[6666]: DEBUG: retrieving grub-installer 1.78ubuntu20.3
<...> prep_sync_flag: Not setting the PReP partition flag on Software RAID device '/dev/md0' (writes not yet supported by grub2)
<...> prep_sync_flag: Not setting the PReP partition flag on Software RAID device '/dev/md0' (writes not yet supported by grub2)
<...> prep_sync_flag: Not setting the PReP partition flag on Software RAID device '/dev/md0' (writes not yet supported by grub2)
<...> prep_sync_flag: Not setting the PReP partition flag on Software RAID device '/dev/md0' (writes not yet supported by grub2)
<...> prep_sync_flag: Not setting the PReP partition flag on Software RAID device '/dev/md0' (writes not yet supported by grub2)
<...> prep_sync_flag: Not setting the PReP partition flag on Software RAID device '/dev/md0' (writes not yet supported by grub2)
<...> prep_sync_flag: Not setting the PReP partition flag on Software RAID device '/dev/md0' (writes not yet supported by grub2)
<...> main-menu[1675]: INFO: Menu item 'grub-installer' selected
<...> grub-installer: info: architecture: ppc64el/chrp_ibm
<...> grub-installer: info: Identified partition label for /dev/md0p2: loop
<...> grub-installer: info: Wiping PReP partition /dev/sda1
<...> grub-installer: info: Installing grub on '/dev/sda1'
<...> grub-installer: info: grub-install does not...

[bugproxy (bugproxy)]

------- Comment on attachment From <email address hidden> 2016-01-12 08:15 EDT-------

And here's the instructions followed (to be documented in the ppc64el Ubuntu wiki page) for an example using Software RAID1 with 2 component devices and guided partitioning with LVM.

[Mauricio Faria de Oliveira (mfo)]

@mathieu-tl

This important part of the message has faded in the long comment..

Can this bug be targeted for 14.04.4?

The changes are contained w/in the partman-prep package, which affects only ppc64el/powerpc, and it looks like a scenario/path that hasn't been exercised often previously (haven't seen other bug reports). So, I suspect that, if tried at all previously, it'd be likely to fail (ie, this bug), so little there's little regression potential.

Thanks!

[Brian Murray (brian-murray)]

Hello bugproxy, or anyone else affected,

Accepted partman-prep into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/partman-prep/27ubuntu1.14.04.1 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!

[Mauricio Faria de Oliveira (mfo)]

I verified this on Trusty w/ apt-setup/proposed=true.
The installation finishes fine (no errors on grub-installer), and the system boots fine.
Marking verification-done.

Installation instructions for Software RAID have been documented in the SoftwareRAID [1] wiki page, and linked from the ppc64el wiki page [2].

[1] https://wiki.ubuntu.com/ppc64el/SoftwareRAID
[2] https://wiki.ubuntu.com/ppc64el/

Details from the installer (end of installation) and booted system:

Installer:
---------

~ # grep grub-installer /var/log/syslog
Jan 22 12:53:23 anna[6673]: DEBUG: retrieving grub-installer 1.78ubuntu20.3
Jan 22 13:23:37 main-menu[1674]: INFO: Menu item 'grub-installer' selected
Jan 22 13:23:37 grub-installer: info: architecture: ppc64el/chrp_ibm
Jan 22 13:23:53 grub-installer: info: Identified partition label for /dev/md0p2: loop
Jan 22 13:23:54 grub-installer: info: Wiping PReP partition /dev/sda1
Jan 22 13:24:07 grub-installer: info: Installing grub on '/dev/sda1'
Jan 22 13:24:07 grub-installer: info: grub-install does not support --no-floppy
Jan 22 13:24:07 grub-installer: info: Wiping PReP partition /dev/sda1
Jan 22 13:24:07 grub-installer: info: Running chroot /target grub-install --force "/dev/sda1"
Jan 22 13:24:07 grub-installer: Installing for powerpc-ieee1275 platform.
Jan 22 13:24:13 grub-installer: Installation finished. No error reported.
Jan 22 13:24:13 grub-installer: info: grub-install ran successfully

~ # parted_devices
/dev/sda 17179869184 QEMU QEMU HARDDISK
/dev/sdb 17179869184 QEMU QEMU HARDDISK
/dev/mapper/mauricfo4--vg-swap_1 754974720 Linux device-mapper (linear)
/dev/mapper/mauricfo4--vg-root 16139681792 Linux device-mapper (linear)
/dev/md0 17161912320 Linux Software RAID Array

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

Booted:
------

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinux-4.2.0-26-generic root=/dev/mapper/mauricfo4--vg-root ro splash quiet nomdmonddf nomdmonisw vt.handoff=7

$ mount | grep ' / '
/dev/mapper/mauricfo4--vg-root on / type ext4 (rw,errors=remount-ro)

$ sudo lvm pvs
  PV VG Fmt Attr PSize PFree
  /dev/md0p3 mauricfo4-vg lvm2 a-- 15.73g 0

$ cat /proc/swaps
Filename Type Size Used Priority
/dev/dm-1 partition 737216 0 -1

$ ls -l /dev/mapper/mauricfo4--vg-swap_1
lrwxrwxrwx 1 root root 7 Jan 22 09:13 /dev/mapper/mauricfo4--vg-swap_1 -> ../dm-1

[Mauricio Faria de Oliveira (mfo)]

Hi @mathieu-tl,

Friendly asking. The fix has been in -proposed for 7+ days now. Is it making -updates before GA? :)

Thanks,

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-prep - 27ubuntu1.14.04.1

---------------
partman-prep (27ubuntu1.14.04.1) trusty; urgency=medium

  * Better handle PReP partitions created for RAID installs (or in other cases
    where there are multiple partitioning passes): (LP: #1487365)
    - Check filesystem too for a valid PReP partition, in case method was wiped
      in a previous run of partman.
    - Set filesystem to prep in init.d/prep.
    - Remove mountpoints file when setting up a prep partition.
    - Never write the prep flag if we're working on a partition for which the
      parent device is a mdadm array.
    - Enforce the fact that the PReP partition can't be on RAID; also update
      the template accordingly.

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 19 Jan 2016 14:46:49 -0500

[Chris J Arges (arges)]

The verification of the Stable Release Update for partman-prep 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.

[Mauricio Faria de Oliveira (mfo)]

@mathieu-tl

Thank you very much ;-)