PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Představen byl notebook TUXEDO InfinityBook Pro 15 Gen10 s procesorem AMD Ryzen AI 300, integrovanou grafikou AMD Radeon 800M, 15,3 palcovým displejem s rozlišením 2560x1600 pixelů. V konfiguraci si lze vybrat až 128 GB RAM. Koupit jej lze s nainstalovaným TUXEDO OS nebo Ubuntu 24.04 LTS.
Po půl roce od vydání verze 2.41 byla vydána nová verze 2.42 knihovny glibc (GNU C Library). Přehled novinek v poznámkách k vydání a v souboru NEWS. Vypíchnout lze například podporu SFrame. Opraveny jsou zranitelnosti CVE-2025-0395, CVE-2025-5702, CVE-2025-5745 a CVE-2025-8058.
Byla vydána nová verze 9.15 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
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: