you might do a fdisk -l sdb and see what the partition table looks
like and what type of table it is.

And run this:
 dd if=/dev/sdb bs=1M count=2 | xxd -a  | more
my first block (0000) is all 00 (this is where the  partition table
goes) and my md header looks like this:

00001000: fc4e 2ba9 0100 0000 0100 0000 0000 0000  .N+.............
00001010: ea9b 97b7 9301 0e79 ef9a ac45 a0b8 4276  .......y...E..Bv
00001020: 6c6f 6361 6c68 6f73 742e 6c6f 6361 6c64  localhost.locald
00001030: 6f6d 6169 6e3a 3133 0000 0000 0000 0000  omain:13........


On Wed, Jan 24, 2024 at 4:22 PM Robin Hill [off-list ref] wrote:

There have been reported cases of BIOSes auto-creating partitions on
disks, so this is certainly a possibility. I used to use bare disks but
have switched to partitions instead, just to prevent this sort of thing
from happening.

Cheers,
    Robin

On Wed Jan 24, 2024 at 03:44:55PM -0600, Roger Heflin wrote:

quoted

Well, if you have a /dev/sdb1 device and you think the mdadm device is
/dev/sdb (not sdb1) then SOMEONE added a partition table at some point
in time or you are confused what you mdadm device is.   if sdb is a
mdadm device and it has a partition table then mdadm --examine may see
the partition table and report that and STOP reporting anything else.

And note that that partition table could have been added at any point
in time since the prior reboot.  I have found (and fixed) ones that
were added years earlier and found on the next reboot for something
similar a year or 2 later.  On my own stuff before a hardware/mb
upgrade i will do a reboot to make sure that it reboots cleanly as all
sorts of stuff can happen (ie like initramfs/kernel  changes causing a
general failure to boot).

On Wed, Jan 24, 2024 at 3:31 PM RJ Marquette [off-list ref] wrote:

quoted

I didn't touch the drives.  I shut down the computer with everything working fine, swapped motherboards, booted the new board, and discovered this problem immediately when the computer failed to boot because the array wasn't up and running.  I definitely haven't run fdisk or other disk partitioning programs on them.

Other than the modifications to the mdadm.conf to describe the drives and partitions (none of which have made any difference), I modified my fstab to comment out the raid array so the computer would boot normally.  I've been trying to figure out what is going on ever since.  I've tried to avoid doing anything that might write to the drives.

I thought this upgrade would take an hour or two to swap hardware, not days of troubleshooting.  That was the advantage of software RAID, I thought.

Thanks.
--RJ




On Wednesday, January 24, 2024 at 04:20:51 PM EST, Roger Heflin [off-list ref] wrote:





Are you sure you did not partition devices that did not previously
have partition tables?

Partition tables will typically cause the under device (sda) to be
ignored by all of tools since it should never having something else
(except the partition table) on it.

I have had to remove incorrectly added partition tables/blocks to make
lvm and other tools again see the data.  Otherwise the tools ignore
it.

On Wed, Jan 24, 2024 at 12:06 PM RJ Marquette [off-list ref] wrote:

quoted

Other than sdc (as you noted), the other array drives come back like this:

root@jackie:/etc/mdadm# mdadm --examine /dev/sda
/dev/sda:
 MBR Magic : aa55
Partition[0] :  4294967295 sectors at            1 (type ee)

root@jackie:/etc/mdadm# mdadm --examine /dev/sda1
mdadm: No md superblock detected on /dev/sda1.


Trying your other suggestion:
root@jackie:/etc/mdadm# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sde1 /dev/sdf1 /dev/sdg1
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: /dev/sdb1 has no superblock - assembly aborted

root@jackie:/etc/mdadm# mdadm --assemble /dev/md0 /dev/sdb /dev/sde /dev/sdf /dev/sdg
mdadm: Cannot assemble mbr metadata on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted


Basically I've tried everything here:  https://raid.wiki.kernel.org/index.php/Linux_Raid

The impression I'm getting here is that we aren't really sure what the issue is.  I think tonight I'll play with some of the BIOS settings and see if there's something in there.  If not I'll swap back to the old motherboard and see what happens.

Thanks.
--RJ





On Wednesday, January 24, 2024 at 12:06:26 PM EST, Sandro [off-list ref] wrote:





On 24-01-2024 13:17, RJ Marquette wrote:

quoted

When I try the command you suggested below, I get:
root@jackie:/etc/mdadm# mdadm --assemble /dev/md0 /dev/sd{a,b,e,f,g}1
mdadm: no recogniseable superblock on /dev/sda1
mdadm: /dev/sda1 has no superblock - assembly aborted

Try `mdadm --examine` on every partition / drive that is giving you
trouble. Maybe you are remembering things wrong and the raid device is
/dev/sda and not /dev/sda1.

You can also go through the entire list (/dev/sd*), you posted earlier.
There's no harm in running the command. It will look for the superblock
and tell you what has been found. This could provide the information you
need to assemble the array.

Alternatively, leave sda1 out of the assembly and see if mdadm will be
able to partially assemble the array.

-- Sandro