Zítra začne v Brně na FIT VUT třídenní open source komunitní konference DevConf.CZ 2024. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, Twitteru nebo Mastodonu.
Google Chrome 126 byl prohlášen za stabilní. Nejnovější stabilní verze 126.0.6478.55 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán Mozilla Firefox 127.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 127 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána (𝕏) nová verze 9.5 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Společnost Raspberry Pi dnes vstoupila na Londýnskou burzu jako Raspberry Pi Holdings plc (investor).
Do 17. června do 19:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | červen 2024 doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
Apple na své vývojářské konferenci WWDC24 (Worldwide Developers Conference, keynote) představil řadu novinek: svou umělou inteligenci pojmenovanou jednoduše Apple Intelligence, iOS 18, visionOS 2, macOS Sequoia, iPadOS 18, watchOS 11, …
Vyšla nová verze XMPP (Jabber) klienta Gajim, která přidává podporu reakcí pomocí emoji (XEP-0444: Message Reactions) a citace zpráv (XEP-0461: Message Replies). Přehled dalších vylepšení je k dispozici na oficiálních stránkách.
Po po téměř roce vývoje od vydání verze 5.38 byla vydána nová stabilní verze 5.40 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 75 vývojářů. Změněno bylo přibližně 160 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Mělo by stačit
DEVICES /dev/sd* ARRAY /dev/md0 uuid=...
kde místo tří teček doplníte UUID toho pole, zjištění např. pomocí 'mdadm --detail /dev/md0
'.
Není problém v tom, že se vám systém po startu nedetekuje disky pokaždé ve stejném pořadí? Pak byste měl dvě možnosti: za prvé se s tím smířit - mdadm
podle persistentních bloků správně pozná, která partition patří do kterého pole a jakou tam má funkci a to, že je jednou pole složeno z /dev/sdb1
a /dev/sdc1
a podruhé z /dev/sdb1
a /dev/sdd1
, vás trápit nemusí. Za druhé můžete persistentní pojmenování blokových zařízení zajistit nastavením pravidel pro udev.
Ja jen tvrdim, ze autoraid a prekompilovane jadro tim padem, mi dnes pripada lepsi. a ten problem by treba nemel/vyresil. Vy ne?
Ale ano. Jenže původně jste tvrdil něco trochu jiného než teď:
v pripade hellgasta by ale toto pomohlo
Netvrdil jsem, že to pomoci nemůže. Jen jsem se zeptal, proč tak kategoricky tvrdíte, že to pomůže, když není vůbec jasné, jaký má tazatel problém, a dokonce ani to, jestli už to právě takhle nemá.
mdadm
bez hrubého násilí sestaví pole z disků/oddílů, které do něj nepatří, zbývá mi jediný závěr: že celý problém (je-li to vůbec problém) není v tom, že by se pole nesestavilo, ale v tom, že přiřazení jednotlivých disků blokovým zařízením /dev/sd*
není persistentní. Proto jsem hned na začátku doporučil řešení pomocí udev rules a proto se vám celou dobu (zatím marně), snažím vysvětlit, že vaše přesvědčení, že nastavení id oddílů problém vyřeší, je neodůvodněné, tím spíš, že je dost dobře možné (a při použití automatických nástrojů dokonce pravděpodobné), že už to tak tazatel má.
/usr/share/doc/mdadm/README.upgrading-2.5.3.gz
.
Pokud je už raid rozbitý, zde je postup, jak ho spravit jen s pomocí ramdisku:
/dev
break=mount
echo
a přesměrování) jednoduchý /etc/mdadm/mdadm.conf
. V mém případě vypadal takto:
DEVICES=/dev/hd[ac][1235] ARRAY /dev/md0 devices=/dev/hda1,/dev/hdc1 # podobně pro zbytek polí
/usr/share/mdadm/mkconf
si vygeneruj nový popis RAIDových polí. Ten je založený na UUID, takže ho nerozhodí případné příští změny v pořadí disků a přitom zachová jména zařízení /dev/md*
podle toho, jak jsi je nastavil v ramdisku. Podle nich uprav svůj /etc/mdadm/mdadm.conf
. V mém případě vypadá nějak takto:
DEVICES partitions ARRAY /dev/md0 level=raid1 num-devices=2 UUID=ea27fba0:2b3e1587:8ee259d8:14122aa7 # zbytek konfigurace
/var/lib/mdadm/CONF-UNCHECKED
dpkg-reconfigure linux-image-2.6.18-4-486
(dosaď si název nainstalovaných balíčků s jádry)mdadm --stop /dev/md*V
/proc/mdstat ověř, že jsou všechna pole vypnutá
/dev/md*
zařízení odpovídaly tvé konfiguraci. Pokud je dané pole v pořádku, stačí něco na způsob:
mdadm --assemble /dev/md0 /dev/hda1 /dev/hdc1Pokud v pořádku není, je potřeba pole spustit postupně (samozřejmě jako první spustit partišnu se zdravými daty). V mém případě to vypadá takto:
mdadm --assemble /dev/md0 /dev/hda1 mdadm --add /dev/md0 /dev/hdc1Pole se automaticky začne synchronizovat. Pokud je potřeba synchronizovat i jiné pole, tak čeká, až se dokončí sync prvního. Postup lze sledovat v
/proc/mdstat
cd /mnt; mkdir md1 mount /dev/md1 md1 cd md1 for dir in dev proc sys; do mount /$dir $dir ;done chroot .
/dev/sda
(b, c, d) je pokaždé stejný fyzický disk? Není nakonec problém skutečně v tom, co jsem naznačoval hned v první odpovědi?
Zkusím to ještě jednou, zdá se, že mi pořád nerozumíte. Všechno, co jste zatím napsal, podle mne naznačuje, že problém není v tom, že by se vám po restartu pole sestavilo z jiných disků/oddílů, než z kterých jste ho původně vytvořil (opravdu nevěřím, že by mdadm
něco takového bez velké míry přemlouvání udělal), ale spíš na to, že se vám po restartu jinak přiřadila bloková zařízení /dev/sd?
jednotlivým fyzickým diskům. Zkuste např. porovnat výstup
scsi_id -g -s /block/sda scsi_id -g -s /block/sdb scsi_id -g -s /block/sdc scsi_id -g -s /block/sdd
při jednotlivých spuštěních systému.
V tom případě doporučuji podívat se na Writing udev rules. Nedávno jsem podobný problém řešil u jednoho zákazníka (tam šlo o jeden interní SCSI disk a externí pole s multipath přístupem) a řešením bylo právě nastavení udev rules tak, aby se fixovala jména speciálních souborů. Měli tam ale SLES, kde stačilo po změně udev rules přegenerovat initial ramdisk, aby to fungovalo i s kořenovým filesystémem, nevím, jestli to na Debianu půjde stejně snadno.
Pokud byste nenašel dostatečné rozlišovací prvky ve výstupu udevinfo
, zkuste tenhle článek, tam jen ukázka, jak se dá použít výstup scsi_id
(jen tam nerozlišují '==
' a '=
').
Tiskni Sdílej: