[Bug 1523637] Comment bridged from LTC Bugzilla
bugproxy
bugproxy at us.ibm.com
Wed Feb 10 15:50:16 UTC 2016
------- Comment From ruddk at us.ibm.com 2016-02-10 10:30 EDT-------
Hi Mathieu.
Our test team tested using the specific URL you provided and also
continue to encounter the failure. I am currently re-running my own
test for confirmation of previous timelines.
(In reply to comment #50)
> HI,
>
> Tried installing ubuntu14.04.4 using netboot install which is pointed to
> 'http://ports.ubuntu.com/ubuntu-ports/dists/trusty-proposed/main/installer-
> ppc64el/20101020ubuntu318.35/images/wily-netboot/' this netboot image and
> it still fails with same error as earlier on Habenaro system bmc-ray.
>
>
>
> ????????? [!!] 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> ?
> ? ?
> ?????????????????????????????????????????????????????????????????????
>
>
> Regards,
> Indira
------- Comment From ruddk at us.ibm.com 2016-02-10 10:47 EDT-------
My retest succeeded, so I'm re-marking this bug back to verification-needed while I work on resolving why the test team's test is failing. Please stand by a bit.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to libdebian-installer in Ubuntu.
https://bugs.launchpad.net/bugs/1523637
Title:
grub-installer fails due to alternate disk partition error - 14.04.3
Status in debian-installer package in Ubuntu:
Fix Released
Status in libdebian-installer package in Ubuntu:
Fix Released
Status in debian-installer source package in Trusty:
Fix Committed
Status in libdebian-installer source package in Trusty:
Fix Committed
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/debian-installer/+bug/1523637/+subscriptions
More information about the foundations-bugs
mailing list