HP Microserver Gen10, versus Raid1+ Ubuntu 16.04, install fail

Ubuntu Linux

Sziasztok,

Vettem egy gen 10 HP Microservert, és egy Ubuntu 16.04 LTS-t szerettem volna feltenni rá Raid1-el, és nem kis meglepetésemre nem sikerül.

Raid nélkül gond nélkül felmegy, azzal az istennek sem, mintha a Raid vezérlő és a linux nem lennének barátságban egymással.

Lehetséges hogy az egyik legnagyobb hardvergyártó szervernek szánt vasán nem támogatott az egyik legnépszerűbb linux distro szerver kiadása?!

Én csesznék el valamit, csinált esetleg valaki ilyet sikerrel?

Jeleztem a problémát a HP-nek és irtam az Ubuntu fórumra is.
Íme a HP-nak írt ticket szövege:

Case details
Operating system/version: Ubuntu 16.04.03 Lts
Product: HPE ProLiant MicroServer Gen10
Product vendor:
Problem description:
I was unable to install Ubuntu Lts 16.04.03 using two hdd in Raid1 with encrypted Lvm. The install process runs nice, seems everything ok, but the machine doesnt boot at all, the boot option doesnt show the disks or the raid array. The hardware itself seems to be ok, It works if I install the same linux distro to a single disk.
How can I use it the way I want?
Troubleshooting steps taken:
I tried it more than 10 times, with Efi, with legacy mode. I upgraded the firmware to ZA10A320 from ZA10A290 and tried it again with Efi and legacy. I tried with newer kernel using HWE mode, and I tried with Ubuntu 17.10 too without any result.
I saw that Gen8 Microserver had similar problems too, it needs a driver to build software Raid. What is the solution with gen10?

Eleddig csak egy félhivatalos levélben kaptam választ, íme:

"Kedves SzG!

Bár írtam egy hosszabbat - azt még nem véglegesítettem.

Viszont dióhéjban:
Ha jól látom, a gond az hogy az Ubuntu nem kezeli a beépített RAID vezérlőt (Marvel 88SE9230), nincs hozzá driver.
Én is kerestem Ubuntu (Debian) Marvel drivert - nem találtam.
Amúgy az Ubuntu támogatottságáról ezen a géptípuson sem találtam infót (valószínű, hogy épp a Marvell chip lehet az oka, más nem HW-okot látok hirtelen)
Szerintem, ezt így "ne erőltessük" (Ubuntu + Marvel)

Mit lehet tenni:
- más OS-t használni. Pl RHEL támogatott - ha az nem működik, na az már baj! Azt meg kell tudjuk oldani.
- más vezérlőt használni. Én ajánlani csak a hivatalos HPE-s opciót ajánlhatom
"HPE Smart Array E208i-p SR Gen10 Controller"
ami a termék QS-ében benne van
https://h20195.www2.hpe.com/v2/Getdocument.aspx?docname=a00008701enw
Ez egy SmartArray jellegű vezérlő - bár lehet hogy ehhez sem lesz Ubuntu driver!!!
- s ha nagyon ragaszkodnak az ubuntu-hoz, akkor valami olyan más (esetleg HP által NEM támogatott, DE működő!) kártyát kell választani, mely együtt tud működni az Ubuntu-val (lehet intelligens RAID, pl régebbi P410/P420 - de akár HBA jellegű is bármilyen gyártótól - ez "át fogja engedni" a diszkeket az OS felé, majd SW aid-ezni lehet)

Más lehetőséget nem látok.
Kérem fontolja meg a leírtakat."

Nem tudom eldönteni hogy ez a válasz mannyiben tekinthető supportnak...

Íme az Ubuntu fórumos leírás:
https://askubuntu.com/questions/990266/hp-microserver-gen10-marvel-chip…

Amire érdemi rakció nem jött.

A Raid1-et nem szívesen engedném el, és az Ubuntut sem szívesen. Otthoni irodai szerverről van szó, a szerver árával vetekedő Raid vezérlő nem reális alternatíva.

Ti hogy lépnétek tovább?

  • 4029 megtekintés

( klixnetwork | 2018. 01. 06., szo – 08:27 )

A szerverben van 0Ft-ért egy fake raid vezérlő, mint bármely sima alaplapon... azokra is általában rá van írva, hogy csak “vindóz” alatt megy :) ha kell a RAID és valós hw nem gagyi akkor venni kell bele vezérlőt. Szerintem P410 található már fillérekért.

napokban beszéltem HP supporttal erről. Állítólag már a Marvel chip támogatásával is lehet gond, ha nem supportált OS-t használsz.
Hálás lennék, ha ezt meg tudná valaki erősíteni v cáfolni. Azaz sima Debian8 v Debian9-el megy md-vel?

Annyit még mondtak, h állítólag olyan tükröt gyárt, hogy átteszed a lemezeket később egy SmartArray vezérlőre (gép upgrade) és simán felismeri.

ps: ha van támogatott OS (pl RH) akkor azzal fog menni. Egészen addig, amíg nem jön ki vmi új kernel (pl Spectre javítással) és ahhoz nem gyártják le a bináris driver-t (időben)...

ps: ha van támogatott OS (pl RH) akkor azzal fog menni. Egészen addig, amíg nem jön ki vmi új kernel (pl Spectre javítással) és ahhoz nem gyártják le a bináris driver-t (időben)...

hatalmas +1 :) Én is ezzel szívtam, hpvsa b120 -vel kapcsolatban nemrég.. :) Ráadásul ott (RH / centos) 7.3 -> 7.4 -es ugrás volt, ami elvileg "minor" azt mégse. pár hónap után lett is driver 7.4-hez a HPtól :)

De ezt a Marvel-es rettenetet én is elfelejteném (amúgy már a b120-at is..) egyszer hullik ketté, azt akkor lehet leskelődni hogy mi van.

( ncc1701 | 2018. 01. 06., szo – 11:11 )

Felesleges driver, abban tuti fake raid vezérlő van, annál pedig az mdadm fényévekkel jobb.

( joco01 v | 2018. 01. 06., szo – 11:23 )

Én nyers diszkeket használok zfs-sel, Debian alatt, csont nélkül megy. Én is hallottam róla, hogy szívás az a raid vezérlő.

( SzG | 2018. 01. 07., v – 14:48 )

Sziasztok,
Köszi a tippeket, véleményeket!
Erősen gondolkodtam rajta hogy a Zfs mirrornak ugorjak neki, olvasgattam manualt, látom hogy nem next-next enter, done, de talán én is meg tudok bírkózni vele.
Végül tettem még egy kísérletet, és a Hp oldaláról leszedett efi shellből futtatható Marvell config tool (https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_a2d926f8d9a…) segítségével (nem értem miért nem lehet a Biosból, vagy annak töltődése után elérhető menüből adminisztrálni a raid vezérlőt, spóroltak ezzel, vagy műszakilag van indok erre vajon?) sikerült létrehoznom a tömböt.

Elsőre az Ubuntu wizardjával tettem fel, de az ext4 helyett amúgy is btrfs-t szerettem volna, igy nekiláttam újra, és feltettem kézzel. Így hogy a vezérlő menüjében hoztam létre a tömböt, igy az Ubi egy SCSI eszközként látta a két lemezt, és tulajdonképpen gond nélkül csináltam benne encrypted lvm-et.

Nagy kérdés, hogy vajon merjem-e használni? :-)
Szerintetek merjem?
SzG

Szia,
A Raid vezérlő efi shellen keresztüli berhelése előtt az Ubuntu telepítővel próbáltam Raid1-et építeni, a csomagtelepítések alapján én abban a hitben voltam, hogy ekkor az mdadm segítségével hozza létre, nem így van? Simán lehet hogy tévedek, rutintalan vagyok a kérdésben.
SzG

Nagyon egyszerű, húzd ki az egyik diszket aztán nézd meg hogy még mindig bootol-e. Utána ugyanez online.
De én még mindig software raid irányába mennék, ha egy hw hiba után ki kell egy másik gépen olvasni az adataidat jobb esélyed lesz.
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Ööö én nem ezt mondtam? Azt írtam hogy hagyja a hardware kontrollert (még ha fake is), és legyen szoftveres a tükör.
Hogy aztán ez mdadm vagy ZFS vagy bármi más az mindenkinek szája íze (pénztárcája is mondjuk, lásd a ZFS nagyobb és ECC ram igényét).
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Nem ezt írtad. Swraid és ZFS között fényévnyi különbség van.

Tegyük fel, hogy van egy swraid tükröd, és rajta egy ext4. Tegyük fel, hogy a tükör egyik felén van egy bithiba/bad sector/bármi. Mi fog történni? Ha adatot érint a hiba, az ext4 észre se fogja venni, mert nem checksumozik. Random, hogy az adatod jó vagy rossz másolatát fogod beolvasni a tükörről. Ha valami fájlrendszer struktúrát érint, akkor a jó lemezről olvasva épp menni fog, rossz lemezről olvasva meg elhalálozik a fájlrendszer. Az ext4 nem tudja javítani, mert nem tudja megkérni az swraid-et, hogy mutassa meg az adat másik példányát. A raid se tudja magát javítani, mert nem tud róla, hogy milyen adat van fölötte. Azért nem tudják egymással megbeszélni a dolgot, mert külön rétegek. Tehát egy ilyen swraid adathiba ellen semmit nem véd, csak arra jó, ha az egyik diszk kiesik, még elfutkorászik, de utána simán lehet, hogy tükör újraépítésekor hibás adatot fog duplikálni a másik diszkre.

Mindez a ZFS-nél nem gond, mert a raid és fájlrendszer tudnak egymásról. A ZFS fájlrendszer bármilyen hiba érzékelése esetén megkéri a diszk rendszert, hogy adja oda az adat másik példányát, és kijavítja magát.

A BTRFS ugyanezt tudja elvileg, csak még nem tart ott (pl. a RAID5-öt nem ajánlják még élesre).

A ZFS elszaladgál egész kevés RAM-mal is (csak a dedupról kell lemondani, az eszik rengeteget).

A ZFS-hez nem muszáj ECC, csak ajánlott. Ha hibázik a RAM-od, az összes létező fájlrendszerrel tönkre fognak menni az adataid. Tehát igazából bármilyen workload mellett érdemes ECC-t használni. A ZFS nagyon ki van hegyezve az adatok védelmére, és ezért ők szólnak, hogy nem lesz 100%-os a rendszer ECC nélkül. (Sőt, talán van esély rá, hogy pont a ZFS önjavító képessége miatt több kárt szenvedsz, mint más fájlrendszerrel.) De ha hibázik a RAM, akkor már úgyis tök mindegy.

Én is gen10-en nyomom. Olvasgattam róla pár napig, ez tényleg kellett a megértéshez. De elsőre ment minden Debian alatt.

Azt gondolom, hogy kellően stabil. Sokan vannak még így. Mások meg félnek tőle. Tényleg nem a legjobb, hogy forrás formában a kerneltől elkülönülten kell terjeszteni. De az ext4 fejlesztői sem fognak neked garancialevelet adni :). Jó sok bejegyzés van a ZOL bugtrackerben, de a fejlesztők aktívan válaszolgatnak, és normál setup mellett kritikus adatvesztéssel járó hibát nem láttam.

4 éve is mondták már, hogy production ready. Ez 1 éves, elég rémes képet fest: https://bashelton.com/2017/02/my-journey-with-zfs-on-linux/ . Azóta viszont szerintem javultak ezek a dolgok. Volt már Debianon kernel upgrade-em, a ZFS túlélte (de azért izzadt a tenyerem, hiszen a root is ZFS-en volt, és a telepítő épp magát a ZFS modult fordította újra, ha ott valami becsúszik, akkor jön a recovery, de nem gáz, van ZFS snapshot a rootról is). Grub, initrd is megy rendesen (egy apró grub hiba van, de könnyű javítani). Ubuntuék alapból szállítják és támogatják. Hogy terhelés alatt összeesik-e, hát jó kérdés, nem látok a jövőbe, csak remélni tudom, hogy nem lesz ilyen :).