Fórumok
Sziasztok!
Mivel közeleg a hivatalos megjelenés, gondoltam kipróbálom egy virtuális játszótéren igy dist-upgrade előtt. A virtuális gépen
2 db 2 GB -os merevlemezt szerettem volna RAID1-be rakni. A telepités sikerese,stb jönnek a szokásos dolgok, azaz grub sda-ra sdb-re, initramfs-nek bootdegraded=true. Az elméleti hibát szimulálva, az sda kiszedve, sdb marad, gép indul, grub bejön, de a kernel után sajna nem megy tovább,initramfs sajnálkozás, hogy nemtudja visszaállitani az md arrayokat. Ugyanezen combó Debian 7 és Ubi 14.04 alatt természetesen tökéletesen működött. Valakinek esetleg ötlete?
Hozzászólások
Ugyanezt én is eljátszottam hétvégén.
A bootdegraded=true semmi hatását nem észleltem. Sem az initramfs paraméterként (/etc/initramfs.tools/conf.d/mdadm >> BOOT_DEGRADED=true),utána természetesen "update-initramfs -u", sem a grub menünél kernel paraméterként átadva.
A degraded eszközöket nem akarja mount-olni.
Most így indul:
Az initramfs promptnál:
<initramfs> mdadm --run /dev/md[012]
<initramfs>exit
Ezután a systemd megcsinálja a dolgait, megkapom a login promptot.
A "féllábú" raid minden eszköze rendben mountolódik a helyére.
Annak még nem olvastam utána, hogy ennek valami jól megfontolt elvi dolog az oka, vagy csak sima bug :)
Vagy rosszul paraméterezem az initrd-t ?
Lehet, hogy érdemes lenne kipróbálni systemd helyett sysvinit-el? Tényleg, hogy lehet legegyszerűbben sysvinit-re visszaállni?
szerk:
Közben találtam egy ilyet:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1302195
Úgy tudom (fixme), hogy nem lehet visszaváltani sysvinit-re a systemd-ről.
Ez a módszer működött még néhány hete.
Sajnos ahogy nézelődök ez inkább normális új funkció, azaz degraded módban rendszergazdai beavatkozás szükséges.
Másik gépen szintén systemd, előjött egy /dev/fd0 is, (véletlenül BIOS-ban meg volt adva egy 1.44-es floppy) ami irgalmatlanul lassú boot időt eredményezett, kernel után systemd mindig az fd0-t akarta piszkálni holott fstab-ban nincs is rá bejegyzés. Értem Én, hogy mozduljunk az enterprise vonal felé meg minden, de ezt egy kicsit erős húzásnak érzem, azaz a januári dist-upgrade kimarad, kitudja még milyen új feature-k vannak implementálva.
De amúgy nagyon korrekt és rendes, biztos véletlenül csinálja az admin az initramfs-ben a degraded paraméter megadását....
Rossz hozzáállás - ezzel a szolgáltatás folytonosságát csapja agyon,amire eddig jó volt az mdraid.
Egyetertek, itt nem a backup-funkcio hanem a rendelkezesre allas a fontosabb, ez pedig igy pont erre nem alkalmas - csak akkor az a kerdes hogy mire az?!
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Úgy látom, nem véletlenül nem boot-ol a féllábú soft RAID1. A végleges kiadásban is ez a koncepció.
Az initramfs nem lát md[x] eszközt, nincs miről filerendszert betölteni.
Kézi segítségre van szükség:
mdadm --run /dev/mdX.
Vagy valami elkerülte a figyelmem.....
Távolról egy reboot után izgulni kell? - vagy előre venni kell egy buszjegyet:)
subscribe :(
* Én egy indián vagyok. Minden indián hazudik.
Ha nem egyszerűen leveszem a hibásnak szimulált diszket, hanem hibásnak jelölöm meg - tehát az mdadm _tud_ róla, hogy rossz -, és utána rebootolok, akkor elindul féllábúan.
Tehát így működik a dolog:
mdadm /dev/md0 --fail /dev/sda1
mdadm /dev/md0 --remove /dev/sda1
ezután reboot, akkor elindul.
De mi van, ha kikapcsolákor még minden rendben, a következő bekapcsolásra meg pl beáll az egyik disk csapágya?
akkor szerintem foglalj jegyet a következő csillaghajóra, ha a szerver messze van...
Ha majd visszatértek a múlt évezredből, akkor majd lesz remote managment / ip console, no para :)
Nem az a probléma, hanem hogy a raid alapkoncepiója, hogy Redundant, tehát pl. RAID1-nél 1db diszkről be kéne bootolni. Nyilván az jó, hogy ha minnél erősebben jelzi, hogy cseréljdiszket/hibásdiszkvan, de bootoljon.
Életemben egyszer használtam biosban belőhető swraid-et, de addig amíg egy bootnál nem közölte, hogy Degraded!!! és hogy cannot boot. A slusszpoén pedig az volt, hogy a két diszk teljesen hibátlan volt, de én nyertem egy reinstallt.
"Remek".
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
subscribe
Múlt héten megnéztem a Linux Akadémia előadását egy Jessie szerver telepítésről, nem emlékszem, hogy szóba került volna ez a hiba...
Érdekel a téma.
Akkor beszéljünk róla? (sub)
Tegnap telepítettem (ügyfélnél) egy gépet.
Persze Jessie.
Így:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 58593279 58591232 28G fd Linux raid autodetect
/dev/sda2 58593280 60547071 1953792 954M 82 Linux swap / Solaris
/dev/sda3 60547072 1953523711 1892976640 902,7G fd Linux raid autodetect
/dev/sdb ugyan az mint sda.
Personalities : [raid1]
md1 : active raid1 sdb3[1] sda3[0]
946357248 blocks super 1.2 [2/2] [UU]
bitmap: 0/8 pages [0KB], 65536KB chunk
md0 : active raid1 sdb1[1] sda1[0]
29279232 blocks super 1.2 [2/2] [UU]
/dev/md0 on / type ext4
Az md1-et telepítéskor csak létrehoztam nem mountoltam sehová.
Mikor kész lett a telepítő az md0 már szinkronban volt, az md1 nem.
reboot után "grub rescue" fogadott :(
Emlékeztem erre a témára, hiszen fel is iratkoztam.
Telepítő cd vissza a gépbe, ott a rescue módot választottam és chroot-oltam a telepített rendszerbe.
Ott töröltem az md1-et, hiszen még nincs is rá szükség.
Reboot és minden működik.
Elkeserítő!! :(((
Állhatok neki virtuális gépben kitesztelni és megoldani, mert így a munkát sem tudjuk folytatni. Ha lesz eredmény megírom.
Tenyleg ekkora problema szukseg eseten az initramfs-rol kezzel inditani az md eszkozoket, majd egy CRTL+D, aminek hatasara folytatodik a boot? Plane, ha ott ulsz elotte?
es ha nem ulsz ott elotte akkor mekkora szivas? mondjuk egy aramszunet utan ujraindul mikozben megpusztult az egyik hdd? mindez az ejszaka kozepen?
neked tenyleg nem problema ez?
Nem. Ha fontos a gep, jon rola riasztas, belepek a konzoljara, es megreszelem, amit kell.
ertem.
gondolj bele ebbe: a szerver nem annyira fontos es egy telephelyen van, ami mondjuk 200km-re van toled es a gep egyben a router funkciokat is ellatja, azaz nincs console. akkor szepen utazhatsz le 200m-re minden mast felreteve/atutemezve. ahelyett, hogy felbutulva szolna, hogy itt van egy hibas hdd amit cserelni kellene. ezt szepen beutemezed es megoldod vagy mas mgeoldja.
szerinted nem ez lenne a kivanatos mukodes inkabb?
fontos gepnek van soros/ilo/ipmi konzolja, és normális hálózati eszköz adja a VPNt...
Attól függetlenül fos megoldás amit kitaláltak.
Az, hogy szétesett raid esetén nem indul el a gép, az pont a raid által adott plusz rendelkezésre állást gyakja pofán, de nagyon. Aki ezt kitalálta, annak a valós üzemeltetési tapasztalataival/gyakorlatával kapcsolatban jelentős kételyeim vannak.
+1
Kinek jutott eszébe, ez az oltári nagy hülyeség? Reméljük ezt gyorsan kijavítják, nem hiszem hogy ilyet direkt beletettek volna.
* Én egy indián vagyok. Minden indián hazudik.
+1
Ja amikor azt nehéz átverni , hogy miért olcsóbb egy extra 20 ezer HUF-os HDD, mint az esetleges 300 ezres data recovery. (bár annyiból igazuk van, hogy azzal a "megoldással" ez a scenario kivédhető)
A diszk ára és a data recovery ára hogy aránylik? Ami fontos, arról legyen mentés, mert tetszőleges diszk meghalhat vagy bármilyen okból korruptá válhat rajta az adat.
Igazad van, mentés volt (egyik saját winchesterem beáldoztam, miután a smartctld kellően meggyőző üzeneteket küldött, hogy nem lesz jó vége (ami igazából nem érdekelt senkit mert az email működött)), de a mentés nem fog visszamászni az Adatparkba, ha az egyetlen drive lehal.
Mindenesetre amikor a Lantronix Spider úgy fogadott a grub rescue-val (amihez egyébként hozzászokik az ember az ötödik után (majd ha meghal cseréljük (TM):()) és nem hajlandó listázni a partíció tartalmát, biza felér két SAM bácsival. )
Igazán viccess azután volt amikor le akarták foglalni az akkor már (élessé előlépett) helyi backup rendszert. Azt hiszem az első kérdés az volt, backup van? (azt nézitek :()
De azóta sikerült kiharcolnom egy Desktop I5-öst 16GB RAM-mal és 3x3TB HDD-vel ahonnan naponta mentve van minden, úgyhogy (no console edition :():
A tükör nem mentesít a mentés alól, csak ritkábban lehet csinálni.
Addig dolgozik a féllábú tükör. Itt azt is tudjuk, hogy nem lehetünk biztos mit is tartalmaz a tükör egészséges fele.
Persze, ha lefittyen az egyik diszk, akkor úgy is le kell "kerekezni" azt a 200km de az ügyfél addig is tud dolgozni. Persze, ha van a gépben egy negyedik (a harmadik a mentés) diszk akkor még lehet az a megoldás, de ehhez buherált keretek kellenek.
* Én egy indián vagyok. Minden indián hazudik.
2003-at írunk a cégnél van egy, 64kbit/sec-es bérelt vonalad (x gépre ahol x már akkor nagyobb mint 10). Összeírsz egy normális desktopot (nem szervert) az akkori főnököd kihúzza a második HDD-t a listáról, mert úgye költséghatékonyság. Hova mentesz? (értsd én boldogabb lettem volna ha a második HDD ott van :)). Egyébként 2013-ba halt meg ahhoz képest valjuk be jól bírta :).
(Azt hiszem Potato-val kezdte és nem érte meg a Wheezy-t :()
Total offtopic, de a swapot miert nem teszed raid1-be?
Az gondolom a swap-en nincs olyan adat, amit hosszú távon meg kéne őrizni.
No meg így helytakarékos. :)
Es ha meghal az egyik vinyod, akkor hiaba volt RAID, megis osszeomlik a rendszer :-)
Valóban, ha a swap tartalmaz érvényes adatokat és akkor romlik el
a merevlemez, akkor baj lehet.
Nekiálltam kvm-ben, virt-manager segítségével reprodukálni a hibát. A netinst iso-t most töltöttem le.
Pontosan azt csináltam mint m0csi, a hiba nem jelentkezik.
Nekem működik egy diszkkel is a boot. Néztem a szerver telepítésem, ahol jelentkezett a hiba és, a tesztkörnyezetben
ugyan azok a csomagverziók vannak.
m0csi!
Te milyen virtualizációval próbáltad?
Ha most frissíted a rendszert, a hiba még jelentkezik?
Bizonytalan vagyok ebben a kérdésben, de én azt tapasztaltam, hogy a telepítő verziója sem közömbös. Persze azt nem vizsgáltam, hogy a felkerülő csomagok verziójában mi a difi, de azt már tapasztaltam nem egyszer, hogy a frissített verzióval másként működik a rendszer ugyanazon a vason.
* Én egy indián vagyok. Minden indián hazudik.
Sziasztok!
A Jessie kiadása óta most kellett csak éles szervert telepítenem ezzel a disztróval, nem gondoltam hogy számomra ennyi negatív változás lesz benne.. Sajnos nagyon nem érzem üzembiztosnak ezt az új kiadást :(
A szerver már ugyan megy, de a raid1 tesztel virtuális gépben szenvedek már pár órája. Azon felül, hogy a fenti módszerrel be lehet rúgni a rendszert, próbált valaki már új vinyót is hozzáadni a tömbhöz? :) Új nekem még a systemd, lehet itt is kellene valamit piszkálni?
Tehát amit eddig csináltam:
-rendszer feltelepít
-grub-install /dev/sdb re is.
-vinyó kivesz
-initramfs mdadm --run /dev/md0
-beboot /poweroff
-új hdd berak
-indít
-partíciós táblát átmásolom sfdisk -d /dev/sda | sfdisk /dev/sdb
-telepítem grubot új vinyőre
-hozzáadom a tömbhöz, szinkronizál
Rebootnál viszont a systemd "A start job is running for dev-disk-by" üzenettel még matat.
Mit csinálok rosszul, mit kellene csinálni, esetleg valaki tudna egy normális velős systemd doksit linkelni?
Miért nem a telepítővel teszed rögtön raid1-re a bootot? A systemd leszedhető, legalábbis nagyrészt: apt-get install sysvinit-core
Ha a systemd a jövő, sajnos azzal kell dolgozni :( Lecserélése pedig lehet beláthatatlan következményeket okoz egy esetleges frissítésnél.
Én maradok systemd mentes amíg lehet.
Megvan a hiba..
fstab-ban még a régi vinyó uuid-je (másik imádnivaló feature :) ) IS meg volt adva swap-re, ezért volt a megakadás...
fstab-ban nem az mdX tomb uuid-je kellene, hogy legyen? (nálam a swap is raid-ben van)
Mint korábban írtam, ha nem csak egyszerűen lehúzom a hibás(-nak mondott) diszket, hanem előtte megmondom az mdadm-nak is hogy ez a rossz, el fogom távolítani, akkor a reboot rendben elindul féllábúan:
http://hup.hu/node/137700#comment-1863319
Én a swap-ot nem szoktam raidbe rakni, hanem fstab-ban kiegészítem a pri= opcióval. Évekkel ezelőtt jártam körül ezt a dolgot, akkor egy picivel több érv szólt a nem raidolt swap mellett.
Mégjobb talán, ha fájlrendszerre rakod, így ha kisebb-nagyobb kell, csak törlöd, újra létrehozod a fájlt, mkswap, swapon -a és kész.
Ha titkosítod a fájlrendszert, raidet használsz, egyfüsttel a swapra is megoldva.
Már nem tudom mióta dúl az uuid "őrület", de én az fstab -ban LABEL -t használok. Persze itt-ott belefutottam hogy uuid -t akar rám erőszakolni egy-egy telepítő script, de összességében jól, megbízhatóan működik így.
(Azért nem kedvelem az uuid -s megoldást, mert egy bizonyos diszkhez ragaszkodik. Folyton meglepetéseket okoz ha valamiért cserélnem kell.)
* Én egy indián vagyok. Minden indián hazudik.
Marpedig ahol egyedi azonosito kell, ott sokkal jobb az uuid. Semmi sem garantalja, hogy ugyanaz a (manualisan beallitott) LABEL ne legyen tobb fs-nel hasznalatban, es nem is minden fs tamogat LABEL-t.
Így igaz!
Én arról beszélek, ahol lehet - pl. RAID1 nem használok uuid -t pont a hiba és csere miatt.
* Én egy indián vagyok. Minden indián hazudik.
Én sehol se használnék ha lehetne, általában tényleg csak a gondot okozza..
-semmitmondó
-hosszú
-nehezen kezelhető
Ráadásul nem csak az fstab-ba, de pl akár a grub-ba is okozhat ez gondokat, ha az ember nem figyel.
Arra, hogy mik az előnyei a mindennapokban, még nem jöttem rá :)
Az a baj, hogy addig fejlesztik a dolgokat, hogy már mindenre jó lesz minden, csak arra nem amire kitalálták.
Berakod egy tetszőleges gépbe, és van egy biztos adat, ami alapján hivatkozhatsz rá. Tök mindegy, hogy melyik vezérlő, melyik portjára, natívan sata-ra vagy épp usb-n esetleg firewire csatolós dobozban van a diszk.
Nekem még egyszer se fordult meg a fejemben, hogy usb-ről bootljam be a régi rendszert. Ha meg sata0-n volt, úgyis sata0-ra fogom kötni, egy csavarhúzó mindig van nálam :) Ráadásul adatmentést meg úgyse saját magáról bootolva csinál az ember.
Viszont általánosabb az a probléma, hogy migrálod a rendszert egy másik hdd-re. Na ott aztán a semmiből szerkesztheted az ide-oda bejegyzet UUID-eket grub-tól fstab-ig hogy elinduljon.
Igen, én is kombinálom az lshw-val kilistázott egyedi azonosítók végével, és akkor inkább ZFS, pl. így:
NAME STATE READ WRITE CKSUM
zfs-1 ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
sdb-zfs-1_S13PJ1CQC00013 ONLINE 0 0 0
sdc-zfs-1_S13PJDWQ614976 ONLINE 0 0 0
sdd-zfs-1_S13PJ1CQ722258 ONLINE 0 0 0
sde-zfs-1_S13PJ1CQ722246 ONLINE 0 0 0
+1