Unable to boot degraded RAID-1 array from second disk

Bug #873009 reported by James Page on 2011-10-12
This bug affects 4 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Colin Watson

Bug Description

Following the RAID test case from the ISO tracker; installs fine, boots normally with both disks, boots fine with second disk disconnected, rebuilds array manually when second disk reconnected but grub won't boot with just the second disk in the array attached.

Reproduced on release images for Oneiric, amd64 and i386.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: grub2 (not installed)
ProcVersionSignature: Ubuntu 3.0.0-12.20-server 3.0.4
Uname: Linux 3.0.0-12-server x86_64
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Wed Oct 12 19:14:26 2011
InstallationMedia: Ubuntu-Server 11.10 "Oneiric Ocelot" - Release amd64 (20111011)
SourcePackage: grub2
UpgradeStatus: No upgrade log present (probably fresh install)

tags: added: iso-testing
Colin Watson (cjwatson) on 2011-10-12
Changed in grub2 (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
importance: Undecided → High
status: New → In Progress
tags: added: rls-mgr-p-tracking
Steve Langasek (vorlon) on 2011-10-26
tags: added: rls-p-tracking
Steve Langasek (vorlon) on 2011-11-16
Changed in grub2 (Ubuntu):
milestone: none → ubuntu-12.04
Colin Watson (cjwatson) on 2012-04-05
summary: - Unabled to boot degraded RAID-1 array from second disk
+ Unable to boot degraded RAID-1 array from second disk
Colin Watson (cjwatson) wrote :

I had a look at this today. I only got as far as setting up test environments before getting distracted by other things, but my preliminary result is that I don't seem to be able to reproduce this immediately in precise, so it may be that we've actually fixed this and I didn't notice! I'll try to verify this more carefully after the Easter weekend.

Colin Watson (cjwatson) wrote :

I've isolated the fix to 1.99-20ubuntu1 by bisection, using KVM snapshots to restore to a known state before each attempt. 1.99-18ubuntu1 failed in the way described in this bug, but 1.99-20ubuntu1 boots successfully from either disk. (As previously noted, the current version in precise, 1.99-21ubuntu2, also succeeds.)

Although I hadn't been expecting it to fix this particular bug - my intention was to improve 4K sector support - this was almost certainly a consequence of "Support non-512B sectors and agglomerate reads", backported from upstream in 1.99-19. That makes a degree of sense since it's quite possible that the pattern of reads caused by using a degraded RAID array tickled earlier bugs in GRUB's disk cache layer.

Changed in grub2 (Ubuntu):
importance: High → Undecided
milestone: ubuntu-12.04 → none
status: In Progress → Fix Released
importance: Undecided → High
milestone: none → ubuntu-12.04
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers