raid1 összeomlás - ilyet még nem láttam

Debian GNU/Linux

Adva van két 1T SATA2 HDD, ami régóta fekszik de még sosem volt használatban.
# sfdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EZRX-00A
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: dos
Disk identifier: 0x1d22a38e

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 16001023 15998976 7.6G fd Linux raid autodetect
/dev/sda2 16001024 32002047 16001024 7.6G fd Linux raid autodetect
/dev/sda3 32002048 48003071 16001024 7.6G fd Linux raid autodetect
/dev/sda4 48003072 1953523711 1905520640 908.6G fd Linux raid autodetect

Ugyanaz a típus és partíciók a /dev/sdb
Ezekből készült négy raid1 sw tömb
md1 sda1+sdb1, md2 sda2+sdb2, md3 sda3+sdb3 és md4 sda4+sdb4

Az első szimptóma az volt, hogy valamiért tunya lett a login.
Aztán ránéztem a tömbökre - cat /proc/mdstat és azt láttam, hogy resyncing meg (PENDING).
Az md2 és az md4 még formázva sem volt, az md3 pedig a swap. Miért kell re-szinkronizálni?
Az md4 -et leformáztam, így szépen leszinkronozta a semmit.
Az md3 (swap) végül így indítottam be # mdadm --readwrite /dev/mdX
Leszinkronozott, reboot.
Elkezdett mindenféle hibaüzeneteket küldözgetni a sata alrendszerről.
De bebootolt, viszont az eredmény teljesen érthetetlen a számomra:
md1 sda2+ removed
md2 sda1+sdb1
md3 sda3+sdb3
md4 sda4+sdb4

# mount
/dev/md1 on / type ext4 (rw,relatime,errors=remount-ro)

Hogy tud mountolni és bootolni egy üres (épp csak felformázott) tömb egyik lemezére?

Olyat már láttam és kezeltem ha a tömb egyik lemeze kiesik, de hogy helyet cserél ez nekem teljesen új.
Mit csinálhatok ezzel?
Kezdjem újra az egészet?

( uid_395 v | 2019. 10. 24., cs – 20:51 )

/off

Kövezzetek meg... de miért kell a teljes rendszert MD* sw raidre rakni ? ..

Kövezzetek meg, Pendriveról / HDDről / Egyébről fut az OS, + utána mellete fut az MD kötet...

btw ezt a sok md2-3-4-5-6ot sem igazán értem .. hogy ha már md mi a f.szért kell így szétszedni.. vannak erre elegánsabb megoldások.

UUID körül keresgélj.

off/

(tudom ZFS, meg minden egyéb...)

Az eddigi rendszerem (sok évig jól működött) md1 - rendszer, md2 -swap, md3 - /home
Most úgy gondoltam, ha legközelebb distrót kell váltanom ott egy negyedik partíción simán kipróbálhatom (és ha valami balul üt ki akkro visszaálhatok a régire).
Elvileg, egy diszket 4 elsődleges partícióra lehet felosztani. A rendszer teljesen jól működött, míg megjelent ez a resync üzenet. Akkor a teljesen tartaléknak szánt md2 -t felformáztam, utána "szabadult el a pokol".
UUID - nem módosítottam semmit, hozzá sem nyúltam ezekhez (gondolom grub, mdadm és fstab).
Mi lenne az elegáns megoldás?

* Én egy indián vagyok. Minden indián hazudik.

Sajnos az USB kiesik - USB 2.0 k'va lassú.
A HDD az jó ötlet, régen (az ezeket a rendszereket megelőző időben) volt ilyenem. De egy gui nélküli szerveren egy rendszer partíciónak a 8G elég, milyen diszket tennél oda ami nem lenne pazarlás?
Megpróbálkoztam olyannal, hogy betenni egy SSD -t de az SATA3 lehet az előző rendszeremben is ez vágta haza a SATA2 alrendszert.

* Én egy indián vagyok. Minden indián hazudik.

( uid_20269 | 2019. 10. 24., cs – 21:12 )

Nekem a RAID1 swap-ra gúvadt kissé a szemem..
Hogy néz ki a raid.conf-od jelenleg.?
--
God bless you, Captain Hindsight..

Hosszú, de az előző, még ép verzióban, ami nincs kimaszkolva:
# The designation "partitions" will scan all partitions found in
# /proc/partitions
DEVICE partitions
Vagyis szedd össze.

Valószínűleg próbálkoztam egy olyat, ami miatt tuti újra kell kezdeni - még talán van egy mentésem de hogy sikerül e felrakni nem tudom.
Bebootoltam egy rescueCD -ről, és az md2 -nek megfelelő tömböt lenyomtam:
# mdadm --stop /dev/md12X
majd
# dd if=/dev/zero of=/dev/sda2 bs=512 count=1000
# dd if=/dev/zero of=/dev/sdb2 bs=512 count=1000

Újra próbáltam bootolni, de most már csak az initrd promptot kaptam meg :(
Újra rescueCD bemountoltam az (állítólag) sda1+sdb1 tömböt és üres, csak a lost+found.
Olyan mintha a diszk partíciók borultak volna fel.
Ez egyre rosszabb.
Nem értem :(

* Én egy indián vagyok. Minden indián hazudik.

( uid_6201 v | 2019. 10. 24., cs – 21:22 )

cat /etc/mdadm/...conf
mdadm --detail --scan

Ezek mit írnak az UUID-s résznél?

Most épp így néz ki:
ARRAY /dev/md/nusi:3 metadata=1.2 name=nusi:3 UUID=7439f965:3dcfa9cb:8764bac1:edaa414a
ARRAY /dev/md/nusi:4 metadata=1.2 name=nusi:4 UUID=f77b924c:e554f67c:191c3b26:953a46dd
ARRAY /dev/md/nusi:2 metadata=1.2 name=nusi:2 UUID=460e9034:502080d7:46daa627:4be5e07a

De ez már az az állapot, amikor kitöröltem(?) a boot md1 -et

* Én egy indián vagyok. Minden indián hazudik.

Igen, eselyes... A klasszikus eredeti raid1 (amit most -e 0-nak vagy 0.90-nek hivnak) meg az ujabb 1.0-s raid1 olyan hogy a raid-superblock a particio legvegen van. Ez azt jelenti hogyha a raid1 alatt levo particiora "csak ugy" ranezel, akkor mindenfele extra nelkul fel tudod mountolni readonly uzemmodban, anelkul hogy tudnad hogy az valojaban egy raid1 resze. Ez jelentosen megkonnyiti a bootloader-ek dolgat, es abban az idoben amikor megezek a "bios boot" meg "efi" particiok nem voltak elterjedtek, lenyegeben csak igy lehetett raid1-rol bootolni. Es igazabol most is, ezekkel is szerintem az "erosen ajanlott" kategoriaba tartozik... Lasd meg: https://raid.wiki.kernel.org/index.php/RAID_setup (Ctrl+F: boot).

https://raid.wiki.kernel.org/index.php/RAID_setup#Create_RAID_device

If you want to access all the latest and upcoming features such as fully named RAID arrays so you no longer have to memorize which partition goes where, you'll want to make sure to use persistent metadata in the version 1.0 or higher format, as there is no way (currently or planned) to convert an array to a different metadata version. Current recommendations are to use metadata version 1.2 except when creating a boot partition, in which case use version 1.0 metadata and RAID-1.

Booting from a 1.2 raid is only supported when booting with an initramfs, as the kernel can no longer assemble or recognise an array - it relies on userspace tools. Booting directly from 1.0 is supported because the metadata is at the end of the array, and the start of a mirrored 1.0 array just looks like a normal partition to the kernel.

( tovis v | 2019. 10. 24., cs – 21:52 )

Van egy tegnapi rendszer mentésem, sima tar.gz
Viszont, mivel úgy tűnik, mintha felcserélődtek volna a partíciók (sda1-sda2, sdb1-sdb2) nem tudom, hogy tudom használni.
Talán, leállítom a mostani sd1+sdb1 tömböt, majd újra create md2 és végül md1?
Hogy tudnám rábírni ezt az el'aszott felosztást felejtse el és építse újra?

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2019. 10. 24., cs – 22:04 )

Feladom.
Végül is csak 4-5 óra meló van még benne.
Valaki említett elegánsabb megoldást, mi lenne az?
Valaki az mdadm.conf -ot akarta látni, érdemes itt valami komolyabbat beépíteni, mint a "szedd össze magad"?

* Én egy indián vagyok. Minden indián hazudik.

( SySERR | 2019. 10. 24., cs – 22:10 )

Ez nagyon erősen RAM hiba gyanús!
Hibás RAM miatt láttam már RAID6-ot is széthullani.
-------------------
https://onlinestream.live/ - A legtöbb magyar rádió és TV egy helyen!

Megtesztelem.
Újra próbálkoztam a telepítéssel, leállítottam az összes tömböt és fejbe vágtam az alját a diszknek, de a telepítő nem hagyja teljesen újra építeni a tömböket (sda3+sdb3 és sda4+sdb4).
A telepítő az sdb diszkre panaszkodik, hibákat dobál!

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2019. 10. 24., cs – 22:49 )

Amíg megy a RAM teszt ...
Mit tudtok, az mdadm jól működik az extended partíciókon?
(Lehet azért ilyen nyűgös a rendszer mert pont határ a 4 elsődleges partíció amit használok)

* Én egy indián vagyok. Minden indián hazudik.

( wladek1 | 2019. 10. 24., cs – 23:08 )

smartctl -A /dev/sdb kimenete? Fura, hogy eddig meg senki nem kerdezte...

Nem az első eseményem, mindent rendben talál - nem csináltam short és long tesztet. Most egyelőre csere.

OFF: Van olyan tapasztalatom, hogy az a disk ami raid1 -ben hibázik, tök jól el van szingliben. Jó lenne az ilyen diszkeket tesztelve formázni, de ez annyi idő lenne amim nincs.

* Én egy indián vagyok. Minden indián hazudik.

Nagyon valószínű, hogy mivel itt bukott el az egyik diszk a raid -ből (amíg nem formáztam fel ezeket a területeket, nem volt disk hiba naplózva, utána meg a tömb is fejre állt)
Most minden tömböt leformáztattam a telepítővel. Van egy "hiba" jelzésem ami a diszk energia felhasználására vonatkozik, de ez minden amit a # grep fail /var/log/syslog parancsra kapok.
(# grep err /var/log/syslog parancsra csak az interrupt és override találatokat kapok)

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2019. 10. 25., p – 01:20 )

Érdekes.
Kicseréltem a hibázgató diszket (régi használt de egy hete még kifogástalanul működött).
Megnöveltem a "kis" 8G partíciókat 10G -re, így már nem akarja megtalálni a régi rontottakat.
Az előző telepítésnél (nem tudom miért) de az tömbök nem nullától, hanem egytől számozódtak, most 0 -tól.
Nem tudom jelent e ez bármit.
(Azért szeretem ha a szoftverek kétszer egymás után azonosan működnek).

* Én egy indián vagyok. Minden indián hazudik.

( vl v | 2019. 10. 25., p – 10:00 )

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 616447 614400 300M fd Linux raid autodetect
/dev/sda2 616448 976773167 976156720 465.5G 8e Linux LVM

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 616447 614400 300M fd Linux raid autodetect
/dev/sdb2 616448 976773167 976156720 465.5G 8e Linux LVM

Personalities : [linear] [raid0] [raid1] [raid6] [raid5] [raid4]
md127 : active raid1 sdb1[1] sda1[0]
307136 blocks super 1.0 [2/2] [UU]

# vgs
VG #PV #LV #SN Attr VSize VFree
vg 2 7 0 wz--n- <930.93g <10.88g
# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 vg lvm2 a-- 465.46g <5.44g
/dev/sdb2 vg lvm2 a-- 465.46g <5.44g
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home vg rwi-aor--- 430.00g 100.00
log vg rwi-aor--- 3.00g 100.00
portage vg rwi-aor--- 6.00g 100.00
root vg rwi-aor--- 10.00g 100.00
src vg rwi-aor--- 6.00g 100.00
swap vg rwi-aor--- 2.00g 100.00
var vg rwi-aor--- 3.00g 100.00

És akkor nem kell küzdeni ezekkel az MD device-okkal...

Próbálom értelmezni.
Van 2db 500G HDD. Rajtuk:
Van egy 300M bájtos raid1 tömb - minek, mire elég 300M?
A fennmaradó 465,5G összerakod egy logikai tömbbe, így a rendszer szempontjából ck. 1T kapsz. De hogy lesz ettől biztonságosabb a tárolás? (Nekem azért kell a raid1, hogy hiba esetén tudjam menteni az utolsó állapotot)

* Én egy indián vagyok. Minden indián hazudik.

Akkor ha ez egy mirror, hogy lesz ebből 1T?

Van két 500GB-s diszk, az bruttó 1TB terület. A vg ennyit tud. Az per lv dől el, hogy lesz-e tükrözés, vagy sem.

Azt honnan lehet látni, hogy az lv -k mirror -ban vannak?

A betűhalmazból (Attrs) az első karakter mondja meg, hogy milyen típusú lv az ott. Az m/M a legacy mirror lv device, az r/R meg a raid1 lv device.

The lv_attr bits are:

1 Volume type: (C)ache, (m)irrored, (M)irrored without initial sync,
(o)rigin, (O)rigin with merging snapshot, (r)aid, (R)aid without
initial sync, (s)napshot, merging (S)napshot, (p)vmove, (v)irtual,
mirror or raid (i)mage, mirror or raid (I)mage out-of-sync, mirror
(l)og device, under (c)onversion, thin (V)olume, (t)hin pool, (T)hin
pool data, raid or pool m(e)tadata or pool metadata spare.

Szerintem csináltam ilyet valamelyik disztribúció gyári telepítőjével is (ez Gentoo, itt ez a fogalom nem ismert), meg persze bármelyik disztribúciónál működik az, hogy egy shellben megcsinálod a diszkfelosztást/fájlrendszereket, aztán ellövöd az installert, hogy már kész a diszk, csak használja azt.
 

( tovis v | 2019. 10. 25., p – 13:50 )

Valahogy nem gömbölyű ez dolog.
Bootoltam egyet:
# grep fail /var/log/syslog
Oct 25 13:31:41 nusi systemd-udevd[331]: Process '/usr/sbin/alsactl -E HOME=/run/alsa restore 0' failed with exit code 99.
Oct 25 13:31:41 nusi systemd-udevd[326]: Process '/lib/udev/hdparm' failed with exit code 1.
Oct 25 13:31:41 nusi systemd-udevd[344]: Process '/lib/udev/hdparm' failed with exit code 1.
Oct 25 13:31:41 nusi kernel: [ 0.367515] acpi PNP0A08:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
Oct 25 13:31:43 nusi ntpd[474]: bind(24) AF_INET6 fe80::4261:86ff:fe0e:5417%2#123 flags 0x11 failed: Cannot assign requested address
Oct 25 13:31:43 nusi ntpd[474]: failed to init interface for address fe80::4261:86ff:fe0e:5417%2

Visszatöröltem a logot, bootoltam kettőt:
Oct 25 13:33:45 nusi systemd-udevd[303]: Process '/lib/udev/hdparm' failed with exit code 1.
Oct 25 13:33:45 nusi systemd-udevd[320]: Process '/lib/udev/hdparm' failed with exit code 1.
Oct 25 13:33:45 nusi kernel: [ 0.368315] acpi PNP0A08:00: _OSC failed (AE_NOT_FOUND); disabling ASPM

A processz /lib/udev/hdparm akkor ilyen jelzést ha a /proc/mdstat -ban ilyenek jelennek meg "resync|repair|recover|check"

cat /proc/mdstat

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active (auto-read-only) raid1 sdb3[1] sda3[0]
9991168 blocks super 1.2 [2/2] [UU]
resync=PENDING

md3 : active (auto-read-only) raid1 sdb4[1] sda4[0]
946628608 blocks super 1.2 [2/2] [UU]
resync=PENDING
bitmap: 8/8 pages [32KB], 65536KB chunk

md0 : active raid1 sdb1[1] sda1[0]
9990144 blocks super 1.2 [2/2] [UU]

md1 : active (auto-read-only) raid1 sdb2[1] sda2[0]
9991168 blocks super 1.2 [2/2] [UU]
resync=PENDING

unused devices:

Ugyanakkor, a rendszer tömb:
# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Fri Oct 25 00:16:38 2019
Raid Level : raid1
Array Size : 9990144 (9.53 GiB 10.23 GB)
Used Dev Size : 9990144 (9.53 GiB 10.23 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Fri Oct 25 13:42:22 2019
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : resync

Name : nusi:0 (local to host nusi)
UUID : f8869ca8:8a01ac22:045b9886:f0fcbeb4
Events : 465

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1

Vagyis "clean"

Az md1 - ami épp csak etxt4 -re formázta, nincs felcsatolva:
State : clean, resyncing (PENDING)

Az md2 ami a swap szintén zenész:
State : clean, resyncing (PENDING)

Végül a jövendő /home - fromázva nem felcsatolva:
State : clean, resyncing (PENDING)

Miért kell ezeket a tömböket "resyncing"?
Kezdjek aggódni?
Mi baja lehet az alsa -val?

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2019. 10. 25., p – 13:56 )

Még valami.
Az összeomlott verzióban, még láttam hogy van /etc/mdadm/mdadm.conf - viszont néhány lépéssel az összeomlás előtti mentésben nem találtam ilyet!?
Most ismét van, és ez van benne:
# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=f8869ca8:8a01ac22:045b9886:f0fcbeb4 name=nusi:0
ARRAY /dev/md/1 metadata=1.2 UUID=c9f6d652:7d3a8c07:1287bffd:9124e98f name=nusi:1
ARRAY /dev/md/2 metadata=1.2 UUID=690b0c24:0482f067:3432040c:f3366a31 name=nusi:2
ARRAY /dev/md/3 metadata=1.2 UUID=e0590093:186aa7c2:7746aeaa:25375ad9 name=nusi:3

* Én egy indián vagyok. Minden indián hazudik.