Najprv trochu príbehovo. V roku 2020, určitý čas pred prechodom z Cloveru na OpenCore a z macOS 10.14 na macOS 10.16b1 som si robeu zálohu 10.14kovej inštalácie. Zakál som si šecky zálohy pred touto a šecky zálohy po tejto robeu jak readonly komprimuvané .dmgčka tak toť táto bola volákou záhadnou a bližší neobjasnenou výnimkou pri kerej som spraveu .sparsebundle. Spraviť zálohu v inom formáte neni zrovna hneď takto voláka problematická vec, ten filesystem je. Veci sa majú totižto tak, za celé roky odkedy som na jablčnej systémovej platforme, som prežeu aj HFS+ celkom dlho a aj zažeu príchod a kompletný prechod na APFS. APFS je filesystem dobrý, nehovorím že ne. Podporuje CoW, vnútorné kontajnery a podobné sprostosti, fakt to pekne vymysleli a ešte lepší premigruvali to, čo na HFSku bolo vrátane i<Zariadení> a existujúcich macOS inštalácií. Ale nemóžem si odpustiť za tí roky povedať na APFS aj volačo zlé, s týmto filesystemom som mal ja osobne asi najvác incidentov pri porovnaní se šeckými ostatnými. Jeden incident s týmto filesystemom som mal v júni 2018 krátko po príchode macOS Mojave, jeden ve februári 2022 a potom posledný dva dni pred príchodom mójho aktuálneho MacBooku presne 16.3.2022. Teda, ten posledný bol posledným dotedy, dokedy ho nenahradeu ten z čerajšku (21.8.2024).
Le incident z čerajšku (21.8.2024)
Momentálne robím doma veliké upratuvaní na diskoch, robím porádky a stem si potenciálne vzácne veci z tých záloh dať na jednu kopu aby som vóbec o tom vedel že to existuje. Pri tejto príležitosti som zálohový disk mal vybratý, kopíruval som súbory odťál hentam a tam. Jedna z posledných velikých záloh bola zrovna táto .sparsebundle macOS záloha o kerej som dlho vedel že trvá strašne dlho kým sa vóbec namountuje. Nevedel som dóvod, neríšeu som to ale robeu som čo bolo treba, vyťahuval veci. Volačo som vyťáhol a potom som potrebuval spraviť reštart a disk prehodiť inde. A tu sa dostávame k jednému problému o kerom som v tom čase reštartu ešte nevedel.
Pojme rovno k veci, tá .sparsebundle záloha bola totižto voláky záhadný read/write výmysel pri kerom som to vtedy nedomysleu aj keď som za to moc nemohol a nemal som jak vedeť. V zálohe bolo teda APFSko keré, jak som už naznačeu, schytalo incident a posralo sa. Posralo sa z dóvodu "doví", na výpadky a disky vyzíra byť filesystem fakt náchylnejší jak na SSDčku. Vtedy sa naskytla bežná otázka "Šak vezni voláky recovery program a prežeň to s ním, šak to bude jednoduché, ne?", lenže jeden by si pomyslev... Keďže tá záloha bola úplne kaput tak nešla namountuvať. (v tomto prípade keby nešla namountovať tak by som ju pridal do recovery programu jak súbor, lenže .sparsebundle záloha je zložka s kvantiliónom malých súborov kerým rozumí jedine zálohový formát a nie ja) V tomto prípade sa zaťál nedal použiť recovery program jakéhokoľvek typu, a tým bol v mojom prípade čil Disk Drill. Ale vereu som že existuje voláky spósob.
A čil reálny spósob:
To s tým "záloha bola úplne kaput tak nešla namountuvať" bola hovadina. Ona namountuvať v podstate išla. S velikou podmínkou. Nemohol sa použiť klasický macOSový dvojklik, disk utilita a ani nič podobné. V termináli dokonca klasický "hdiutil attach" ťéž nešóv.
Na aspoň čiastočné namountuvaní bolo treba
Code: Select all
hdiutil attach -verbose -nomount -noverify -noautofsck <cesta k sparsebundlu>Code: Select all
obj_checksum_verify:6644: s1 failed: cksum 0x0000000000000000, oid 0x0, o_xid 0x0, o_type 0x0, o_subtype 0x0, size 4096
nx_corruption_detected_int:60: Container corruption detected by obj_checksum_verify:6652!
obj_read:6230: s1 oid 0x497fb7 flags 0x10040000003 0x0 type 0x40000003/0xb paddr 0x497fb7 error verifying checksum
btree_check_recent_sanity:798: s1 node 0x137e34 (level 1): error getting index 127 child: 92
nx_check_recent_sanity:1256: s1 omap check failed for omap 909411: 92
nx_checkpoint_find_valid_checkpoint:630: xid 437 sanity check of recently-changed structures failed: 92
Code: Select all
obj_init:3207: wrong object at 0x490068 - wanted oid 0x490068 type 0x4000000b:0x0 xid 0 - got oid 0x2d19 type 0x3:0xe xid 402
nx_corruption_detected_int:60: Container corruption detected by obj_init:3208!
nx_checkpoint_traverse:855: failed to get omap for checkpoint FIXUP traverse: 92
nx_checkpoint_find_valid_checkpoint:603: xid 304 failed to fix up checkpoint data: 92
Code: Select all
nx_checkpoint_find_valid_checkpoint:603: xid 395 failed to fix up checkpoint data: 92
2024-08-22 17:17:47.703 hdiutil[64298:12176400] -[DIHelperProxy(Thread) waitForHelperDone] timed out waiting for helper registration
2024-08-22 17:17:47.703 hdiutil[64298:12176400] helper did not register
obj_checksum_verify:6644: s1 failed: cksum 0x0000000000000000, oid 0x0, o_xid 0x0, o_type 0x0, o_subtype 0x0, size 4096Code: Select all
nx_mount:1636: failed to find valid checkpoint: 2
DIDiskImageInstantiatorProbe: interface 3, score 0, CRawDiskImage
DIDiskImageInstantiatorProbe: interface 5, score -100, CShadowedDiskImage
DIDiskImageInstantiatorProbe: interface 6, score -100, CWrappedDiskImage
DIDiskImageNewWithBackingStore: CSparseBundleDiskImage
DIDiskImageNewWithBackingStore: instantiator returned 0
Attaching…
DI_kextWaitQuiet: about to call IOServiceWaitQuiet...
DI_kextWaitQuiet: IOServiceWaitQuiet took 0.000002 seconds
2024-08-22 17:34:27.709 diskimages-helper[64301:12214962] DIHelperHDID serveImage: attaching drive
{
"auto-fsck" = 0;
autodiskmount = 0;
"hdiagent-drive-identifier" = "0CD77208-F07E-48B2-9F1B-D2CA1BF90069";
"unmount-timeout" = 0;
}
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: connecting to myDrive 0x460B
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: register _readBuffer 0x120008000
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: activating drive port 17419
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: set cache enabled=TRUE returned FAILURE.
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: set on IO thread=TRUE returned SUCCESS.
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] -processKernelRequest: will sleep received
Finishing…
Finishing…
/dev/disk5 GUID_partition_scheme
/dev/disk5s1 EFI
/dev/disk5s2 Apple_APFS
/dev/disk9 EF57347C-0000-11AA-AA11-0030654
/dev/disk9s1 41504653-0000-11AA-AA11-0030654
/dev/disk9s2 41504653-0000-11AA-AA11-0030654
/dev/disk9s3 41504653-0000-11AA-AA11-0030654
Našóv. Našóv file table, našóv súbory, našóv obsah, póvodné APFSko vyskladal tak, jak si ho pamatám naposledy. Obsahy som si kukal tedy v Disk Drille a nič nevyzíralo zle. Nastav ale ďalší zádrhel, volákym externým faktorom som bov nútený ten disk se zálohou vypať a ríšiť inšo, takže som ten session nehal uložiť a disk se zálohou som odpojeu. Potom keď som sa k zálohe vráteu som dav načítať session a vyťahuvať súbory. Na disk nasypalo gigabajty relevantných súborov. Priznám sa že som si spätne z tej zálohy potom už nič neprekontroluvával, takže som to potom zebral a dal na místo určeňá.
Tu samozrejme reálny spósob končí, ve vačšine prípadov je záloha zachránená, šetci sú radi a hotovo, tu vlákno bežne končí.
Akurát že v mojom prípade trt. To jak som ja ten disk odpojeu a pripojeu, to jak som načítal ten session, som toto šecko nespraveu úplne dobre. Ja som si totižto tedy nešimóv malé varuvaní v Disk Drille o tom, že to tú zálohu nájsť neví. On ju v zozname ukazuval, on ukazuval póvodne místo zálohy, ale nemal ju namountuvanú tým póvodným spósobom, takže ju nevidel a on na disk nasypal gigabajty prázdnych súborov. Je pravda že ma mohol vác upozorniť alebo potenciálne poslať kadeľahší s tým že to nemám ani robiť keď to nič reálne nevyťáhne, ale to je už jedno. Ve výsledku som na koreň problému aj tak ja došóv. V tomto prípade som ja mosel celé mountuvaní zopakuvať ešte raz, dať to prehľadať celé odzačátku ešte raz lebo ten session furt nevidel tú zálohu namountuvanú a dať to vykopíruvať. Týmto som zabeu ďalších 5 hodín len čakaním na to, aby som vóbec videl voláky obsah zálohy.
Ve výsledku som pochybeu aj ja. Raz darmo, nido neni svatý, ani software, ani človek a ve výsledku samozrejme ani ten hardware.
Čil momentálne ešte čakám kým sa veci vykopírujú, priznám sa že mi dojde že to čil aj kopíruje pomalší jak tedy prvý raz. A samozrejme uvidíme čo z toho bude, lebo z toho čo som zbežne kukol tak súbory majú náhľady, majú obsah, takže to je fakt na lepšej ceste jak to bolo dočilku.
