Grub install fails after manual xfs partitioning

Bug #855871 reported by Chad A Davis
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
partman-partitioning (Ubuntu)
Fix Released
Medium
Colin Watson

Bug Description

I chose the manual partitioning option.
I first created a new partition table.
Then I created a 5 GB swap at the beginning of the disk (RAM is 4GB)
I left a 1 GB gap in the middle of the disk, unpartitioned, to not use up the entire disk.
Then I created a 300-something GB XFS partition at the end of the disk.

Installation continues until grub tries to install and fails. Grub says that it has failed. I opted to continue without installing the bootloader. Upon finishing the installation, ubiquity also crashed, which is what this apport report caught. The real problem appears to be with grub/partman though.

This is ubuntu-oneiric-desktop-amd64+mac.iso from 2011-09-21

This is a MacBookPro6,2

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: ubiquity 2.7.34
ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 1.23-0ubuntu1
Architecture: amd64
CasperVersion: 1.284
Date: Wed Sep 21 21:34:42 2011
LiveMediaBuild: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64+mac (20110921.1)
ProcEnviron:
 LANGUAGE=de_DE.UTF-8
 PATH=(custom, no user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Chad A Davis (chadadavis) wrote :
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote : Traceback

Exception during installation:
Sep 21 21:34:25 ubuntu plugininstall.py: Traceback (most recent call last):
Sep 21 21:34:25 ubuntu plugininstall.py: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 256, in start
Sep 21 21:34:25 ubuntu plugininstall.py: self.db.progress('START', 0, 100, self.title)
Sep 21 21:34:25 ubuntu plugininstall.py: File "/usr/lib/python2.7/dist-packages/debconf.py", line 60, in <lambda>
Sep 21 21:34:25 ubuntu plugininstall.py: lambda *args, **kw: self.command(command, *args, **kw))
Sep 21 21:34:25 ubuntu plugininstall.py: File "/usr/lib/python2.7/dist-packages/debconf.py", line 81, in command
Sep 21 21:34:25 ubuntu plugininstall.py: status = int(status)
Sep 21 21:34:25 ubuntu plugininstall.py: ValueError: invalid literal for int() with base 10: ''
Sep 21 21:34:25 ubuntu plugininstall.py:

tags: added: installer-crash
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Thanks for your report.

Here is the error
Sep 21 21:30:48 ubuntu grub-installer: info: architecture: amd64/mac
Sep 21 21:30:49 ubuntu grub-installer: info: Identified partition label for /dev/sda2: gpt
Sep 21 21:30:51 ubuntu grub-installer: dpkg: Warnung: there's no installed package matching grub
Sep 21 21:30:51 ubuntu grub-installer: dpkg: Warnung: there's no installed package matching grub-legacy
Sep 21 21:30:51 ubuntu grub-installer: dpkg: Warnung: there's no installed package matching grub-efi
Sep 21 21:30:51 ubuntu grub-installer: dpkg: Warnung: there's no installed package matching grub-efi-amd64-bin
Sep 21 21:30:51 ubuntu grub-installer: dpkg: Warnung: there's no installed package matching grub-efi-amd64
Sep 21 21:30:51 ubuntu grub-installer: dpkg: Warnung: there's no installed package matching grub-efi-ia32-bin
Sep 21 21:30:51 ubuntu grub-installer: dpkg: Warnung: there's no installed package matching grub-efi-ia32
Sep 21 21:30:52 ubuntu grub-installer: info: Installing grub on '/dev/sda'
Sep 21 21:30:52 ubuntu grub-installer: info: grub-install supports --no-floppy
Sep 21 21:30:52 ubuntu grub-installer: info: Running chroot /target grub-install --no-floppy --force "/dev/sda"
Sep 21 21:30:53 ubuntu grub-installer: /usr/sbin/grub-setup: Warnung: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!.
Sep 21 21:30:53 ubuntu grub-installer: /usr/sbin/grub-setup: Warnung: Einbettung ist nicht möglich. GRUB kann in dieser Konfiguration nur mittels Blocklisten installiert werden. Blocklisten sind allerdings UNZUVERLÄSSIG und deren Verwendung wird daher nicht empfohlen..
Sep 21 21:30:58 ubuntu grub-installer: /usr/sbin/grub-setup: Fehler: »/boot/grub/core.img« kann nicht korrekt gelesen werden.
Sep 21 21:30:58 ubuntu grub-installer: error: Running 'grub-install --no-floppy --force "/dev/sda"' failed.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
Chad A Davis (chadadavis) wrote :

In another installation, also with xfs, I left a 1-2 GB unpartitioned space at the beginning of the disk (plenty of space for the bios_grub partition), but grub again failed.

In another installation, I also tried the same patition layout as the original bug report (first 4GB swap, 1-2 GB unpartitioned, ~300 GB root partition) with ext4 rather than xfs and the bios_grub partition was created correctly and the system boots as expected.

I'm trying to narrow down whether the problem occurs due to deciding where the bios_grub partition gets placed, but it seems to only occur with xfs.

Revision history for this message
Colin Watson (cjwatson) wrote :

The bios_grub partition is not automatically created simply by virtue of leaving some blank space. If you're using manual partitioning, you do need to set it up by hand.

That said, it's still a bug that GRUB is failing hard in this case, just a less serious one.

Changed in ubiquity (Ubuntu):
importance: Undecided → Medium
assignee: nobody → Colin Watson (cjwatson)
Colin Watson (cjwatson)
tags: added: rls-mgr-o-tracking
Revision history for this message
Chad A Davis (chadadavis) wrote :

That's interesting, because it is not necessary to create any additional partition when I do manual partitioning with an ext4 filesystem. I've posted some install logs about that in bug 856763 .

I still believe this bug here to be unique because it causes grub to fail to install, which does not occur e.g. with reiserfs.

tags: added: rls-mgr-p-tracking
removed: rls-mgr-o-tracking
Revision history for this message
Chad A Davis (chadadavis) wrote :

If I re-install over a system that was installed using 'guided: entire disk' partitioning and simply re-format the ext4 root partition as an xfs partition, the grub installation error does not re-occur.

The system still fails to boot, however, which seems to be a different bug (bug 856763).

Steve Langasek (vorlon)
tags: added: rls-p-tracking
Steve Langasek (vorlon)
Changed in ubiquity (Ubuntu):
milestone: none → ubuntu-12.04
Revision history for this message
Colin Watson (cjwatson) wrote :

You've noted that reiserfs and xfs behave differently from ext4 here. The reason for this is that GPT disks ordinarily require you to dedicate a partition to boot loader code (as distinct from the MBR format where boot loader code was often stuffed into unused space in a rather risky way). In your tests, you have not been doing so. This means that GRUB falls back to leaving its core image in the filesystem containing /boot/grub, which it does by computing "block lists" - that is, a sequence of offset/length pairs for each of the blocks on disk making up /boot/grub/core.img - and storing those in the boot sector.

At this point you are in very risky territory. Firstly, GRUB has to check that it can actually read from the filesystem using its own code bypassing the kernel's filesystem code, and historically XFS has not played very well with this; something like that may well be the cause of the specific failure here. Secondly, you're relying on the filesystem not moving blocks around, which is a particularly unsafe assumption with reiserfs but may very well break with other filesystems too. A dedicated boot loader partition is much safer. In bug 856763, you indicate that you thought you were leaving "several megabytes free at the beginning of the disk for the GPT/bios_grub partition", but this *is not what happens* - what is actually happening is that that space is left entirely unused and GRUB falls back to the dangerous blocklist approach instead. It happens to get away with it for ext4, at least for long enough to complete an installation and boot, but that doesn't make it a good idea. You must actually create the partition or it will not be used.

Therefore, based on this reasoning, I intend to fix both this bug and bug 856763 by adding a warning to manual partitioning if you fail to create an EFI System Partition or a BIOS Boot Partition on systems with only GPT disks, as appropriate for the firmware.

no longer affects: ubiquity (Ubuntu Oneiric)
affects: ubiquity (Ubuntu) → partman-partitioning (Ubuntu)
Changed in partman-partitioning (Ubuntu):
status: Confirmed → Triaged
Colin Watson (cjwatson)
Changed in partman-partitioning (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-partitioning - 83ubuntu2

---------------
partman-partitioning (83ubuntu2) precise; urgency=low

  * On systems with only GPT disks, check that an EFI System Partition or a
    BIOS Boot Partition exists, as appropriate (LP: #855871).
 -- Colin Watson <email address hidden> Tue, 20 Mar 2012 18:17:34 +0000

Changed in partman-partitioning (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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