dd if=/dev/sdb of=/root/sdb.512byte.block.save bs=512 count=1 (repeat on each damaged drive with its name). then dd if=/dev/zero of=/dev/sdb bs=512 count=1 (for each disk). the first command makes a copy of that first block just in case and the 2nd command clears the first 512 bytes that contains the partition data. On Wed, Jan 24, 2024 at 7:13 PM RJ Marquette <rjm1@xxxxxxxxx> wrote: > > It looks like this is what happened after all. I searched for "MBR Magic aa55" and found someone else with the same issue long ago: https://serverfault.com/questions/580761/is-mdadm-raid-toast Looks like his was caused by a RAID configuration option in BIOS. I recall seeing that on mine; I must have activated it by accident when setting the boot drive or something. > > I swapped the old motherboard back in, no improvement, so I'm back to the new one. I'm now running testdisk to see if I can repair the partition table. > > Thanks. > --RJ > > > > On Wednesday, January 24, 2024 at 04:45:19 PM EST, Roger Heflin <rogerheflin@xxxxxxxxx> 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 > > > > > >
