[Bug 1523637] Comment bridged from LTC Bugzilla

[bugproxy]

------- Comment From ruddk at us.ibm.com 2016-01-25 11:07 EDT-------
(In reply to comment #24)
> Still, we do add PReP partitions for every ppc64el system. This means you're
> doing manual partitioning, and specifically omitting the PReP partition, no?

Actually, no.  The partitioning is the the default chosen.  All I did
was to specify that all of /dev/sdb should be used.

> In this case, is there any way we can recognize this particular system? Is
> it some chrp subtype that we should completely skip the PReP partition for?
> This would mean changes needed in grub-installer, as well as updates to
> partman-auto automatic partitioning recipes.

I suspect that the installer is already recognizing that it does not
need a PReP partition for this system (PowerNV/OPAL):

platform        : PowerNV
model           : 8247-42L
machine         : PowerNV 8247-42L
firmware        : OPAL v3

I think the original replication test system tripped across this issue
because the system was being used in different test roles, and sharing
disk resources between different boot environments.  The alternate disk
found with a PReP partition was being used by a PowerKVM guest when
doing testing for that environment.  This is what the PowerKVM guest
environment reports:

platform        : pSeries
model           : IBM pSeries (emulated by qemu)
machine         : CHRP IBM pSeries (emulated by qemu)

So, it looks like the installer partitioning code is correctly handling
PowerNV vs CHRP.  It's the grub bootloader logic that wants to overwrite
the first PReP partition it finds (if one doesn't exist on the install
drive) that is in question.  Was there some historical reason for not
wanting a PReP partition on some other drive?

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub-installer in Ubuntu.
https://bugs.launchpad.net/bugs/1523637

Title:
  grub-installer fails due to alternate disk partition error - 14.04.3

Status in grub-installer package in Ubuntu:
  Triaged

Bug description:
  ---Problem Description---
  This is the Habanero NV system.
  Try to install Ubuntu 14043.
  It fails to install the GRUB boot loader at the very end of the process.

  ---boot type---
  Network boot
   
  == Comment: #3 - Kevin W. Rudd - 2015-12-02 16:48:46 ==
  This looks to be an issue very similar to the one originally reported
  in Bug 120779 (LP1415918)

  In this case, the install is being done to /dev/sdj, but the
  grub-installer script is finding a PReP partition on /dev/sdr that it
  wants to remove.  It fails because /dev/sdr1 has not been mapped and
  does not exist in /dev

  Dec  2 15:45:46 grub-installer: info: Identified partition label for
  /dev/sdj2: gpt
  Dec  2 15:45:47 grub-installer: info: Wiping PReP partition /dev/sdr1
  Dec  2 15:45:47 grub-installer: dd: invalid number ''
  ...
  Dec  2 15:45:47 main-menu[835]: (process:28150): blockdev: can't open
  '/dev/sdr1': No such file or directory

  /var/log # ls -l /dev/sdj*
  brw-------    1 root     root        8, 144 Dec  2 18:31 /dev/sdj
  brw-------    1 root     root        8, 145 Dec  2 18:24 /dev/sdj1
  brw-------    1 root     root        8, 146 Dec  2 18:24 /dev/sdj2
  brw-------    1 root     root        8, 147 Dec  2 18:24 /dev/sdj3

  /var/log # ls -l /dev/sdr*
  brw-------    1 root     root       65,  16 Dec  2 18:42 /dev/sdr

  One big question I have is:

  Does it make sense to remove a PReP partition on a *different* disk
  than the one being used for the install?  It seems rather heinous to
  be destroying data on a non-install disk.

  == Comment: #4 - Kevin W. Rudd - 2015-12-02 18:17:19 ==
  Hmmm.  This may be key information for replicating this behavior.  It might explain why the partition device entries are not being auto-created for the problem /dev/sdr drive:

  # parted /dev/sdr print
  Warning: /dev/sdr contains GPT signatures, indicating that it has a GPT table.
  However, it does not have a valid fake msdos partition table, as it should.
  Perhaps it was corrupted -- possibly by a program that doesn't understand GPT
  partition tables.  Or perhaps you deleted the GPT table, and are now using an
  msdos partition table.  Is this a GPT partition table?
  Yes/No? Yes                                                               
  Model: ATA ST1000NM0033 (scsi)
  Disk /dev/sdr: 1000GB
  Sector size (logical/physical): 512B/512B
  Partition Table: gpt

  Number  Start   End     Size    File system     Name  Flags
   1      1049kB  8389kB  7340kB                        prep
   2      8389kB  975GB   975GB   ext4
   3      975GB   1000GB  25.1GB  linux-swap(v1)

  == Comment: #7 - Kevin W. Rudd -  2015-12-03 16:11:11 ==
  After a bit more research on this system, it appears that the
  problem drive was previously used for Trusty testing within a
  PowerKVM environment.  To avoid further blocking the test team,
  I temporarily removed the problem drive from the installer's view,
  and the grub-installer was able to continue without further error.

  The primary reason for the failure was that the installer did not
  like the partition on that other drive.  In addition to the parted
  warning listed in comment 4, kpartx also complained:

    Warning: Disk has a valid GPT signature but invalid PMBR.

  Either this partition was slightly corrupted, or this is just a side
  effect of the earlier PowerKVM storage mapping to the /dev/vdb device.

  This still begs the question:

  ? Should the grub-installer really be touching other drives ?

  It seems to me that a multi-boot environment is still valid, and
  destroying partitions on alternate drives could really mess up the
  testing on a shared resource.

  == Comment: #12 - Paulo Flabiano Smorigo - 2015-12-07 13:15:01 ==
  Even if Ubuntu overwrite PReP from other disk you can still boot the older system because grub-mkconfig (using os-prober) seeks for other systems and add them to the config file.

  The problem with this approach is that old system can overwrite PReP
  partition for some reason (i.e. an update) and its grub-mkconfig has
  the OS seeker disabled.

  For me, the safer approach is to have PReP in the same disk as Kevin
  is suggesting.

  I believe that we should have ask Canonical for an option about it
  since grub-installer is a Debian/Ubuntu tool.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1523637/+subscriptions