You never booted windows or any other non-linux boot image that might have decided to "fix" the disk's missing partition tables? And when messing with the install did you move the disks around so that some of the disk could have been on the intel controller with raid set at different times? That specific model of marvell controller does not list support raid, but other models in the same family do, so it may also have an option in the bios that "fixes" the partition table. Any number of id10t's writing tools may have wrongly decided that a disk without a partition table needs to be fixed. I know the windows disk management used to (may still) complain about no partitions and prompt to "fix" it. I always run partitions on everything. I have had the partition save me when 2 different vendors hardware raid controllers lost their config (random crash, freaked on on fw upgrade) and when the config was recreated seem to "helpfully" clear a few kb at the front of the disk. Rescue boot, repartition, mount os lv, and reinstall grub fixed those. On Thu, Jan 25, 2024 at 9:17 AM RJ Marquette <rjm1@xxxxxxxxx> wrote: > > It's an ext4 RAID5 array. No LVM, LUKS, etc. > > You make a good point about the BIOS explanation - it seems to have affected only the 5 RAID drives that had data on them, not the spare, nor the other system drive (and the latter two are both connected to the motherboard). How would it have decided to grab exactly those 5? > > Thanks. > --RJ > > > On Thursday, January 25, 2024 at 10:01:40 AM EST, Pascal Hambourg <pascal@xxxxxxxxxxxxxxx> wrote: > > > > > > On 25/01/2024 at 12:49, RJ Marquette wrote: > > root@jackie:/home/rj# /sbin/fdisk -l /dev/sdb > > Disk /dev/sdb: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors > > Disk model: Hitachi HUS72403 > > Units: sectors of 1 * 512 = 512 bytes > > Sector size (logical/physical): 512 bytes / 4096 bytes > > I/O size (minimum/optimal): 4096 bytes / 4096 bytes > > Disklabel type: gpt > > Disk identifier: AF5DC5DE-1404-4F4F-85AF-B5574CD9C627 > > > > Device Start End Sectors Size Type > > /dev/sdb1 2048 5860532223 5860530176 2.7T Microsoft basic data > > > > root@jackie:/home/rj# cat /sys/block/sdb/sdb1/start > > 2048 > > root@jackie:/home/rj# cat /sys/block/sdb/sdb1/size > > 5860530176 > > The partition geometry looks correct, with standard alignment. > And the kernel view of the partition matches the partition table. > The partition type "Microsoft basic data" is neither "Linux RAID" nor > the default type "Linux flesystem" set by usual GNU/Linux partitioning > tools such as fdisk, parted and gdisk so it seems unlikely that the > partition was created with one of these tools. > > > >>> 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 am a bit suspicious about this cause for two reasons: > - sde, sdf and sdg are affected even though they are connected to the > add-on Marvell SATA controller card which is supposed to be outside the > motherboard RAID scope; > - sdc is not affected even though it is connected to the onboard Intel > SATA controller. > > What was contents type of the RAID array ? LVM, LUKS, plain filesystem ? >
