bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #54192] Fails to assemble RAID6 on sata/scsi devices, but works wit


From: Lars Kruse
Subject: [bug #54192] Fails to assemble RAID6 on sata/scsi devices, but works with virtio (qemu)
Date: Tue, 26 Jun 2018 21:24:55 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0

URL:
  <http://savannah.gnu.org/bugs/?54192>

                 Summary: Fails to assemble RAID6 on sata/scsi devices, but
works with virtio (qemu)
                 Project: GNU GRUB
            Submitted by: sumpfralle
            Submitted on: Wed 27 Jun 2018 01:24:54 AM UTC
                Category: Disk &amp; Partition
                Severity: Major
                Priority: 5 - Normal
              Item Group: Software Error
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 
                 Release: 2.02
         Reproducibility: Every Time
         Planned Release: None

    _______________________________________________________

Details:

Hello,

I configured RAID6 consisting of four drives.
The disks use the GPT partition scheme.
The following partitions are defined on each disk:
* 1M - BIOS Boot
* the rest - LVM RAID

The RAID is complete (non-degraded) and uses the metadata version 1.2.
The RAID contains an LVM (which contains the root filesystem, incl. /boot/).
But I never saw a sign, that the RAID is assembled by Grub - thus I guess, the
LVM is not relevant.
The system runs Debain Stretch.

When booting the server, the rescue console is visible and an error message
regarding the missing boot blockdevice is presented.
"ls" shows only the partitions of the disks (e.g. "(hd0,gpt1)"). The RAID is
not visible.


The same error is shown (and "ls" outputs the same) when trying to boot these
disks via qemu as "scsi" disks:

qemu-system-x86_64 \
    -drive format=raw,if=scsi,readonly,file=/dev/sda \
    -drive format=raw,if=scsi,readonly,file=/dev/sdb \
    -drive format=raw,if=scsi,readonly,file=/dev/sdc \
    -drive format=raw,if=scsi,readonly,file=/dev/sdd


When using the "virtio" blockdevice driver of qemu it magically works:

qemu-system-x86_64 \
    -drive format=raw,if=virtio,readonly,file=/dev/sda \
    -drive format=raw,if=virtio,readonly,file=/dev/sdb \
    -drive format=raw,if=virtio,readonly,file=/dev/sdc \
    -drive format=raw,if=virtio,readonly,file=/dev/sdd

I am surprised by the different behaviour of both blockdevice virtualization
backends. Everything else remained unchanged. The disks (and their partitions)
can obviously be read while using the "scsi" interface (as demonstrated by the
"ls" command).
Thus it feels a bit like a subtile interaction between the sata/scsi module
and the RAID module (crazy wild guessing).

btw.: Booting from a RAID1 with metadata version 0.9 (instead of RAID6 with
v0.9) works also with the "scsi" interface via qemu.


Do you have any idea, how I could debug the situation?

Thank you for your time!

Cheers,
Lars




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54192>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]