Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Intel vydal 41 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20240514 mikrokódů pro své procesory řešící INTEL-SA-01051, INTEL-SA-01052 a INTEL-SA-01036.
Společnost Raspberry Pi patřící nadaci Raspberry Pi chystá IPO a vstup na Londýnskou burzu.
Google na své vývojářské konferenci Google I/O 2024 představil řadu novinek. Keynote byl věnován umělé inteligenci (DeepMind, Gemini, Responsible AI).
V Gitu bylo nalezeno 5 zranitelností. Opraveny jsou ve verzích 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 a 2.39.4. Útočník může připravit repozitář tak, že při jeho klonování (git clone) může dojít ke spuštění libovolného kódu.
Virtualizační softwary VMware Workstation Pro a VMware Fusion Pro jsou nově pro osobní použití zdarma. Softwary VMware Workstation Player a VMware Fusion Player končí.
Linuxová distribuce Endless OS (Wikipedie) byla vydána ve verzi 6.0.0. Přehled novinek i s náhledy v příspěvku na blogu, poznámkách k vydání a také na YouTube.
Dobry den,
prosim zkusenejsi o pomoc s DRBD. Doted jsem ho znal jen z doslechu. Snazim se v rychlosti neco nacist, ale zatim je to malo.
Pokousim se vydolovat data z noveho QNAPu, kteremu po par mesicich odesla zakladni deska. Podle recenzi na internetu to potkalo hodne lidi. Servis v NL nestiha a po nejake dobe vraci penize.
Oba disky jsou vporadku. MD raidy se sestavi a na oddilech, kde je rovnou EXT4 pro system, jsou videt data - konfiguracni soubory, logy, atd. Horsi je to s oddilem pro uzivatelova data. Ta jsou na think provisioned LVM, pod kterym bezi DRDB.
Pokus nahodit DRDB dopadne takto:
# drbdadm up r1 strange bm_offset -2112 (expected: -1928) No valid meta data found
A ted se ptam:
- Muzu prikazem "drbdadm create-md r1" vytvorit znovu metadata, aniz bych poskodil data na disku?
- Da se pomoci nejakeho offsetu dumpnout disk, abych z DRDB oddilu dostal Physical Extends pro PV?
Nerad bych to resil stylem pokus/omyl, protoze vytvorit pracovni kopii disku trva DDckem 10 hodin.
Dekuji
dl
.
----------
Puvodni originalni konfiguraky a info ze stroje, kde to zkousim:
# lsmod | grep drb
drbd 425984 0
lru_cache 16384 1 drbd
libcrc32c 16384 2 btrfs,drbd
# rpm -qa | grep drb drbd-utils-9.13.0-lp152.2.3.1.x86_64 drbd-9.0.22~1+git.fe2b5983-lp152.2.2.1.x86_64
# blkid -c /dev/null /dev/md126 /dev/md126: UUID="43c1a77e5b530960" TYPE="drbd"
# cat /etc/drbd.d/global_common.conf
global {
usage-count no;
}
common {
handlers {
}
startup {
}
options {
}
disk {
}
net {
}
}
# cat /etc/drbd.d/r1.res resource r1 { syncer { rate 4G; } on HomeHost { device /dev/drbd1; disk /dev/md126; meta-disk internal; address 127.0.0.1:7789; } on FakeHost { device /dev/drbd1; disk /dev/md126; meta-disk internal; address 1.0.0.1:7789; } }
# drbdadm up r1 strange bm_offset -2112 (expected: -1928) No valid meta data found
# cat /proc/drbd version: 8.4.11 (api:1/proto:86-101) srcversion: B5223DD0E70DC76DE10377F 1: cs:Unconfigured
LOG z puvodniho NASu:
# grep drb pstore_2_201907101733.log
[ 14.619019] drbd: initialized. Version: 8.4.5 (api:1/proto:86-101)
[ 14.625194] drbd: GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by @U16BuildServer40, 2019-06-20 06:15:46
[ 14.635647] drbd: registered as block device major 147
[ 39.414676] drbd r1: Starting worker thread (from drbdsetup-84 [2460])
[ 39.421491] block drbd1: disk( Diskless -> Attaching )
[ 39.426832] drbd r1: Method to ensure write ordering: flush
[ 39.432392] block drbd1: Adjusting my ra_pages to backing device's (32 -> 1024)
[ 39.439668] block drbd1: drbd_bm_resize called with capacity == 7794125112
[ 39.446521] drbd_realloc_pages use the Default memory
[ 39.451747] block drbd1: resync bitmap: bits=7611451 words=118929 pages=233
[ 39.458682] block drbd1: size = 3717 GB (3897062556 KB)
[ 39.483867] block drbd1: recounting of set bits took additional 0 jiffies
[ 39.490650] block drbd1: 3717 GB (7611451 bits) marked out-of-sync by on disk bit-map.
[ 39.498546] block drbd1: Suspended AL updates
[ 39.502897] block drbd1: disk( Attaching -> UpToDate )
[ 39.508111] block drbd1: attached to UUIDs 9EBFAD153C603FE5:0000000000000004:0000000000000000:0000000000000000
[ 39.556553] drbd r1: conn( StandAlone -> Unconnected )
[ 39.561792] drbd r1: Starting receiver thread (from drbd_w_r1 [2461])
[ 39.568374] drbd r1: receiver (re)started
[ 39.572393] drbd r1: conn( Unconnected -> WFConnection )
[ 40.603095] drbd r1: conn( WFConnection -> Disconnecting )
[ 40.603103] drbd r1: Discarding network configuration.
[ 40.613849] drbd r1: Connection closed
[ 40.617616] drbd r1: conn( Disconnecting -> StandAlone )
[ 40.622996] drbd r1: receiver terminated
[ 40.626915] drbd r1: Terminating drbd_r_r1
[ 40.634108] block drbd1: role( Secondary -> Primary )
[851456.448823] block drbd1: role( Primary -> Secondary )
[851456.454085] block drbd1: bitmap WRITE of 0 pages took 0 jiffies
[851456.460100] block drbd1: 3717 GB (7611451 bits) marked out-of-sync by on disk bit-map.
[851456.501104] block drbd1: disk( UpToDate -> Failed )
[851456.506178] block drbd1: bitmap WRITE of 0 pages took 0 jiffies
[851456.512172] block drbd1: 3717 GB (7611451 bits) marked out-of-sync by on disk bit-map.
[851456.520147] block drbd1: disk( Failed -> Diskless )
[851456.525389] block drbd1: drbd_bm_resize called with capacity == 0
[851456.531594] drbd r1: Terminating drbd_w_r1
Ta jsou na think provisioned LVM, pod kterym bezi DRDB.Co to je za zběsilost? A v rámci jednoho fyzického stroje? To jako to drbd běželo přes localhost? Tedy…
MD RAID → LVM → DRBD → BtrfsA s čím se to jako synchronizovalo? A proč je to blokové zařízení rovnou nad MD raidem a ne nad LV oddílem?
strange bm_offset -2112 (expected: -1928) No valid meta data found
Dekuji vsem za ochotu. Jeste doplnim:
Proc je to tak blbe udelane? - Nevim. Je to nesmyslne, souhlasim. Udelalo se to samo behem instalace. Asi pokrok. Do ted nebyl problem disky z Qnapu precist v linuxu. S tim je ted konec. Pujcil jsem si od znamych 2 ruzne starsi modely, ale ani jeden neobsahuje drbd. Nova doba, nove modely, nova funkcionalita, nove problemy...
Pripojil jsem disk v Centosu 7.1 ale dopadlo to stejne. Zkusim jeste Centos 6, snad tam bude drbd verze 8.
Zkusim nekde pujcit identicky model QNAPu a pripojit to v nem.
Diky moc
Zjistil jsem, ze DRBD uklada metadata na konec diskoveho oddilu. Minimalni velikost metadat je 128 MB (pro disky < 8 TB). Ve verzich si myslim problem nebude, jak Centos 7.1 tak onen QNAP bezi na verzi DRBD8.
QNAP # cat /proc/drbd version: 8.4.5 (api:1/proto:86-101) GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by @UBuildServer40, 2019-03-28 06:16:13, HA:disabled
CentOS71# cat /proc/drbd version: 8.4.11 (api:1/proto:86-101) srcversion: B5223DD0E70DC76DE10377F
Dalsi problem bude v LVM, jsou tam nejake nezname atributy. Asi vlastni rozsireni LVM. Nejde aktivovat na openSUSE Tumbleweed ani na CentOSu 8.2, ktere by podporu THIN LVM2 meli umet.
# pvscan WARNING: Unrecognised segment type tier-thin-pool WARNING: Unrecognised segment type thick WARNING: Unrecognised segment type flashcache WARNING: PV /dev/md126 in VG vg1 is using an old PV header, modify the VG to update. LV tp1, segment 1 invalid: does not support flag ERROR_WHEN_FULL. for tier-thin-pool segment. Internal error: LV segments corrupted in tp1. Cannot process volume group vg1 No matching physical volumes found
Nakonec nezbylo, nez sehnat ten samy model QNAPu, pripojit disky - vsechny filesystemy nabehly se statusem CLEAN, aktivovat jednotlive vrtvy dle videa https://youtu.be/cvuLTgvnTjY a odsypat data po siti.
Protoze nekterym nedosla tragicnost cele situace, tak znovu opakuji. Byla to bezna NASka, pravdepodobne v defaultni konfiguraci, porizena uzivatelem domu za ucelem zalohovani blbosti z mobilu a notebooku. Ne firemni uloziste v HA konfiguraci.
Dekuji vsem za ochotu a brzy na videnou, treba u disku ze Synology
Tiskni Sdílej: