public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: karl@aspodata.se
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Fun with mdadm (Software RAID)
Date: Fri, 20 Dec 2024 15:50:53 +0100 (CET)	[thread overview]
Message-ID: <20241220145053.B361C85A435A@turkos.aspodata.se> (raw)
In-Reply-To: <Z2VLTVQmRBwDulyX@MAC.fritz.box>

Alan Mackenzie:
...
> The cause was me booting up the machine with a rescue disk.  This
> assembled my RAID partitions /dev/md127 and /dev/md126 reversed, but
> also wrote those wrong identifiers, 126 and 127, into the "preferred
> minor" field of the partitions' super blocks.  In essence, they got
> swapped.
...
> Just for the record, all my RAID arrays have metadata version 0.90, the
> (old fashioned) one that allows auto-assembly by the kernel without the
> need of an initramfs.
> 
> The moral of the story: if your system uses software RAID, be careful
> indeed before you boot up with a rescue disk.

So, why don't you simple add "root=902 md=2,/dev/sda2,/dev/sdb2" or similar to
your boot loader kernel command line ?

///

 And... what is the need for dynamic minors now when dev_t is 32bits:

$ grep dev_t /Net/git/linux-stable/include/linux/types.h 
typedef u32 __kernel_dev_t;
typedef __kernel_dev_t          dev_t;
$

 and we have 20 bits minors:

$ grep -A1 MINORBITS /Net/git/linux-stable/include/linux/kdev_t.h 
#define MINORBITS       20
#define MINORMASK       ((1U << MINORBITS) - 1)

#define MAJOR(dev)      ((unsigned int) ((dev) >> MINORBITS))
#define MINOR(dev)      ((unsigned int) ((dev) & MINORMASK))
#define MKDEV(ma,mi)    (((ma) << MINORBITS) | (mi))

Regards,
/Karl Hammar




  reply	other threads:[~2024-12-20 14:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-20 10:47 [gentoo-user] Fun with mdadm (Software RAID) Alan Mackenzie
2024-12-20 14:50 ` karl [this message]
2024-12-20 15:28   ` Alan Mackenzie
2024-12-20 17:44     ` karl
2024-12-20 20:19       ` Alan Mackenzie
2024-12-20 20:38         ` Hoël Bézier
2024-12-20 20:53           ` Alan Mackenzie
2024-12-20 22:02         ` karl
2024-12-30  4:08           ` Frank Steinmetzger
2024-12-20 22:02         ` karl
2024-12-21 12:43           ` Alan Mackenzie
2024-12-21 16:36             ` Alan Mackenzie
2024-12-21 16:45               ` karl
2024-12-21 16:58                 ` Alan Mackenzie
2024-12-22 13:08                   ` Alan Mackenzie
2024-12-22 12:16             ` Wols Lists
2024-12-22 12:08         ` Wols Lists
2024-12-22 12:02       ` Wols Lists
2024-12-22 13:43         ` Alan Mackenzie
2024-12-22 15:29           ` Peter Humphrey
2024-12-22 16:53             ` Wols Lists
2024-12-22 20:05               ` Alan Mackenzie
2024-12-25 21:16                 ` Steven Lembark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241220145053.B361C85A435A@turkos.aspodata.se \
    --to=karl@aspodata.se \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox