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 <robin@xxxxxxxxxxxxxxx> 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: > > > 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 <rjm1@xxxxxxxxx> wrote: > > > > > > 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 <rogerheflin@xxxxxxxxx> 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 <rjm1@xxxxxxxxx> wrote: > > > > > > > > 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 <lists@xxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 24-01-2024 13:17, RJ Marquette wrote: > > > > > > > > > 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 > > > > > > > > >
