bugGNU GRUB - Bugs: bug #38406, GRUB assembles wrong disks for md...


You are not allowed to post comments on this tracker with your current authentication level.

bug #38406: GRUB assembles wrong disks for md RAID device

Submitter:  Marc Warne (GigaTux) <gigatux>
Submitted:  Mon 25 Feb 2013 11:25:32 AM UTC
Category:  Booting Severity:  Major
Priority:  5 - Normal Item Group:  Software Error
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  Marc Warne
Open/Closed:  Open Release:  1.98
Release:  Reproducibility:  Every Time
Planned Release:  2.03+

Sun 21 Oct 2018 08:32:20 PM UTC, comment #2: 

I think I recently got bit by this as well.  I have 3 disks with part in a 3 way raid10 for my root fs, and the rest in a raid5 for media storage.  After some updates, I rebooted and got all kinds of weird errors trying to load any kernel.  I booted from a liveusb and poked around and it turned out that one of the disks had been marked as failed in the raid10 for some reason a month or two before and I hadn't noticed.  After re-adding the disk to the array and resyncing it, I was able to boot again.  GRUB really needs to pay attention to the failed flags in the most recently updated metadata block.

Phillip Susi <psusi>
Wed 02 Mar 2016 02:21:24 PM UTC, comment #1: 

Fixing this is somewhat hairy. Postponing after release to avoid introducing worse bugs

Vladimir Serbinenko <phcoder>
Group administrator
Mon 25 Feb 2013 11:25:32 AM UTC, original submission:  


I haven't yet attempted to reproduce this as it occurred on a production system that I needed to get up as soon as I could, but when it was an issue, it was fully repeatable.


  1. /boot stored on a four disk MD RAID-1 array.
  2. Two disks had failed simultaneously.
  3. Upon GRUB boot, GRUB was assembling the two failed disks (which comprised a valid but somewhat old filesystem) instead of the two more recently updated disks.

My best guess is that GRUB isn't taking account the relevant timestamps on the RAID members which should specify when they were last updated.

It should be possible to reproduce this by failing two md devices simultaneously and then getting GRUB to use it as its filesystem. I'm not sure which two would need to fail (e.g. does GRUB just use the devices with the lowest numbers?) but I think some simple checking of timestamps would be required.

Marc Warne (GigaTux) <gigatux>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by psusi (Posted a comment)
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by gigatux (Submitted the item)
  • -email is unavailable- added by gigatux

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-02 phcoder Planned ReleaseNone 2.03+
    2013-02-25 gigatux Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.12