On 06/16/2021 02:02 PM, Piergiorgio Sartor wrote: > On Mon, Jun 14, 2021 at 01:35:06PM -0400, H wrote: >> On 06/14/2021 04:17 AM, antlists wrote: >>> On 13/06/2021 23:51, H wrote: >>>> I would very much appreciate if anyone can suggest how to check the last items? Once this has been verified the next step would be to get mdadm RAID-1 going again. >>> An obvious first step is to run lsdrv. https://raid.wiki.kernel.org/index.php/Asking_for_help >>> >>> That will hopefully find anything there. >>> >>> But before you do anything BACKUP BACKUP BACKUP. It's only 250GB from what I can see - getting your hands on a 500GB or 1TB drive shouldn't be hard, and a quick stream of the partition shouldn't take long (although a "cp -a" might be safer, given that LUKS is involved ...). >>> >>> Cheers, >>> Wol >> Thank you for the link, here is the output from the various packages listed on that page: >> >> uname -a >> >> Linux tsp520c 3.10.0-1160.2.2.el7.x86_64 #1 SMP Tue Oct 20 16:53:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux >> >> mdadm --version >> >> mdadm - v4.1 - 2018-10-01 >> >> smartctl --xall /dev... >> >> I skipped this since the output is lengthy and not sure which parts we might need. >> >> mdadm --examine /dev/sdb (and /dev/sdc as well as individual partitions) >> >> [root@tsp520c ~]# mdadm --examine /dev/sdb >> /dev/sdb: >> MBR Magic : aa55 >> Partition[0] : 500118191 sectors at 1 (type ee) >> [root@tsp520c ~]# mdadm --examine /dev/sdb1 >> /dev/sdb1: >> MBR Magic : aa55 >> Partition[0] : 1701978223 sectors at 1948285285 (type 6e) >> Partition[3] : 441 sectors at 28049408 (type 00) >> [root@tsp520c ~]# mdadm --examine /dev/sdb2 >> mdadm: No md superblock detected on /dev/sdb2. >> [root@tsp520c ~]# mdadm --examine /dev/sdb3 >> mdadm: No md superblock detected on /dev/sdb3. >> [root@tsp520c ~]# >> >> [root@tsp520c ~]# mdadm --examine /dev/sdc >> /dev/sdc: >> MBR Magic : aa55 >> Partition[0] : 500118191 sectors at 1 (type ee) >> [root@tsp520c ~]# mdadm --examine /dev/sdc1 >> /dev/sdc1: >> MBR Magic : aa55 >> Partition[0] : 1701978223 sectors at 1948285285 (type 6e) >> Partition[3] : 441 sectors at 28049408 (type 00) >> [root@tsp520c ~]# mdadm --examine /dev/sdc2 >> mdadm: No md superblock detected on /dev/sdc2. >> [root@tsp520c ~]# mdadm --examine /dev/sdc3 >> mdadm: No md superblock detected on /dev/sdc3. > It does not seem there is any Linux RAID around. > > Maybe it was the "fake RAID" or whatever, which > was handled by the motherboard. > > If the data is accessible, just copy everything > somewhere else and reconfigure the storage. > > bye, > > pg > >> cat /proc/mdstat >> >> Personalities : >> unused devices: <none> >> >> mdadm --detail /dev/mdx >> >> There are no /dev/md devices >> >> lsdrv >> >> **Warning** The following utility(ies) failed to execute: >> sginfo >> Some information may be missing. >> >> USB [uas] Bus 002 Device 002: ID 0bc2:231a Seagate RSS LLC Expansion Portable {NAADA87P} >> └scsi 0:0:0:0 Seagate Expansion >> └sda 3.64t [8:0] crypto_LUKS {f573965d-f469-4fc2-abf6-8155f7f422c4} >> └dm-4 3.64t [253:4] ext4 {3a94f5a0-058a-4002-9067-27ed211e99f0} >> └Mounted as /dev/mapper/luks-f573965d-f469-4fc2-abf6-8155f7f422c4 @ /run/media/hakan/3a94f5a0-058a-4002-9067-27ed211e99f0 >> PCI [ahci] 00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller [AHCI mode] >> ├scsi 1:0:0:0 ATA SAMSUNG MZ7LH256 {S4VSNE0MA03154} >> │└sdb 238.47g [8:16] Partitioned (gpt) >> │ ├sdb1 260.00m [8:17] vfat 'SYSTEM' {A850-134B} >> │ ├sdb2 1.00g [8:18] xfs {2d8a56bf-f1e3-4f02-9ae7-3a20c987586d} >> │ └sdb3 237.22g [8:19] crypto_LUKS {8fb015aa-50d8-49b5-9001-964e3247fc87} >> │ └dm-0 237.21g [253:0] PV LVM2_member <237.21g used, 4.00m free {K082KU-HZAr-i6Np-9TwL-av7Z-Nytm-4I4jHe} >> │ └VG centos_tsp520c 237.21g 4.00m free {Y4mpA3-tMd8-L5Pg-xYQF-lcQY-7wgk-Ox2iSi} >> │ ├dm-3 179.52g [253:3] LV home xfs {1d7fabc3-c6f5-4e43-b609-ea86d33012c1} >> │ │└Mounted as /dev/mapper/centos_tsp520c-home @ /home >> │ ├dm-1 50.00g [253:1] LV root xfs {f4f1de82-b53d-4d6d-81f0-621103dddec5} >> │ │└Mounted as /dev/mapper/centos_tsp520c-root @ / >> │ └dm-2 7.69g [253:2] LV swap swap {7fbb4125-6394-4fe8-83a1-8ff0e079ae98} >> ├scsi 2:0:0:0 ATA SAMSUNG MZ7LH256 {S4VSNE0MA03145} >> │└sdc 238.47g [8:32] Partitioned (gpt) >> │ ├sdc1 260.00m [8:33] vfat 'SYSTEM' {A850-134B} >> │ │└Mounted as /dev/sdc1 @ /boot/efi >> │ ├sdc2 1.00g [8:34] xfs {2d8a56bf-f1e3-4f02-9ae7-3a20c987586d} >> │ │└Mounted as /dev/sdc2 @ /boot >> │ └sdc3 237.22g [8:35] crypto_LUKS {8fb015aa-50d8-49b5-9001-964e3247fc87} >> └scsi 7:0:0:0 ATA Samsung SSD 860 {S597NE0MA20991N} >> └sdd 1.82t [8:48] Partitioned (gpt) >> ├sdd1 1.82t [8:49] zfs_member 'zfspool' {3888980096123243448} >> └sdd9 8.00m [8:57] Empty/Unknown >> Other Block Devices >> └loop0 0.00k [7:0] Empty/Unknown >> >> Note that there are two other disks in the system which are not relevant (sda and sdd). The two identical SSDs, SAMSUNG MZ7LH256, are the ones that should be configured RAID-1 (sdb and sdc). >> >> Thank you. >> >> I see. I do recollect that at one time I had /dev/md127 and /dev/md128 show up in gparted. Could they have been created by the Intel fake RAID? If there are no signs of a remaining mdadm RAID installation and I have to install fresh, I do have a couple of questions. Naturally I need to make backups of the partitions before doing anything but: - Since the system seems to be booting from sdc1 and sdc2 while using sdb3 for the data partition, I would think that any restoration should be from backups of sdc1, sdc2 and sdb3, correct? - Is there anyway to do a dry-run of a fresh mdadm installation to see if it might install on the disks as currently partitioned and not disturb sdc1, sdc2 and sdb3? I do have this minimal partition of ca 4 MiB at the end of both disks which, if I understand correctly, might be used by a mdadm 0.90 scheme?
