[Bug 855871] Re: Grub install fails after manual xfs partitioning

[Colin Watson]

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)

** Package changed: ubiquity (Ubuntu) => partman-partitioning (Ubuntu)

** Changed in: partman-partitioning (Ubuntu)
       Status: Confirmed => Triaged

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

Title:
  Grub install fails after manual xfs partitioning

Status in “partman-partitioning” package in Ubuntu:
  Triaged

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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-partitioning/+bug/855871/+subscriptions