Az FSF.hu Szabad Szoftver Pályázat 2023 keretein belül beígért támogatásnak hála, leforkoltam a Simpleboot-ot, és belevágtam a bootmenedzser fejlesztésébe (azért írom, hogy beígért, mert bár mindjárt november, szerződést még nem sikerült aláírnunk. De megelőlegezem nekik a bizalmat, és teljesítem a rám eső rész első mérföldkövét.)
Fícsörök listája:
Lemezképkészítő
Pontosan ugyanolyan egyszerű használni, mint a Simpleboot esetén, a kapcsolói is azonosak. Tud lemezképet létrehozni, de lehet vele már meglévő eszközre is telepíteni a betöltőt.
Moduláris
A Simpleboot-al ellentétben itt lehet beépülőket is használni, amivel fordítás nélkül lehet a képességeit bővíteni. A Multiboot2 protokollt továbbra is egyetlen fájlból támogatja, mind ELF, mind PE/COFF esetén, és alapból van benne gzip kicsomagoló is. Egyelőre Linux boot protokollhoz van külön beépülő (igaz, az most már támogatja a Raspberry Pi-t), hamarosan érkeznek a többiek.
Háromféle beépülőt képes kezelni: fájlrendszer (a root partíció értelmezéséhez), kernel (a fájlformátum és a boot protokoll kezelésére) valamint kitömörítő (tömörített modulok transzparens kicsomagolásához).
Eredetileg struct exec-et akartam használni (a klasszikus UNIX a.out fájlformátuma), de sajnos manapság a GNU ld-be nem fordítják bele a támogatást, az LLVM lld-be meg soha nem is implementálták. Ezért végül saját formátum és saját linkelő írása mellett döntöttem, ami miatt tovább tartott a fejlesztés, mint eredetileg terveztem. A plgld tök jól működik, de szélsőséges esetekben lehetnek ezzel még pitty-puttyok.
Interaktív menü
Több boot opciót is kezel, ezeket színes-szagos ikonokkal és cimkékkel jeleníti meg, amik közül a felhasználó választhat, de megadható időkeret is, ami után automatikusan kiválasztja a megadottat. A cimkék alapból ASCII-k lehetnek csak, az UTF-8 támogatáshoz csak fel kell másolni egy "easyboot/font.sfn" nevű fájlt, ami a UNICODE glifeket tartalmazza (ez elég nagy, 900k körüli, mit mondjak, jó sok UNICODE karaktert definiáltak már).
A menü egyaránt megjelenik a képernyőn és soros porton is. Választani billentyűzettel vagy soros konzollal is lehet. Itt abba futottam bele, hogy eredetileg PS/2 meghajtóval kezeltem mindent, az időkeret várakozást is. Ez igazi vason gyönyörűen működik, azonban a qemu bugos, és a specifikáció szerinti 15 msec helyett host gép függően oszcillál (magyarán használható várakozásra, csak tökre nem tudni, mennyit fog várni). Emiatt végül a BIOS változatban le kellett cserélnem PIT pollozásra, aminek az a hátulütője, hogyha valamelyik BIOS nem mode 2-be inicializálja, mint ahogy a BSS előírja, hanem mode 3-ba, akkor előfordulhat, hogy kétszer olyan gyorsan telik majd az idő, mint kéne (ez nem túl valószínű, de ha esetleg mégis valaki belefutna ebbe, az légyszi mindenképp jelezze). UEFI és RPi alatt nincs gond, ott precíz a timer.
Magyar nyelvű dokumentáció
A program támogatja a magyar locale-t, továbbá a README és a részletes dokumentáció is elérhető magyar nyelven! (De még a példa konfigurációs fájlból is van magyar nyelvű kommentes verzió)
GPL licensz
A Simpleboot-al ellentétben (ami MIT volt), ez GPLv3+ licenszű lett a beépülők miatt. Így sokkal többféle forrásból jöhetnek ugyanis (egy GPL licenszű beépülőt nem lehetne MIT licenszű repóban felhasználni, ugyanakkor egy MIT vagy CC-BY licenszű beépülő simán szerepelhet egy GPL-es repóban).
FONTOS!!! Ez még csak az első mérföldkő. Ez azt jelenti, hogy az alaprendszer megvan, de korántsincs annyira kitesztelve, mint a Simpleboot, számítsatok itt-ott bugokra, és a legtöbb beépülő is hiányzik még. Ezek a második mérföldőbe vannak beütemezve, aminek a határideje dec 30 (még két hónap).
Elkészült a második mérföldkő is, elérhető a repóból! Kellemes karácsonyt mindenkinek!
Hozzászólások
Én most némileg offline vagyok / leszek, de figyelek. Rémlik, hogy volt szó BSD-ről is :-)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Igen. A legfőbb indok, ami miatt nem került a Simpleboot-ba BSD támogatás, az az, hogy túl sok kódot igényel, és egyszerűen nem fért bele 64k-ba minden. Ezért is volt fontos az Easyboot-nál, hogy legyenek beépülők, így most nincs többé ilyen korlát. Ettől függetlenül mondjuk vannak még problémák BSD fronton.
OpenBSD esetében a tömörített kernel már most is automatikusan kicsomagolódik (ezt a Simpleboot még nem tudta, az Easyboot már igen), viszont ami kicsomagolódik, az egy teljesen szabályos 64-bites Sysv ABI-t jelző ELF fejlécű bináris, miközben pedig rohadtul nem is az. A belépési pontja 32 bites és speciális verem alapú (nem SysV, na). Próbáltam írni az OpenBSD-seknek, de válaszra sem méltattak. Hát én nem fogom törni magam ilyen balfaszokért (van ugyanis saját, bejegyzett OpenBSD ABI kódjuk, szóval szimplán csak idióták, hogy hibás kód kerül a kernelük fejlécébe). Az UEFI-s efiboot.efi betöltőjüket viszont már most is kezeli az Easyboot.
FreeBSD-nél meg az volt a gond, hogy dinamikus linker kell a kernelükhöz, illetve nagyon sokféle kód a sokféle betöltőjéhez. Beépülőben ez már nem okoz problémát (detektálni se para, mert helyesen FreeBSD ABI szerepel az ELF fejlécben), viszont akkor is rohadt nagy munka mindet megírni. Szóval ez jön, de el fog tartani egy darabig, mire meglesz. Addig is az UEFI-s loader.efi-t itt is már képes használni az Easyboot.
Szóval a helyzet az, hogy modern gépeken már most is megy, a legacy-hoz kellenek csak a beépülők.
Ja, sajnos a BSD-k eléggé túlbonyolították ezt a bootolást. Ami elég lassú is, de nem emiatt, hanem optimalizálás nincs olyan magas fokon, mint Linuxnál, érthető a kevesebb fejlesztő miatt.
A másik, amit BSD-kben nem szeretek, hogy a rendes partíciót hívják slice-nak, és a logikai partíciónak megfelelőt partíciónak. Értem, hogy ez régi Unix/BSD örökség, és a BSD partíciós táblatípus miatt van, de sose szerettem. Bár az is lehet, hogy csak azért, mert MBR/DOS-os világhoz szoktam hozzá először.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Hát az már egyszer biztos!
Szerintem nem. Amit lehetett, kioptimalizáltak (boot környezetben egyébként sincs túl sok lehetőség rá, nagyon köt a vas), szerintem inkább azért lassú, mert nem jók az absztrakciók (túl sok lépcső), és még Lua interpreterre is szükség van a kernel betöltéséhez... A Linux kernelnél csak becsűröd a memóriába, összeraksz egy statikus struct-ot és ráadod a vezérlést, ennyi. A lehető legfaékebb, emiatt olyan gyors. (Megjegyzem ez a túlontúl faék egyszerűség egyáltalán nem jó, mivel portolhatatlan, ezért minden architektúrán újra meg újra fel kell találni. Az ideális valahol e kettő között lenne: ne kelljen szkriptinterpeter se, de azért legyen több egy statikus struct-nál. Az FDT alapvetően jó irány, csak annak meg nagyon elkufták az implementációját szerintem, bár még így is fényévekkel jobb, mint az AML meg az ACPICA).
Az más kérdés, ha a teljes bootidőt nézzük, bekapcsolástól a login promptig, akkor a BSD-k messze verik a Linuxot, mert egyrészt a Linux eszközmeghajtóinicializáliója nem túl hatékony, másrészről a bloated systemd lassabb, mint egy vemhes csiga. A BSD-knél ugyan tovább tart, mire betölt a kernel, na de onnantól pikk-pakk megy minden. SZVSZ.
Lehet igazad van. Nem értek ennyire mélyen a BSD-k bootolásához, részben, mert keveset használtam őket a Linuxhoz képest, másrészt meg sose volt velük bootolási problémám, hogy a motorháztető alatt kelljen matatnom, és beletanulnom a részletekbe. A Lua egy jó scriptnyelv, de valóban nem bootoláshoz való, nem optimális ahhoz.
Ami tovább bonyolít, az a menet közben kernel újralinkelés, bár azt meg ki lehet kapcsolni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Igen, igazad van, tényleg nincs vele gond. Én is csakis emiatt a projekt miatt ástam bele magam a részletekbe, mert kértétek, hogy tudjon BSD-t bootolni, egyébként eszembe se jutott volna.
Mert hát minek piszkálni azt, ami jól működik?
Lett egy csomó fordítás, ez ügyben fordulok hozzátok segítségért. Mivel nem beszélem a legtöbb nyelvet, ezért MI-vel készült gépi fordításokról van szó, jó lenne, ha valaki, aki beszéli is az adott nyelvet, átfutná, és segítene kijavítani a nyelvtani hibákat.
Fordítás három helyen fordul elő:
- src/lang a programba kerülő sztringek (ez nem sok, pár sor csupán, kevesebb, mint egy képernyő)
- README a projekt README fájlja (ez kicsit több, de nem vészes, kb. 4K)
- docs Markdown formátumú doksi (mérsékelt mennyiség, kb. 50K)
Előre is köszönöm, ha valaki áldozna a szabadidejéből a segítségre!
ps: az angol fordítás jó (max. gépelési hiba lehet), a németnél kicsit kiestem a gyakorlatból (valószínűleg jó, de ott már előfordulhatnak hibák), az oroszt általános iskola óta nem használtam, a többit nem beszélem.
forditsd vissza oket magyarra/angolra egy masik forditoval :)
amugy az angolt forditottad le MI-vel idegen nyelvekre vagy a magyart?
Már megtörtént. (Addig nem is commitoltam, míg nem ellenőriztem vissza.)
Az angolt, mert bár kevésbé kifejező és több menne a többértelműség, azt általában jobban értik a fordítók (a betanításához sokkal több angol mintát használtak, mint magyar nyelv esetén).
igen, pont ezert kerdeztem...
Ja, viszont az angollal meg az a baj, hogy nagyon nem egyértelmű. Pl. tipikus példa, hiába ugyanaz a szó, a "Login"-t máshogy kell fordítani németre attól függően, hogy hol jelenik meg, a fejlécben vagy gomb felirataként. Ezt az MI (vagy bármilyen gépi fordító) a kontextus ismeretének hiányában képtelen helyesen fordítani. De ugyanez van a "player"-el is, az is lehet játékos (pl soccer player szövegkörnyezetben) vagy lejátszó is (pl movie player esetén), és nagyon nem mindegy. Viszont ha visszafordítom, akkor mindkettőből "Login" (ill. "player") lesz, így nem derül ki számomra, hogy hibás.
Ezért is lennék iszonyat hálás, ha egy, az adott nyelvet beszélő ember átfutná a fordítást és jelezné a problémákat.
hat az ujabb neuralis halos forditok (deepl, chatgpt stb) mar eleg jol figyelembe veszik a temat, kontextust is.
a regebbi statisztikai elvu szurok (google translate pl) nem igazan...
de ismerem a problemat, pl. a konyvtar is ilyen, library, directory, folder stb attol fugg epp email kliensrol vagy file kezelorol van szo
Azt nem tudják figyelembe venni, ami infóhiányos (kontextus alatt itt most nem a szövegkörnyeztet vagy a témát értem, hanem azt, hogy pl az applikáció kontextusában hol fog megjelenni a szöveg, címben vagy gombon. Ezt a plusz metainfót nem tudod átadni, így nem is képesek figyelembe venni. Sok nyelven például tudni kéne a helyes fordításhoz az alany nemét is).
A másik meg, hogy sokszor félrefordítanak azok is a hallucinációik miatt (pl itt meg itt), és ez nem valami, amit ki lehet küszöbölni a mostani technológiával (ezt persze nem verik nagydobra, de ez egy kijavíthatatlan hiba a modellben).
Például adódhatnak kellemetlen félreértések (második linkről): For example, in Polish, Microsoft Bing translated "You're welcome to join us [at the restaurant]," to "Zapraszamy Cię do nas," which is actually an invitation to "come to my house,"
De az abszolút kedvencem ez: Google Bard rarely worked, and even told us, "I cannot translate languages." :-) :-) :-) Végül is kivételesen igazat mondott :-)
nézem az angol <-> német verziót.
Fordításnál sajnos nehéz a teljes szöveg/kontextus nélkül jól fordítani. Pl.:
"unable to locate boot partition in", / "Die Bootpartition konnte nicht gefunden werden",Az angol végén az "in" miatt azt várnám, hogy ott egy hely/fájl meg van adva - ez a németben jelenleg rövidre van zárva, hogy nem találja a boot particiót. Viszont ha az angolban ott még több infó megjelenik, akkor szerintem ez a németben elveszik.Ugyanez vonatkozik a 15-17. sorokra, miközben a 30-31. sorban ez jól müködik.amit javítanék:5. "ist eingehängt. Bitte zuerst aushängen." vagy "ist gemounted. Bitte zuerst aushängen."20. "Installer"
21.
"Debug-Ausgabe erhöhen / Validierung" (itt is jó lenne tudni, miröl van szó)24. "Legen Sie die eindeutige Kennung der Boot-Partition fest (Standard: zufällige Generierung der Kennung).",
25. "Erstellen Sie immer eine neue Abbilddatei, auch wenn diese vorhanden ist",
35. "Zeile"
38. "Falsche Option für Debug-Ausgabe" (lásd 21.-es)
39. "Falsche Framebuffer Dimension"
41. "Falscher Standard-Wert"
42.
"Falscher Ausrichtungswert, „vertical“ oder „horizontal“",43. "Fehlende Zeile mit Kernel im Menüeintrag",
45. "Pfad zu lang"
47. "Das Abbild ist nicht im TGA-Format mit RLE-Farbzuordnung",
48. "Das Icon ist nicht 64 x 64 Pixel groß",
54. "Partition auf der Bootdisk nicht gefunden",ami kontextus miatt még kérdéses (lehet, hogy jó):11.-18.egyébként gratula mindkét projekthez!
Nagyon szépen köszönöm!
Pontosan.
Egy kicsit körülményes a dolog, mert a minnél kissebb footprint volt a cél. Úgy lehet nyakoncsípni, hogy az easyboot.c 52. sorában van egy enum. Ennek kell egyeznie minden fordítás fejlécfájl sztringjeivel. Az enum-ra keresve az easyboot.c-ben meg látható, milyen környezetben jelenik meg. Macerás, nem tagadom. (Nem az én ötletem egyébként, Eric S. Raymond javasolta ezt a sztringek helyett define-okat, nekem meg csak megtetszett, mivel dependency-free megoldás. Ezt később tömbbé alakítottam, és a define-okból index enum lett, hogy futásidőben is lehessen váltogatni a nyelvet.)
Például a 14. sorhoz ("unable to locate boot partition in") a ERRPART enum tartozik, ez pedig így íródik ki:
Szóval igen, van utánna fájlnév, és ez általánosságban is igaz, ha van paraméter, az a lefordított szöveg után jelenik meg.
A 21. sorhoz ("increase verbosity / validation") a VERBOSITY, ennek a kiírása pedig:
printf(" -v, -vv %s\r\n", lang[VERBOSITY]);Azért így, mivel a fordításban nem szerepelhet "%s", ugyanis a C fordító besír, ha a printf/fprintf/sprintf első paramétere nem literál hanem változó. Egyrészről gondolom azért, mert csak angolul beszélő emberkék írták az ellenőrzést a fordítóba, másrészről meg tényleg nem szerencsés változót használni itt, nehezíti a statikus paraméterellenőrzést (igaz, az easyboot esetében mindegyik beégetett, nem dinamikus, szóval itt elvileg nem lehetne baj belőle, de jobbnak láttam elkerülni a C warningokat => fordítás nem lehet formázó sztring, csak paraméter).
Egyébként a blokkokra tagolás nem véletlen, minden blokkon belül minden sztringnél pontosan ugyanaz a paraméter:
1. (egyetlen sor, kétkarakteres kóddal) nyelvkód, nem íródik ki soha
2. általános hibaüzenetek (memóriafoglalás, fájlírás/olvasás stb.) mind után van pontosan egy fájlnév paraméter
3. parancssori súgó üzenetek, a flagek után jelennek meg, nincs paraméter
4. generáláskori üzenetek (általában önmagukban jelennek csak meg, vagy ha van mégis mellé kiírás, az a konfigfájl hibás sorából idézet, szóval működhet ragozás nélkül is)
A javítások:
5. javítva
20. Uppsz, asszem a franciát copy'n'paste-tem? Javítva
21. ez akkor jelenik meg, ha kapcsolók nélkül indítod, a "-v | -vv" leírásában. nem cseréltem, mert nem debug kimenetről van szó
24. ezt se cseréltem le, de csak mert túl hosszú, és így elüt a többi sortól (ez is akkor íródik ki, ha paraméter nélkül indítod, a "-u" leírása).
25. javítva
35. javítva
38. javítva, de meghagytam az "ausführlich"-et (hogy egyezzen a 21.-el)
39. javítva
41. javítva
42. javítva
43. javítva, de meghagytam Kernelzeile-nek
45. javítva
47. javítva
48. ezt meghagytam Symbol-nak, de csak azért, mert kezd túl sok Abbild lenni (lemezkép, képfájl, ikonkép stb.)
54. javítva
Nagyon szépen köszönöm! Gondoltad volna, hogy csak sideproject-ről van szó? (A MEG-4 projektemet akartam OS nélkül is futtatni, onnan indult az egész)
nagyon szivesen! amikor a fórumon megláttam a szálat, nagyon megörültem, mert sokat szívtam már grub-al és utálom (nem is ástam bele magam egyáltalán, a lilo-t még értettem meg szerettem)
egyébként hogy érdemes játszani vele? vm-be egy akármilyen distrót feltenni és ott? sajnos csak minimális szabadidöm van ilyenekre.. :/
emiatt sajnos most nem tudom végig nézni, hogy a sztringek hogy állnak össze - ha majd sikerül kipróbálnom, akkor majd a németet választom és jelzek, ha valami nem tetszik.
a 41.-ben kimaradt egy "r" betü, "Falscher" a helyes
Ezt az "Ausführlichkeit"-et viszont újra kéne gondolni, mert nagyon sérti a fülem. Tulajdonképpen mit csinál az az opció?
menö, csak nem tudtam rájönni, hogy mi ez? Egy saját OS a nevéböl tippelve? Az persze még királyabb...:)
Egyébként általánosságban nagyon sokan rosszul dokumentálnak, szerény véleményem és visszajelzések alapján az én doksijaim nem rosszak:
- próbálom a "hogyan"-t dokumentálni, és nem a "mit" (pl: ürlap doksi, sokan azt írják a bemeneti mezöre, hogy "ez egy bemeneti mezö a xy inputhoz" - én azt, hogy "a bemeneti mezö az xy paramétert várja csak számok vagy betük formájában, ez a minimum és ez a maximum érték/hossz/stb")
- megadni a szélsöséges paraméter határokat
- kicsit rá világítani a megadható értékek rendszer szintü vonzataira is. pl. ha túl kevés ram-ot adsz meg egy vm-hez, akkor az elég hamar használhatatlan lesz, stb.
egyébként nálad kiemelkedönek tünik, hogy ennyi energiát fektetsz a doksiba. Viszont csak úgy naivan rá kérdezek: van natív doksira igény, nem elég az angol?
ok, most jobban megnézve, látom, hogy a MEG-4 egy játék - ezért is "riszpekt"! :)
ezek csak ilyen hobbi projektek a rendes programozó munka mellett?
Szerintem igen. Van is rá rule, make run legyárt egy lemezképet és qemu-ban elindítja. A lemezképet be lehet mountolni és tetszőleges distro fájljait bemásolni, vagy akár le lehet cserélni egy meglévő lemezképre (a parancssori tool képes meglévő lemezképre telepíteni a betöltőt).
Részletes kimenetet ad (kb. mint az összes többi UNIX-os parancsnál a "-v" kapcsoló). Két "-vv" esetén szintaktikailag ellenőrzi a konfigfájlt, és ezen ellenőrzés kimentét is kiírja. Szóval bőbeszédűség, nem kifejezetten debug, bár két "-vv" akár debugra is jó lehet.
Pontosan. A MEG-4 egy virtuális fantasy konzol, ami futtatható önálló operációs rendszerként is (magyarán GNU/Linux és Windows nélkül).
Egyetértek. Én is igyekszem mindezeket belevenni, bár én tagolni szoktam. Pl itt: README-ben csak nagyvonalas áttekintés, doksiban részletesen kifejtve, melyik kapcsoló mire való és milyen összefüggések vannak köztük; végül a technikai specifikáció a legapróbb részletekbe is belemegy.
Kösz! Igazából megszokás. Angol doksit mindig készítek, ha a terv az, hogy a gyerekeim is használhassák, akkor magyart is. Ha meg már van több fordítás ígyis-úgyis, akkor a be szoktam dobni a világnyelveket, mégha csak gépi fordítással is, mert miért ne.
Például ezt is a gyerekeimnek csináltam, úgyhogy az alap angol mellett itt is van magyar nyelvű doksi, többi viszont nincs, mert lusta voltam :-) A doksitól függetlenül azért a programban megjelenő sztringeket itt is lefordítottam (itt kijezetten azért, mert pl a németet és a portugált konkrétan kérték a felhasználók).
Nem játék, hanem játékkonzol :-) Azaz játékok készítésére alkalmas környezet (van benne kódszerkesztő, fordítóprogram, szprájtrajzoló, zeneszerkesztő, stb.) A cél itt az volt, hogy külön program telepítése nélkül, csak ezzel az egy programmal teljeskörűen lehessen egy játékot a nulláról elkészíteni.
Hobbi projektek mind.
Rendes állásom nincs, sajnos nem is lehet, mert a végrehajtói maffia rámszállt. Schadl-Völner ellen hiába folyik büntetőeljárás és bírósági per jelenleg, arról kurvára mélyen hallgatnak, hogy esetleg talán kárpótolni kéne azokat, akiket megkárosítottak ezek a gengszterek. Erről nincs szó...
Jelenleg is végrehajtás folyik ellenem úgy, hogy
- a végrehajtási lapot még csak nem is illetékes bíróság állította ki,
- bíró neve nem is szerepel rajta (még csak a neve sem, nehogy a hitelesítő aláírása),
- semmilyen bírósági végzés sem hagyta jóvá a behajtott összeget (a hivatkozott végzésben konkrétan az áll, hogy a végrehajtást kérő tartozik Nekem milliókkal, és nem Én neki),
- az sem zavarja a végrehajtót, hogy a lapon szereplő állítólagos munkahelyem valójában egy nem is létező cég
- vagy hogy időközben egy másik jogerős bírósági végzés is kimondta, hogy nem is tartozom
Ezekután azon sincs mit csodálkozni, hogy a jövedelmem többszörösét (!) vitték havonta (már amíg még volt mit, 3 hónap alatt ugyanis kifosztották a bankszámlám és az összes megtakarításom is, pár hétig az utcán kellett laknom). A rendőrségen persze feljelentést tettem, de azok lezárták az ügyet azzal, hogy a "közokirathamisítás nem bűncselekmény" (nem viccelek, szó szerint ez szerepelt az indoklásban). Az ügyészség persze rájukszólt, hogy dehogynem bűncselekmény, tessék lefolytatni azt a nyomozást! Erre a főkapitányság áttette az ügyet a megyei kapitányságra, és hogyhogynem, a teljes nyomozati anyag szőrén-szálán "eltűnt" út közben, semmi sem érkezett meg a megyei kapitányságra belőle...
Ez ma Magyarország, ez az Orbán-rendszer valódi arca.
:(
Engem is lenyűgöz a szakértelmed és hogy mit bele nem raksz.
Gratulálok a munkádhoz, tiszteletre méltó! Valamint sok erőt és kitartást a jogi eljárások során!
Sajnos a munkádhoz érdemben nem tudok hozzászólni, de ezen szál elolvasásával is sokat tanultam, köszönöm!
Hihetetlenül elképesző történeted sajnos nem egyedülálló, én is meg tudom erősíteni.
Az egyik barátomnak a napokban szólt a személyzetis, hogy októbertől az xy végrehajtó foglalni fogja a fizuja 33%-át. Fogalma sem volt, hogy miért, hogyan, stb. Valami _állítólagos_ Westel 900 telefontartozás 2001-ből. Nem volt velük szerződésben sosem, soha semmilyen értesítést nem kapott.
A végrehajtó azt mondta, hogy 2003-ban küldtek neki levelet. Mondta, hogy nem kapott semmit, mutassák meg az ajánlott küldemény feladóvényét, de nem nem ajánlottan küldték (ha igaz, hogy küldtek bármit is), hanem simán.
Szal ott van, hogy azt sem tudja, miről van szó, de foglalják a fizuját. Persze írt ellentmondást, de attól még a végrehajtás folyamatban van a behajtással együtt.
Nekem a nagypapám örökségével kapcsolatosan van dolgom a végrehajtókkal. Nagypapám ellen úgy indították meg a végrehajtást, hogy 1 hónapja halott volt. A fizetési felszólításkor egyébiránt tájékoztattam őket a halotti megküldésével, hogy hiába leveleznek vele. Állításuk szerint azonban nem szerepelt a BM rendszerében, mint elhunyt személy, ezért ők szabályosan jártak el.
Persze - remélhetőleg - neked és a barátomnak is tisztázódni fognak ezek a dolgok, de hogy ki és mikor kapja vissza a jogtalanul elvett vagyonát, azt nem lehet tudni, főleg, amilyen lassan és rosszul működik az egész jogszolgáltatás. Én pl. 13 hónap alatt jutottam el oda, hogy egy beázó ingatlanom birtokper keresetét befogadja a bíróság (másodfokon kellett eljárnom csak azért, hogy ne utasítsák el másodjára is kereset befogadását.), még egy év mire ítélet születhet (addig is folyamatosan be fog ázni az ingatlan), de elsőkézből ismerek még sok másik hasonlóan abszurd jogi ügyet...
Részemről teljesen megszűnt a bizalom a jelenlegi jogrendszer irányába, amikor csak lehet, saját hatáskörben fogom megoldani a problémáimat. Nincs időm, energiám és pénzem a szélmalomharcra. A történeted is megerősíti, hogy a rendőrséggel sem nagyon lehet baja az embernek, ha saját hatáskörben bírálja és intézi el a dolgokat...
Hat kerem szepen tessek NER-esnek szuletni vagy a Tiborcz baratjanak lenni, akkor ahogy ok mondjak "ram nem vonatkoznak a torvenyek". :D (a Balabo-s fasz a Tiborcz golyonyaloja :D)
Nagyon szépen köszönöm!
Nincsenek. Hat éven át küzdöttem az igazamért, a bíróságok szisztematikusan figyelmen kívül hagyták az összes tárgyi bizonyítékot, ami mellettem szólt, és folyamatosan hamisították a tárgyalásokról készült bírósági jegyzőkönyveket (ezt bizonyítani is tudom, mert becsempésztem egy diktafont, és hangfelvételeket készítettem a tárgyalásokról). Mindezek ellenére mégis megnyertem a pert, de hiába lett egy jogerős végzésem arról, hogy nem is tartozom, mégis tovább folyik a végrehajtás mind a mai napig.
Akkor még olcsón megúszta, hagyták élni. Nekem nem szólt senki sem, onnan tudtam meg, hogy a jövedelmem többszörösét meghaladó összeget (!) vonnak, hogy nem tudtam az albérletre felvenni pénzt, amikor kellett volna.
Részvétem. Nálam még csak ennyi se, én rendesen szerepeltem a nyilvántartásban, az állítólagos munkáltatóm évekkel korábbi megszűnése is iktatva lett a cégjegyzék szerint. Esetemben nemes egyszerűséggel nem vettek tudomást a állami nyilvántatrásokról és a hatósági bizonyítványról.
Nálam ez úgy volt, hogy beadtam egy keresetet arról, hogy megváltoztak a körülményeim, az erről szóló értesítést postázták a másik félnek, akinek mindjárt másnap kiállított végrehajtási lapját még aznap (!) iktatta is a bíróság (annak ellenére, hogy a keresetemhez csatoltam a hatósági bizonyítványt, így tudniuk kellett, hogy a végrehajtási lapon szerepelő adatok hamisak). Ezt követően majd' egy év telt el az első tárgyalás megtartásáig, több, mint 4 évig húzták a pert, mire kimondták, hogy nem tartozhatok a behajtott összeggel (a hamis adatokkal folytatott végrehajtás közben persze végig ment, "elfelejtették" felfüggeszteni, hiába volt bírósági eljárás folyamatban az ügyben.)
Szóval nem kell aggódni, a Balatonparti szőlőtulajdonos NER-eseknek mindössze 1 nap az átfutási idő, gyors ez a rendszer...! Ha bíró neve meg aláírása nem is szerepel a lapon, akkor pikk-pakk megy ám ez!
Miután összeomlott az Orbán-rendszer, annál előbb biztosan nem. Erre már nem kell túl sokat várni, a diktatúrák végső hanyatló stádiumának iskolapéldáját látjuk épp. Én inkább attól tartok, hogy miután hazavágták a gazdaságot (is), félő, hogy a rendszer bukása magával ránthatja az egész országot. És akkor nemcsak mi, hanem mindenki más is ugyanígy fog járni.
Az öcsém a rendőrségen dolgozik, néha olyanokat mesél, amitől tényleg égnek áll az ember haja. Azt mondja, szarik ott már mindenki az egészbe, kifezetetlen munkabérrel meg sok száz milliós, halmozódó rezsihátralékkal vannak elfoglalva, nem a bűnözőkkel.
Maximum időnként elkapnak pár pitiáner piaci tolvajt meg betörőt, hogy meglegyen a statisztika, esetleg egy-két közútis kollégájukat, ha kirívóan túltolja a megvesztegetést, de eszük ágában sincs megvédeni a becsületes adófizetőket az igazi bűnözőkkel szemben. Volt itt HUP-on is nemrég, hogy a netes csalások száma az egekben, szerinted hány ilyen elkövetőt kaptak eddig el?
Ide a rozsdás bökőt, hogy Schadl ellen is csak azért folyik most eljárás, mert Varga Judit iskolai pajtása szemet vetett a pozijára és szép szóra nem volt hajlandó felmondani, nem máté'. Szó sincs itt igazságszolgáltatásról, csak el kellett paterolni, hogy helyet csináljanak az új seggnyalónak.
de ne már, hogy ezek a dolgok átmennek??!! A bank vagy a munkáltatód csak úgy egy jöttment "végrehajtónak" bejegyzett cégnek oda adja a pénzed?? Ennek is meg van (kéne lennie) a törvényi lefolyásának, hogy mi kell szerepeljen azon a papíron, hogy érvényes legyen...mint írod, bírói aláírás, pecsét....
és az alatt nem kérvényezted a végrehajtás felfüggesztését? a néhány megmaradt oknyomozó / független médiát nem érdekli az ilyen?
@bzt: egyébként nálunk legalább 100-200 ember elférne az ilyen programozó tudással, hogy gyorsabban meg tudjuk valósítani a termékeket....külföldön nem gondolkoztál még?
joreggelt agyarorszag :D
viccesek a jogrendszer tisztasagarol feltett naiv kerdeseid :D
szerencsére nincs semmi ilyenhez közöm és ugye hall/olvas az ember ezt azt, de mégis gondolja/reméli, hogy nem ennyire velejéig rohadt az egész.
Van rá törvény, csak szarnak rá. A VHT. megköti mennyit vihetne a végrehajtó, a BTK. meg egyébként elég egyértelmű: "aki anyagi haszonszerzés céljából törvényt sért, az bűncselekményt követ el".
Dehogynem. Az volt a válasz, hogy ilyent csak a végrehajtást kérő tehet. Mégis lett ügy belőle, mert a végrehajtó is jelentette a bíróságon, ahol meg is indult az ügy a felfüggesztésért a nevemben, de aztán úgy zárták le azt, hogy engem meg sem hallgattak, a beadványimat nem fogadták, visszaküldték azzal, hogy "majd az ítélethozatal után reklamáljak" (nem viccelek, ezt volt). Az iratokhoz közben folyamatosan akadályozták a hozzáférésem, így csak később, az ítélethozatal után tudtam meg, hogy kapott az a bíróság egy beadványt, amiben olyan rágalmazások szerepeltek, hogy állítólag "alkoholista drogos vagyok" (ami persze hazugság, és nem mintha lenne bármi köze is ahhoz, hogy a végrehajtási lapon hamis adatok szerepelnek, vagy hogy egy másik bíróságon folyamatban van az ügy). Mikor végül sikerült hozzáférnem az iratokhoz, nyilván egyből újratárgyalást kértem.
A másodfokú bíróság megállapította, hogy az "alperes beadványai rágalmazásra alkalmasak" (szó szerinti idézet a végzésből), de a rendőrség mégsem tett semmit, és az ügyet sem tárgyalták újra. Abban meg, hogy a hamis adatokkal indított végrehajtást helyben hagyó ítéletet kizárólag az egyik oldal rágalmazó beadványai alapján, a másik fél meghallgatása vagy akár egyetlen beadványának befogadása nélkül, a végrehajtási lapon szerepelő adatok valóságtartalmának ellenőrzése nélkül hozták, nem láttak egy pötty szabálytalanságot se...
Megjegyzés: ez a bíróság is figyelmen kívül hagyta, hogy a behajtandó összeget soha, semmilyen bírósági végzés sem hagyta jóvá, az állítólagos munkáltatóm egy nem létező cég, vagy hogy épp álláskeresőként szerepeltem akkor a hivatalos nyilvántartásban.
Megjegyzés: azt meg, hogy nem vagyok alkoholista drogos, még az NBF is tanúsíthatja, ugyanis amikor ez történt, akkor még érvényes C típusú nemzetbiztonsági átvilágítással rendelkeztem (ma már nem, lejárt azóta az öt év).
De, megpróbáltam. Ott a végrehajtási ügyhöz hasonló hazug levelekkel bombázták a munkaadómat, és ezzel becsületsértés büncselekményét valósították meg. Egy jótét lélek a Nemzeti Fordítóirodában ráírta ugyan a fordításra, hogy törvényhelyhivatkozás és érvényes aláírás nélkül nem szabályos a levél eredetije, de ez nem volt elég. Tisztább, szárazabb érzés volt nekik megszabadulni a problémás migráncs alkalmazottól még a próbaidő alatt.
Arra egyébként kíváncsi lennék, honnan tudták meg, hogy hol tartózkodom és hogy melyik cégnél kezdtem meg a próbaidőt, mert semmilyen legális úton nem juthattak hozzá ehhez az információhoz. Csakis illegális úton deríthették ezt ki. Plusz csavar, hogy az a cég pont akkor költözött új irodába, amikor ott kezdtem, a honlapjukon és minden hivatalos nyilvántartásban meg nyilvános fórumon még a régi címük szerepelt, a rágalmazó levél mégis az új, még be sem jelentett címükre érkezett.
Ja, mondjuk mit is várunk azoktól, akik törvénytelenül Pegasussal kémkednek az állampolgáraik után? Ez egy maffia, a legalja gerinctelen, pénzsóvár szarháziak bandája, akként is viselkednek. Aki elhiszi, hogy demokratikusan lett választva a hőn imádott vezetők, vagy hogy csupán véletlen, hogy a gyerekkori pajtása az ország leggazdagabb embere, az szimplán hülye.
Köszönöm a bizalmat, szívesen jelentkeznék is, de valami azt súgja, ha megtenném, akkor kapnátok egy olyan NAV ellenőrzést a nyakatokba, mint Iványiék. Ha van rajtatok sapka, az lenne a baj, ha nincs, akkor meg az.
ha a következő nem távmunka lesz, akkor hagyd otthon a mobilod...;) vagy írj rá egy spyware keresőt - neked megvan egy délután alatt.. ;)
nálunk a navnak nincs hatásköre szerencsére (külföld)
Ha a NAV-nak nincs hatásköre, akkor meg olyan szarfröcsögős rágalmazási hadjáratot kaptok a nyakatokba, hogy csak na. Keményen tombol ám Orbán köreiben a cancel-culture, mindenkit, aki nem nyalja fényesre a seggüket, megpróbálnak lerántani a saját primitív szintjükre. Hozzájuk képest a szcientológusok "fair play"-e csak egy könnyed babazsúros kampány.
Mondom, amikor megpróbáltam külföldön elhelyezkedni, konkrétan rágalmazás és becsületsértés bűncselekményét követték el (amit, ha nem lenne velejéig korrupt és töketlen a rendőrség, több év börtönbüntetéssel kéne sújtani a BTK szerint). Mondjuk rám aztán kiábalhatnak kutyát-békát, most már kurvára leszarom, de lehet, hogy a Te cégednek gondot jelentene.
Az év "Szent Őrült"-je díjat simán neked adnám. Hihetetlen mi melót beleteszel ebbe.
Szuper, köszi a munkádat!
Köszönjük! Jól értem, hogy ez azt a szerepet csinálja, amit a Grub, LILO, stb is? Most éppen minden gépem működik és inkább nem nyúlok hozzá, de ha legközelebb telepítek valamit, akkor kipróbálom!
Igen, kb. mint a Grub, de nem többmegányi, hanem pár kilobájt csak, és egyetlen függőségmentes paranccsal lehet telepíteni. (A LILO megfelelője a kistesó Simpleboot, ami pontosan egy kernelt tölt be, boot menü nélkül).
Ez még csak béta, nem production ready. Multiboot2 kerneleket, Linuxot és (UEFI alatt) UEFI alkalmazásokat tud már indítani, de a többi kernel támogatása még hátravan. És még apróbb bugok is előfordulhatnak.
Jelen állapotában inkább virtuális gépeken javaslom a biztonság kedvéért. (A Simpleboot ezzel szemben alaposan ki lett már tesztelve, igazi vasakon is, azt bátran merem ajánlani.)
Köszönöm! Örülök, hogy elnyerte a tetszéseteket!
De nem gondolom, hogy hihetetlen melót tennék bele, ez nekem csak a szokásos, szeretek igényes munkát kiadni a kezeim közül.
Hat nem tudom, de ilyenkor cloud es bigdata architect-kent es DevOps-sokent aki azert itt-ott programozik is (Go, Scala, Python, etc) kurvara haszontalannak erzem magam :D
Ez az igazi tudas nem az enyem baszod :D
Ismerem ezt az erzest.
Es egyedul C programozok iranyaba szokott ilyen erzesem lenni.
Mindenki mas eseten kb. ugy erzem, hogy sok gyakorassal el tudnam vegezni vegulis a napi munkajat.
Hát én nem érzem ezt olyan hű, de nagy dolognak, számomra ez tényleg csak "business as usual".
De nagyon szépen köszönöm, jól esik, hogy így gondoljátok! A szavaitok arra ösztönöznek, hogy méginkább odafigyeljek, minőségi legyen a végeredmény!
Csodálom az energiádat. Azt hittem, hogy az ilyen élettörténetek csak a drogos filmrendezők fantáziájában születnek. Ezek szerint ez a való világ, "magyarország így szeretlek". Hogy lehet így élni, hogy lehet így létezni ? Minden tartalék elfogy egyszer.
üdv: virtualm
Nehezen. De ezerszer vállalom inkább ezt, semmint hogy elkurvuljak és beadjam a derekam ezeknek a gerinctelen szarcsimbókoknak.
Vagy mint esetemben, mindjárt az elején ellopják az egészet (mindenemet elvették, nyugdíjtakarékot, Fundamentát, gyerek iskolázására félretett alszámlát, mindent). De ezzel csupán csak annyit értek el, hogy megtanultam ennélkül élni. Azt mondják, ami nem öl meg, attól csak még erősebb leszel.
Az Orbán-rendszer összeomlásáig most már egész biztos kihúzom, nagyon a végsőket rúgja. Azután meg két forgatókönyv lehetséges: 1) népharag végül börtönbe juttatja őket, én pedig a politikai fordulatot meglovagolva addig ütöm a vasat, míg visszamenőlegesen kártérítést nem csikarok ki és elégtételt nem veszek, vagy 2) velük bukik az egész ország cakk-um-pakk és mindenki oda jut, ahol most én vagyok, ekkor meg előnyben leszek a most megszerzett rutinommal. Így vagy úgy, az idő nekem dolgozik :-) Azért az első forgatókönyvnek jobban örülnék, mert spin-diktatúra ide vagy oda, mégiscsak szeretem a hazámat. Ebben az évszázadban is még mindig húsbavágóan aktuálisnak tartom, hogy "Magyar vagyok / Magyarnak születtem / Árulók és gonosztevők uralkodtak felettem".
(Csupán a teljesség kedvéért van még az, hogy újra a Neo-Szovjetúnió legvidámabb barakkja legyünk. Ez kizárt, a Fidesz valami gyíkemberes alternatív valóságban él, hogy mégis ez a célja. A valódi szövetségeseink - EU és NATO - a jelenlegi geopolitikai környezetben nem fogják ezt hagyni, vagy ha minden esély ellenére mégis megtörténne, akkor abból csak egy újabb '56 lenne. A Fidesz mindenképp bukásra van ítélve emiatt, nincs olyan forgatókönyv, amiben győzhetne. És ha bárkinek kételye lenne az oroszok valódi célja felől, Putyin kerek-perec megmondta, nem is egyszer, hogy a célja a Szovjetúnió visszaállítása, és a hazaáruló Orbán valójában ehhez adta áldását, mikor kezet rázott vele.)
Először is megagrat a projektjeidhez. (Ha esetleg van kedved embedded Linux (OpenWRT, Buildroot) és ARM mikrokontroller (STM32, PSOC, stb) alá C-ben fejleszteni dobj egy privátot.)
Másodszor...
Szerintem csalódás fog érni, ha be fog következni a várva várt Orbán-rendszer összeomlás. Nem az Orbán-rendszer ilyen, a rendszer ilyen.
A 90-es évek közepén bebuktam egy pár százezer forintos gépkocsi hitelt. Szerencsére, mert így ideje korán szembesültem azzal, amivel most Te és sokan mások. Már akkor is létezett a végrehajtó maffia, sőt a felszámoló maffia, a közjegyzői maffia, kisajátítási maffia és a karhatalmi szervek maffiája is. Az alvilági maffiáról ne is beszéljünk. Ezen a ponton döntenem kellett az életemről, hogy hogyan tovább. A döntésben segített még az akkori VÁLLAKOZÓ, azaz Palotás János egy mondata: Nem az a gazdag ember, akinek sok pénze van, hanem az aki szükség esetén a kellő erőforrás felett rendelkezik. Szóval azóta úgy élem az életem, hogy gyakorlatilag egy fillér vagyonom sincs, de a szükséges erőforrások mindig a rendelkezésemre állnak.
Már változtathatnék ezen, mert a régi terhek már eltűntek, de soha nem lehet tudni, hogy pl. egy új kormány esetén milyen szart kennének a nyakamba. Szóval marad minden így: vagyon nuku és a szükséges minimális kapcsolódás a rendszerhez. Ennek tökrében annyi lazulás történt az elveimben, hogy hivatalosan a rendszer része vagyok munkavállalóként, így úgymond jó rabszolgának nézek ki. Igaz így krach esetén max. egy havi munkabéremet bukhatom, de ennyit megér a látszat fenntartása.
Egyébként ez az életmód - ha naprakész vagy a jogszabályokban - meglepően kevés lemondással jár, pl. voltak cégeim is. Akkor sokalltam be a cégeskedéssel (eladtam az összeset), mikor Ferink kitalálta az úgynevezett elvárt adó kategóriát. Ennek az a lényege, hogy akkor is kellett adót fizetned, ha nem volt nyereséged. Na most ez egy olyan szituációban ért amikor a cég teljes vagyona be volt fektetve egy új projektbe, hitelt kellett volna felvenni az adó befizetéséhez. Biztos, hogy ezeket akarod vissza?
Nekem majdnem tök mindegy ki van hatalmon, de a mostaniakat már elég jó ismerem. Tapasztalatom szerint elv és morál nincs a rendszeren belül, a rendszerre pedig egyelőre nem tudok hatással lenni.
„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)
> Ennek az a lényege, hogy akkor is kellett adót fizetned, ha nem volt nyereséged.
nem kellett, csak egyszerubb volt. valaszthattad helyette azt is, hogy kitoltesz egy tobb oldalas nyomtatvanyt amiben megindoklod szamokkal (pl. mennyit koltottel reklamra, eszkozre stb) miert nem volt nyereseged, majd jo esellyel kaptal egy APEH ellenorzest is.
amugy mar ez elott is (en az 1. orban alatt lettem vallalkozo) ugy mukodott a rendszer, hogy a veszteseges cegeket vegzaltak folyamatosan, csak akkor ez nem volt leirva.
Köszönöm!
Nem fog. Tökéletesen tisztában vagyok vele, nem véletlenül fogalmaztam úgy, hogy majd az épp aktuális "politikai fordulatot meglovagolva". Nincsenek illúzióim a rendszert illetően.
Szó sincs róla, ugyanannak a kutyaólnak a kölykei, nem ma jöttem a falvédőről, hogy bedőljek a Fideszes propagandának, miszerint "ellenzék" lennének. Egy időben közel voltam a tűzhöz, saját szememmel láttam, hogy a színfalak mögött együtt járnak golfozni meg kurvázni. Látok is némi esélyt arra, hogy őket is előveszik majd, mert már túl sok a vaj a fejükön (számlagyár esete pl, meg Orbán LMP-s nyaralása) és nem hiszem, hogy megint sikerülne úgy elmaszatolni, mint legutóbb '89-ben.
Dehogy nem tudsz, azt csak elhitették veled, hogy nem. Valójában nagyon is egyszerű, nem tüntikézni kell, hanem középső ujjat mutatni befizetés helyett. Ott kell ütni, ahol fáj nekik: ha egyszerre elég sok ember tagadná meg az adóbefizetést, a NAV képtelen lenne bármit is tenni ellenük, és a lavinában máris úgy omlana össze az egész rendszer, mint a kártyavár.
És ez elég jó eséllyel be is következik, na persze nem azért, mert a tömegek öntudatosan kiállnak az igazukért, hanem mert balfasz honatyáink miatt rohamosan nő azok száma, akik képtelenek befizetni bármit is. Gondolj csak bele, ha még a KSH is elismeri hivatalosan, hogy majdnem minden 5. magyar (18.2%) ki volt téve szegénységi kirekesztődésnek három éve, akkor mennyi lehet vajon most a valós adat? Önmagában csak az is beszédes, hogy nem mernek 2020-asnál frissebb adatot kirakni a KSH honlapjára.
Miheztartás végett, 2019-ben a magyarok 75%-a élt az EU-s szegénységi küszöb alatt (ld. TÁRKI felmérése, 16. oldal), és azóta ugye volt COVID, lett gazdasági recesszió, rezsicsökkentés-csökkentés (sicc!) meg EU rekorder infláció is... (amit tutira meg fognak kozmetikázni, hogy év végén egy számjegyűnek tűnjön, na de attól még a valóság megmarad, és azt is tegyük hozzá, hogy a bérek nem követik még ezt a kicicomázott inflációt se.)
Na, kidebuggoltam a beépülőket. Nem volt egy leányálom, az egyik hiba konkrétan Clang bug volt (hiába volt a kifejezés minden változója 64 bites, és a konstans is UL-es, mégis 32 bites shiftelésre fordult, emiatt non-cannonical address keletkezett a relokációkor).
A lényeg, hogy tesztelve ELF64 és PE32+ kernelekkel (Multiboot2), valamint a Linux betöltő beépülő is jól működik. Azért minden lehetséges esetet még nem sikerült kipróbálni, csak a leggyakoriabbakat.
A következő lépés beépülők gyártása, fájlrendszerek meg kernel protokollok, valamint tesztelés, tesztelés, tesztelés.
Újabb fejlemények!
UEFI is kidebuggolva, SecureBoot támogatás megoldva (shim), és egy csomó beépülő elkészült. Lett egy új beépülő típus is, ami tetszőleges adatokkal tudja kibővíteni a kernelnek átadott boot infót.
Támogatott kernelek:
Linux (mindet ugyanaz a beépülő támogatja):
- BIOS alatt
- UEFI alatt
- Raspberry Pi-n
Windows
- UEFI alatt (SecureBoot az kell hozzá, ugye; de beépülő nem)
OpenBSD
- BIOS alatt (saját beépülővel)
(UEFI-s bootolót nem találtam a miniroot74.img-ben, mindössze két fájl van a boot partíción, "boot" és "bsd", de elvileg csont nélkül mennie kell)
FreeBSD
- BIOS alatt (saját beépülővel)
- UEFI alatt (loader.efi-t hívva, beépülő nélkül)
FreeDOS
- BIOS alatt (saját beépülővel)
(UEFI-t maga a DOS nem támogatja)
Egyszerűsített Multiboot2 protokoll a könnyebb hobby OS kernel íráshoz:
- ELF64 / PE32+ (BIOS, UEFI és RPi, beépülő nélkül)
- ELF32 (BIOS, UEFI, védett módban indul)
- a.out (BIOS, UEFI, védett módban indul)
- bővített Multiboot2 lista (pl. átadja az EDID infót is, ami az eredeti specben nem szerepel)
- nincs szükség beágyazott bináris marhaságra (ELF, PE, a.out fejlécet értelmezi oszt jóccakát')
- tisztán 64-bites kernel belépési pont (nincs szükség trampoline kódra, mint a GRUB esetén)
- ha a kernel az indulása korai szakaszában elszállna, akkor részletes és értelmes hibaüzenet ad (kerneltől függetlenül működik, már amíg a kernel be nem állítja az IDT-t/VBAR-t)
- képes a kernelt minden processzormagon egyszerre elindítani (SMP-t nem tud a GRUB, de az Easyboot igen ;-P)
- ha kell, akkor van egy beépülő a GRUB szimulálására, annak összes nyűgjével, így olyan kernelek is betölthetők, amik esetleg GRUB bugra támaszkodnának
Érdekességek
BSD-k esetében úgy döntöttem, hogy a betöltőnél kapcsolódok be, és nem direktben a kernelnél. Ennek több előnye is van: egyrészről így müködnek a boot szkriptek (Lua és társai), a sokféle konfiguráció a különféle modulokkal és akkor sincs gáz, ha változna a kernel dinamikus linkelése. Továbbá így csont nélkül támogatott nemcsak az UFS-ről, de a ZFS-ről való bootolás is.
UEFI esetében külön gond volt, hogy még a referencia TianoCore sem felel meg a szabványnak. Az azt írja ugyanis, hogy a DevPath elhagyható, ha bufferből töltődik be a futtatható, pedig valójában nem is, nemcsakhogy kötelező megadni, de érvényesnek is kell lennie, különben nem indul el az UEFI App. Szóval szívtam egy sort ezzel: ha a kernel a boot partícióról töltődik be, akkor nincs gond, átadom, amit én is kaptam, viszont ha root partíció lett megadva, akkor nekem kell összerakni a hozzá tartozó DevPath-ot; továbbá ha valami miatt nem sikerülne lekérni, akkor is át kell adnom valami érvényes DevPath-ot (ilyenkor a fallback az, hogy egy memory-mapped pathot generálok).
További újjítás a Simpleboot-hoz képest, hogy az ikonok immáron tartalmazhatnak alfa csatornát (pixelenként különböző átlátszóság). Ez azért érdekes, mert a háttérszín dinamikusan állítható. Itt meg abba futottam bele, az ImageMagick nem tudott alfa csatornát menteni TGA esetén, az új GIMP meg bugos lett és már nem képes rá (régen tudta, de már elmúlt). A megoldás az lett, hogy leimplementáltam ImageMagick-be (már beolvasztották, ha letöltitek a legfrissebb verziót, az már tudni fogja). Szóval convert (bármilyen kép) -colors 256 -compress RLE ikon.tga, és ha az eredeti képben volt alfa csatorna, akkor a végeredmény TGA-ban is lesz.
Felkészülnek
A fájl rendszer támogató beépülők (ext, ufs), hogy a kerneleket ne csak a boot partícióról, de közvetlenül a root partícióról is képes legyen betölteni.
Igazából már ezek is elkészültek, de sajnos belefutottam egy csúnya Clang fordító bugba, egyelőre még nem találtam rá kerülőmegoldást, de még nyomozok. A gond konkrétan az, hogy hiába használ pozíciórelatív címzési módot az x86_64, és hiába adom át az "-fno-plt" kapcsolót neki, mégis generál PLT-ket és PLT relokációkat szimpla statikus, lokális függvényhívásokhoz. Érdekes módon csak azokhoz, és ott sem mindig, a futásidőben dinamikusan linkelt függvények (ahol még lenne is értelme a PLT-nek) ellenben jól működnek, helyes, PLT nélküli relokációk generálódnak hozzá. Ez azért para, mert fájlrendszer beépülők esetében mindenképp szükséges pár dolgot helyi függvényekbe kiszervezni. (Megj: ARM alatt nincs gond, ott figyelembe veszi a "-fno-plt" kapcsolót a Clang fordító.)
Szóval a fájlrendszer beépülők jelenleg csak gcc keresztfordítóval fordíthatók emiatt, az alapértelmezett Clang-gal nem; ezért nem commitoltam még őket.
Szép munka
Kösz! Dobj egy csillagot a repóra, ha tetszik!
Ez a többi HUP-osnak is szól, légyszi! Privát is jó, a lényeg, hogy a sok csillag motíváltabbá tenne a Clang bugok workaroundolásában :-) Előre is kösz!
> Dobj egy csillagot a repóra
nincs gitlab accom. de a kedvedert megprobaltam most regisztralni, de mikor valasztani kellett hogy a telszamom vagy a hitelkartyam adom meg, inkabb elengedtem ezt... amugy miert nem a github-on vagy mint kb mindenki mas?
Micsoda? Tőlem ilyent nem kért, igaz régen regisztráltam. Úgy tudtam ilyen a sima giteléshez nem kell, csak akkor, ha CI-t akarsz futtatni (mert túl sokan éltek vissza vele és kriptobányászatra használták a CI pipeline-t). Elvileg ha nem használsz CI-t, akkor nem kér ilyeneket, tőlem sosem kért.
Voltam, de aztán egyre többször erősködött, hogy adjam meg a telefonszámom vagy telepítsek valami kétes mobilappot. Egyre gyakrabban követelelt verification code-ot is, de azok egyre később érkeztek meg (végefele volt, hogy 1 hét is kellett neki). A legutóbbi ilyennél már meg sem jött a levél, úgyhogy nem is tudok már belépni.
Még jó, hogy már akkor elengedtem, amikor felreppent a hír, hogy az M$ ráteszi a kezét, egyből másik git szolgáltató után néztem. De úgy tűnik, most megint keresnem kell egy újat?
Egyébként kár a githubért, ott volt olyan repóm, amit több, mint háromszázan forkoltak, és több, mint 2500 csillagra tett szert. Történetesen azt is tudom, hogy több egyetemen is tananyag lett belőle (legalábbis három helyről kértek engedélyt tőlem, hogy betegyék, de gondolom ennél többen használják / használták). Alacsony szintű Raspberry Pi programozáshoz oktatóanyag.
> Elvileg ha nem használsz CI-t, akkor nem kér ilyeneket, tőlem sosem kért.
hat most reggelni se lehet nelkule. megprobaltam google logint valasztani, akkor meg kotelezoen letre kell hoznom egy repot, addig nem engedi befejezni a reget. hat megkaptak, legyenek boldogok vele ;)
> Voltam, de aztán egyre többször erősködött, hogy adjam meg a telefonszámom
ezt nekem is elkezdte par hete irogatni, dec 24ig van idom bekapcsolni a 2FA-t naluk. de meg nem foglalkoztam vele...
> telepítsek valami kétes mobilappot.
gondolom barmilyen TOTP jo neki, nem? elvileg egy keepassxc is.
> A legutóbbi ilyennél már meg sem jött a levél
ne lehet ott az email cimmel vmi gond? greylist nem fogja meg? nekem mindenhonnan meg szoktak jonni egybol.
> Egyébként kár a githubért, ott volt olyan repóm,
hat igen, kar erte :(
szerk: beallitottam gh-n a 2FA-t, TOTP keepassxc-vel, tartaleknak sms, es lementettem a recovery keyt is, ha megse mukodne :)
mobil appokat en se szeretem, mert ha elveszik/bedoglik a telo vagy csak lecserelem akkor lehet szopkodni mindennel.
neked nincs meg valahol lementve a github-recovery-codes.txt file amit letolt 2fa beallitaskor? azzal elvileg vissza tudnal jutni.
vagy egy bash script is pl: https://github.com/neutronscott/bash-totp
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
aztaq, ez nagyon durva. meg hogy a bash nem programnyelv :)
ja, bár azért a "This will be a basic OTP manager in pure bash (no external programs ever)" állításnak ellentmondani látszik a kód: https://github.com/neutronscott/bash-totp/blob/6b73886f6083e8c5faefcdbe…
(ami egyébként nem para, csak vicces)
neztem en is, de azert a hmac_sha1() le van implementalva bash-ban! csak a 256 nem, gondolom azt is le lehetne ennyi erovel, csak minek.
Ja, hogy a 'hmac_sha1o()' a kikommentelés helyett van :)
Ugyanígy jártam. Megpróbáltam regisztrálni egy kamucímmel, és írta is, hogy a második lépés a telefonszám megadása lenne, a harmadik a kártyaszámé... Egyébként meg ugyanazt tapasztaltam, mint bzt: én is évekkel ezelőtt regisztráltam, és tőlem azóta sem kértek ilyeneket. (TOTP-s tufám viszont van, nem tudom, ez számít-e. Ja, és csak az ingyenes változatot használom.) Szerintem nagyon gáz, hogy már regisztrációkor kérnek ilyeneket. Újabb ok az örömre, hogy már elsődlegesen Sourcehuton vagyok.
Nekem sikerült regisztrálni, nem kért se telefonszámot, se hitelkártyát, mondjuk privátra raktam a regisztrációt, meg hogy ismerkednék vele, a legutolsó lépés után egy 404 fogadott, egy nagyon is magyaros url-el:
https://pasteboard.co/C1q23ocwyQjn.png
:)
Szerk: ment a csillag is a repora.
LOL! És köszönöm!
Megtettem.
Egy kis bosszankodás, mert muszáj kiírnom magamból. Nyugodtan át lehet ugrani, semmi fontos.
Mivel már számtalan boot protokollt támogatok (időközben bekerült a Multiboot 0.6.96 a Haiku és a SerenityOS miatt és a KolibriOS BOOT_LO-ja is), ezért úgy gondoltam, ránézek most már a stivale2-re, amit állítólag a Multiboot2 utódának szántak. Hát nagyon nem lett az, kevés ennél elbaszottabb dologgal találkoztam.
<mérgelődés>
Először is, valahonnan tudnod kéne, hogy a kernel fejléce érvénytelen (bár valós ELF SysV-nek látszik, és semmi, de semmi nem jelzi hogy mégsem az). Multiboot alatt ugye a fájl elején az első 32k-ban kell lennie egy mágikus bájtsornak, amivel detektálhatod, na itt semmi ilyesmi nincs.
Aztán meg, miután beolvastad a fájl elejét és értelmezted az ELF fejlécet, be kell olvasni a fájl legvégéről a szekció fejléceket, majd pedig be kell olvasni a fájl kellős közepéről a szekciókat magukat is, csakhogy eldönthesd, ezt a protokollt használja-e a kernel, vagy esetleg mégiscsak érvényes a fejléce. Mégegyszer, azt, hogy mindezt meg kéne tenni, semmi, de semmi nem jelzi, ha mindezt végigszoptad, csak akkor fog kiderülni, hogy totál felesleges volt-e, emiatt az összes többi boot protokoll detektálását is lelassítja (!!!).
Arról nem is beszélve, hogy az ELF specifikáció szerint a betöltőknek NEM szabad a szekciókkal foglalkozniuk (az ugyanis a Linking View), hanem csakis a program fejlécben szerepelő szegmensekkel (Program View). Szóval ez az egész szekciósdi egy olyan plusz tehret ró a betöltőre, amit semmilyen más protokoll, de még maga az ELF ABI sem követel meg, a szekciókezelést csakis emiatt az egy protokoll miatt kellene implementálni...
És akkor a szekció tartalmáról magáról még nem is beszéltem, CGA text mód (komolyan, a XXI században?) meg hogy a szigorúan x86-only x2APIC platformfüggetlen lenne... Mindez tele pointerekellel (igen, jól olvastátok, nem fájlpozíciókat tárol, hanem memóriacímeket, szóval ágyő relokálható kernel.) ROTFL!
Biztonság? Felejtsd el! Ez a boot protokoll elvárja, hogy a betöltő kódot injektáljon a kernelbe, amit aztán annak a lehető legmagasabb privilégiumi szinten kéne futtatnia, mert hát mi baj lehet belőle, ugye...? Normális????
Mégis, mekkora hozzá nem értő idiótának kell lenni ahhoz, hogy egy ennyire elcseszett megoldással rukkoljon elő valaki? Mintha direkt mindenből a lehető legrosszabb, legesleg erőforrásigényesebb, extra kódot követelő megoldásokat copy'n'pastelte volna össze agyatlan módon. Hát én nem fogom emiatt szétcseszni a kódom, az egyszer hótbiztos!
Ajh, de nagy az isten állatkertje! Hát az IQ teszted? Hálistennek negatív lett!
</mérgelődés>
helyedben leírnám ezeket a doksiban és hozzá tenném, h próbáltad, de ezek és ezek a pontok miatt nem vagy hajlandó támogatni.
szerintem ez korrekt
En csinalnek egy "Why not..." szekciot a doksiban es ott leirnam de nem csak egy ket potban hanem reszletesen. Majd a fejlesztok tudnak ra reagalni ha akarnak
Ezt túlzásnak érzem, tekintve, hogy ez az egyetlen dolog, amit tuti biztos nem fogok támogatni. Minden más frankón működik.
Hogy klasszikust idézzek:
- Beleszarjak a zongorába?
- Ezeknek minek? Úgyse értenék!
Azért figyelmeztetés gyanánt raktam egy szösszenetet a doksiba róla, de a részletek nélkül. Aki egy kicsit is konyít a témához, annak ennyiből világos, hogy ezt kerülni kell, mint a leprát.
Majd ha azok a gyík stivale fejlesztők jó bőségesen megfizetnek érte, akkor talán részletesen is kifejtem nekik, példákkal és PoC-al, hogy miért is balfaszok. De addig minek?
És... dobpergés... tádám! Elkészült a második mérföldkő is! Ezáltal az FSF.hu Szabad Szoftver Pályázat 2023-ra megígért célok mind teljesítésre kerültek.
Felraktam letölthető bináris formában is, elérhető Windows, Linux (sima tgz), Ubuntu és RaspiOS (deb) formában. Természetesen van Gentoo és Arch package fájl is hozzá.
De ez nem azt jelenti, hogy innentől hanyagolnám a projektet! Továbbra is tervezem újabb beépülők gyártását hozzá, meg hát ha valaki belefut valami hibába, jelezze és ha reprodukálni tudom, javítom!
Fájlrendszer pluginok:
- FAT12/16 (eddig csak FAT32-t tudta, most már mindet)
- Minix3 fájlrendszer (ehhez csináltam egy külön oldalt is, mert botrányosan szarul van dokumentálva, pedig sokkal jobb, mint a FAT)
- ext2/3/4 (csomó feature támogatva van, pl. flex groupok, inlined adatok, extentek, hashfák, 64 bites címek, változó inode és descriptor méretek stb.; kábé ami nincs, az a meta bg, tömörítés és titkosítás, minden más van)
Tervben van még: UFS és NTFS, de ehhez nem tudok időt mondani, mert rohamosan közeleg a karácsony.
ext2/3/4: gratula, nem semmi. par eve en is irtam ext-valamelyikhez egy adatmentesi projekt miatt de nagyon nem egyszeru a felepites (pl. extentek miatt) es sok opcionalis feature van amit le kell kezelni...
ntfs: iden nyaron ahhoz is irtam, foleg a tomoritett fileok kezelese nagyon trukkos tud lenni, bar azt nem hiszem hogy neked erdemes tamogatni. anelkul nem akkora gaz azert. Inkabb a filenevek kezelese (tarolja ugyanahhoz a filehoz tobbfele namespeceben, pl. dos 8.3 filenevek, win32 utf16-ban, posix stb - de persze opcionalisak igy hol csak egyik hol masik hol tobbfele is van), es a nagyon pici fileok amit beepit az mft-be, illetev a nagyon nagy fileok (bar ez sztem csak a tomoritesnel vagy eros fragmentalodasnal jon elo) ami tobb MFT blokkbol all (mivel egyben nem fer el az osszes cluster-pozicio) es az elso MFT referenciakat tartalmaz a tobbire.
meg amivel en rengeteget szivtam, hogy az MFT szektorok (512 byteos blokkok) utolso 2 bytejat lecsereli egy checksumra, es azt vissza kell patchelni (az MFT elejen a fixup bytes resz) mielott parsolod az MFT-t. ez valahogy az ntfs doksikbol kimaradt :(
https://dtidatarecovery.com/ntfs-master-file-table-fixup/
Ja, az extentekkel én is szívtam (Tso bácsi biztos sokat csuklott miattam), amíg rá nem bukkantam erre. Ebből a leírásból egyértelművé vált, hogy bár fának hívják, rohadtul nem is fa (egy fa esetében ugyanis az fájloffszet bitjei alapján lehetne kiválasztani a részfákat, na itt semmi ilyesmi nincs). Miután tisztázódott, hogy ez csak egy túlbonyolított lista, amit csak O(n) alatt lehet bejárni, meglett pár sorból az egész (mindössze 16 SLoC).
Jajj, de jó, egy szakértő!!! Nem bánod, ha kérdezek párat? Van egy-két dolog, amit sehonnan nem bírok kihámozni (néztem itt, itt meg itt is, de nem derült ki).
1. Szóval fogom a boot szektort, abból kiolvasom a kluszter méretét meg az mft kezdő kluszterét.
2. Beolvasom innen az első klusztert
3. fogom a legelső MFT rekordban (ami önmagára az MFT-re mutat) megkeresem a $DATA attríbutomot, amiből kihámozom azt a kluszterlistát, hogy az MFT-t hol tárolódik a diszken.
4. miután megvan ez a kluszterlista, azt használva egy folyamatos, összefüggő bitkolbászként láthatom az egész MFT-t, mintha egy fájl tartalma lenne.
Na és innentől nem világos. Hogy találom meg az N.-dik MFT rekordot? Teszem azt a gyökérkönyvtár fid-je 5, tehát az 5. MFT rekordot? Használható erre a boot szektor beli MFT rekord méret (N * boot_mft_entry_size) mint fájloffszet? De ha ez így van, akkor meg miért van minden MFT rekord fejlécében tárolva a mérete? Lehet, hogy muszáj végigiterálni, for(i = offs = 0; i < N; i++, offs += mft->allocated_size);, hogy meglegyen az N. rekordhoz tartozó fájloffszet? Ami tesztet végeztem, ott minden egyes rekordban az allocated_size megegyezett a boot_mft_entry_size-el, na de ez biztos mindig így van?
Ha valamelyik MFT rekord mérete esetleg mégsem a boot szektorban megadott (allocated_size > boot_mft_entry_size), akkor az csak simán folytatólagos, vagy pedig van benne egy újabb MFT header, amiben a fid ugyanaz, mint az előző rekord esetében? (Magyarán igaz az, hogy minden N * boot_mft_entry_size pozíción egy MFT header található, még akkor is, ha több rekord tartozik ugyanahhoz a fidhez?)
Hogy kell listázni egy könyvtárat? Pl. ha a gyökérkönyvtárat akarom kilistázni, akkor fogom az 5. MFT rekordot, dekódolom a $DATA attribútumát, és végigmegyek a tartalmán, vagy pedig az MFT-n kell végigmennem és kikeresni azokat, ahol a $FILENAME attribútumban a parent 5?
És ha már $DATA attribútum, ez mégis hogy tárolja az allokációt? Akármit nézek, a kezdő VCN mindig 0, minden MFT rekordban, mégis hogy derül ki ebből, melyik kluszteren tárolódnak az adatok?
Oh, ez roppant hasznos tanács! Figyelni fogok rá! Ez egyébként csak az MFT adatokra vonatkozik, vagy a fájltartalomra is (ha resident, azaz a fájl tartalma az MFT-ben van)? Vagy lényegtelen, mert csak menjek végig a fixup listán és cseréljem le az értékeket, akármi is az offszetjük, igaz?
> Nem bánod, ha kérdezek párat?
dehogy!
> Használható erre a boot szektor beli MFT rekord méret (N * boot_mft_entry_size) mint fájloffszet?
igen. en legalabbis igy csinalom, mindig stimmelt (sot en egy elso lepesben (persze nekem adatmenetshez kell mindez) kimasolom egy fileba az MFT tartalmat (ritkan van fragmentalva, igy 1-2 dd eleg hozza), es utana mar csak azt a filet parsolom python scripttel :)
arra figyelj hogy az MFT entry size nem mindig 1024 (bar ez a leggyakoribb), es a szektor meret se mindig 512 byte (talalkoztam mar 4k sectormeretu 4TB vinyoval ahol az ntfs is igy szamolta)
> allocated_size megegyezett a boot_mft_entry_size-el, na de ez biztos mindig így van?
biztos a halal, de nekem is mindig egyezett. amugy meg csak annyit kell feldolgozni belole mint az allocated size es kesz :)
> igaz az, hogy minden N * boot_mft_entry_size pozíción egy MFT header található, még akkor is, ha több rekord tartozik ugyanahhoz a fidhez?)
igen. ha nem fer bele egy MFT blokkba egy file osszes adata, akkor tobb MFT blokk lesz, mindegyik sajat headerrel stb (ugyanaz a struktura) de az elso MFT-ben referencia lesz a tobbire (child nodes) es nem a tenyleges file tartalom vcn-ek (runs). erre linkeltem a py implementaciom feljebb, de eleg gany :) de eleg ritka hogy nem fer be egy mft-be, ahhoz nagyon de nagyon fragmentaltnak kell lennie (tobb 100 runs) vagy nagy meretunek es tomoritettnek (mivel akkor minden blokk kulon van megadva).
> Hogy kell listázni egy könyvtárat?
technikailag a konyvtar is csak egy "file" (ugyanugy kell beolvasni mintha file lenne), amiben INDX tipusu (ez a magic az elejen) blokkok vannak, ami az MFT-hez hasonlo (de nem pont ugyanolyan) struktruban tartalmazza a benne levo direntry-ket (nev datum meret stb attribok) es az MFT szamat. igy kell parsolni:
https://github.com/gereoffy/drutils/blob/main/lsindx.py
kb ugyanaz az info van benne mint az MFT-ben, kiveve a tenyleges adat tartalmat (VCN-ek/runs nincs benne).
persze az is jarhato hogy a parent-re szurve vegigmesz az MFT-n, nekem ugye adtamentes miatt hol az MFT hianyzik (ha pl. leformaztak, akkor az 1:1-be felulirodik) hol az INDX hianyzik/serult. ezert en mind2-bol meg tudom mar oldani... csak MFT-bol azert trukkos felepiteni a directory treet, de azert nem veszes
> Ez egyébként csak az MFT adatokra vonatkozik, vagy a fájltartalomra is
az MFT es INDX (konyvtar) rekordokra biztosan vonatkozik, a normal file tartalomra nyilvan nem. ha resident a file akkor persze arra is, de igazabol mar az MFT beolvasasakor meg kell patchelni minden 510.+511. byteot (elvileg miutan ellenorizted a checksumot), es csak utana kezdheted el parsolni, igy mire a resident filehoz ersz mar fixed :)
> Vagy lényegtelen, mert csak menjek végig a fixup listán és cseréljem le az értékeket, akármi is az offszetjük, igaz?
igen. mivel ezt meg az mft parsolasa elott kell megcsinalni, nem is tudhatod hol mi van...
Wow, mennyi hasznos infó!
Jaja, ezt most így számolom ki (az sb->mft_entry_size int8_t, azaz előjeles):
clu_size = sb->bytes_per_sector * sb->sectors_per_cluster_block;mft_entsize = sb->mft_entry_size > 0 ? sb->mft_entry_size * clu_size : 1 << -sb->mft_entry_size;
A hexdumpban 0xF6-nak látom az sb->mft_entry_size-t, és ez így 1024-et köp ki az mft_entsize-ra.
Ezt miért nem bírták beleírni a doksikba? Kösz! Ezek szerint akkor az N * mft_ensize nem járható út, marad a O(N)-es végigjárás, hogy megtaláljuk az N. fidhez tartozó rekordot. Nagyon hasznos tudni, köszönöm!
Ezt azért mellőzném ha lehet. Ezek szerint lehet :-)
Na, akkor már csak azok a fránya VCN-ek nem világosak. Elvileg ha a kezdő nulla, akkor érvényesek a méret adatok az attribútumban, a vége adja meg a run-kódolt kluszterek számát, és a run legelső tagja abszolút kluszterszám, míg a továbbiak relatívek. Ez tiszta. Na de mi van akkor, ha a VCN nem nulla? Ilyennel találkoztál már?
> Jaja, ezt most így számolom ki
sorry ezt passzolom, en sose szamolgattam ki hanem megneztem hexaban szemre mekkora es beleirtam a forrasba :)
> Ezek szerint akkor az N * mft_ensize nem járható út
dehogynem. pont ugy kell. ha egy file tobb MFT blokkbol all akkor tobb fid-je lesz, az elso a "master" a tobbi a child-ek amire a master hivatkozik csak.
nem kell semmit vegigjarni, az id szorozva az mft blokkmerettel az offset az MFT-ben.
> Na de mi van akkor, ha a VCN nem nulla? Ilyennel találkoztál már?
igen, ez az amikor tobb MFT-ben van 1 file, akkor a tovabbi darabokat tartalmazo MFT-kben nem 0 lesz a kezdo.
de amugy talan 4-5 ilyet filet lattam eletemben, eleg ritka dolog, nem hiszem hogy erdemes vele szopnod, foleg hogy ez csak sok gigas tomoritett vagy fragmentalodott fileoknal fordulhat elo (ha kb 100-nal tobb darabbol all, mivel meg egy 512 byteos mft-ben is elfer atlag 100 runs)
Aha, szóval ha teszem azt a 100-as fid egy nagy fájlé, aminek az MFT headerjében az allocated_size = 2048, akkor a következő fid a 102-es, ami fájlnak adható, a 101-es nem használt (nem jelenhet meg directory indexben). Jól értem? Egyébként ha nem, akkor tényleg hagyom a fenébe az egy fájlhoz több MFT rekord is tartozhat dolgot, aki ilyen fájlrendszerről akar bootolni az így járt.
(Itt egyébként nem az a gondom, ha a kernel MFT-je több rekordos lenne, azt semmiképp se kezelném, az aggaszt, mi van, ha egy kissebb fid-jű fájl több rekordos, és utánna jön a kernel MFT-je. Ha jól értem, ez nem para.)
ps: az MFT rekordméret kiszámolást egyébként valamelyik hivatalos doksi lábjegyzetének apróbetűjében találtam meg, és működni látszik.
nem feltetlen a 101 a kovetkezo, bar eleg valoszinu. d eha mondjuk kesobb no a file tovabb, akkor lehet a 101 mar folglalt...
de tokmind1, a 100-as fid mft-jeben benne lesz a referencia a tobbi fid-re amik ugyanehhez a filehoz tartoznak, es azokban mar nem 0 lesz a vcn hanem a file tobbi darabjanak megfelelo.
> Ha jól értem, ez nem para.
jol erted, neked azzal nem kell foglalkozni. ez az egesz csak akkor erdekes, ha a sok giga sfragmentalt/tomoritett filet akarod beolvani.
> MFT rekordméret kiszámolást
hat en hardkodoltam anno 1024-re, es eddig osszesen egy disk eseten kellett atirnom 4096-ra, a tobbinel az 1024 jo volt :)
Baszki, komolyan beleőszülök ebbe a szarba. Minden nyamvadt doksi leírja, hogy az NTFS fájlként tárolja a könyvtárakat, csakhogy ez szemenszedett hazugság. A fájloknak van $DATA streamjük, a könyvtáraknak meg nincs, helyette ezt az agyhalott attribútum indexet használják, tehát NEM igaz az, hogy fájlként lennének tárolva.
És sehogy sem jutok dűlőre vele, akárhogy olvasom a doksikat és bújom a forráskódokat, egyszerűen semmi értelme. Itt akadok el:
Szóval fogom az 5. MFT rekordot (ami elvileg a gyökérkönyvtár), abből kibányászom az $INDEX_ROOT attribútumot. Ezt kapom:
90 00 00 00 58 00 00 00 00 04 18 00 00 00 03 00 ....X...........
38 00 00 00 20 00 00 00 24 00 49 00 33 00 30 00 8... ...$.I.3.0.
30 00 00 00 01 00 00 00 00 10 00 00 01 00 00 00 0...............
10 00 00 00 28 00 00 00 28 00 00 00 01 00 00 00 ....(...(.......
00 00 00 00 00 00 00 00 18 00 00 00 03 00 00 00 ................
00 00 00 00 00 00 00 00 80 5c ab 42 1b 2f da 01 .........\.B./..
80 5c ab 42 1b 2f da 01 80 5c ab 42 1b 2f da 01 .\.B./...\.B./..
06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Menjünk sorról sorra.
1. sor, 5.5.1. MFT attribute header
90 00 00 00 58 00 00 00 00 04 18 00 00 00 03 00 ....X...........
Size: 0x58
Non-resident-flag: 0 (resident)
Name size: 4
Name offset: 0x18
Attribute data flags: 0
Attribute identifier: 3
2. sor, 5.5.2. Resident MFT attribute
38 00 00 00 20 00 00 00 24 00 49 00 33 00 30 00 8... ...$.I.3.0.
Data offset: 0x20
Ezután a parszolást az attrib címe + "Data offset"-nél folytatom, ami jelen esetben a 3. sor. Vagy ezt teljesen rosszul gondolom, és valami egész mást nézek innentől, mint kéne???
3. sor, 8.2. The index root
30 00 00 00 01 00 00 00 00 10 00 00 01 00 00 00 0...............
Collation type: 1
Index entry size: 0x1000
Index entry number of cluster blocks: 1
A libfsntfs forrásából azt hámoztam ki, hogy ezt a root header-t mindig követnie kell egy node headernek (de akkor miért nem része az index root struct-nak?), tehát
4. sor, 8.4. The index node header
10 00 00 00 28 00 00 00 28 00 00 00 01 00 00 00 ....(...(.......
Index node size: 0x28
Allocated index node size: 0x28
Index node flags: 1
Na és itt ezen a ponton kihullik a hajam. A doksi azt írja, hogy "the index node size includes the size of the fix-up values and the alignment padding following it". Ez mégis miről beszél? Az "Index values offset" nem "index value" rekordokra mutat talán (amiben nincs is fix-up)?
Ha jól értelmezem a doksit, akkor most a node header + "Index values offset"-en kell folytatnom, ami jelen esetben az 5. sor.
5. sor, 8.5. The index value
00 00 00 00 00 00 00 00 18 00 00 00 03 00 00 00 ................
Index value size: 0x18
Index key data size: 0
Index value flags: 3
Ebben nincs semmiféle fix-up. És miért van benne MFT fid 0? Ennek semmi értelme. Hogy jön ide az index entry? A 0-ás fid rohadtul az $MFT, és nem egy INDX kezdetű kluszterre mutató valami.
És hogy kapom meg a következő Index value címét? Akárhogy nézem, sehogy sem jön ki.
- Ha a következő index value a struct mérete után jön, akkor a következő soron kezdődik, akkor az megint fid 0, az Index value size meg 0xab5c lenne, ami biztos nem.
- Ha annak ellenére van értéke, hogy nincs is kulcsa (doksi szerint csak akkor tárolódik érték, ha van kulcs is), akkor +0x18, tehát a 6. sor felénél kéne folytatódnia, ami megint nem jó (kizárt, hogy 0x2f1b42ab5c80 egy fid lenne).
- Ha az "Index value flags" & 1 miatt van benne "Sub node Virtual Cluster Number" is (bár a 0x1da2f1b42ab5c80 nem érvényes VCN), akkor a 7. sornál kéne folytatni, aminél a fid 6 lenne, ami még akár jónak is tűnhet, de ugyancsak nem INDX, hanem a kluszter allokációs bitmap, ami kötve hiszem, hogy szerepelnie kéne bármiféle könyvtárlistában.
Szóval WTF? Hogy a herótba kapok egy könyvtárra mutató MFT fid-ből valami értelmes directoryentry szerű fid+filename párokat?
És mi köze az index value-nak az index node-hoz, és hol kerül képbe az index entry???
hu sztem valamit beneztel, ha lesz idom valamikor osszedobok egy listazot. oszinten szolva igy meg sose csinaltam, mert en vegigscannelem az egesz disket (ugye en adatmentesre hasznalom) es az osszes INDX-el kezdodo szektort parsolom mint direntry (hogy a toroltek is meglegyenek). de neked ez nem lenne annyira optimalis ugye, ezert kene az 5-os mft-bol elindulni aztan rekurzivan tovabb, de azt meg nem neztem hogy nez ki pontosan. de amugy runs kell legyen abban is es az azokra a szektorokra/clusterekre kene mutasson amiben az INDX blokkok vannak. az hogy mi a stream neve passz, olyannal en meg csak nem is foglalkozom :)
Ez egészen biztos. A baj az, hogy akárhogy próbálkoztam vele, nem bírtam rájönni, hogy mit. Vagy pedig a doksi hibás, vagy a Linux által gyártott NTFS image, bár ez utóbbiak nem túl valószínűek, sokkal, de sokkal esélyesebb, hogy én néztem be valamit.
Pont ezt nem értem, hogy lesz az $INDEX_ROOT attribútumból cluster run? Még elvi szinten is csak index value-ig sikerült eljutni, de abban sem vagyok biztos, hogy ez így jó. Ezt a részét nem látom sehogy. Őszintén nem értem, miért nincs egy $DATA stream attribjük is, mint a sima fájloknak? Igazán elférne a sok egyéb attribútum mellett.
Mind1, lett helyette MFT parszolósdi (megkeresem azt a rekordot, amiben a $FILE_NAME attribútumban a parent a "current dir", a név meg UCS2-ként stimmel, oszt csók). Ez így most működik, szóval egyelőre jegeltem. Meg hát igazából nem is biztos, hogy érdemes tovább foglalkozni vele, hisz max. 1 - 2 fájlt kell csak kikeresnie, aztán a betöltött kernelben meg már úgyis van rendes NTFS meghajtó.
nem tudom ezek a $IZEK mik amikre hivatkozol, nekem csak ilyen hexa attrib type-jaim vannak :)
szerk: kigugliztam, ezekre gondolsz nyilvan: https://flatcap.github.io/linux-ntfs/ntfs/attributes/index.html
en csak a 0x80 (nalad $DATA) es 0xA0 ($INDEX_ALLOCATION) attribok eseten parsolom a runs-t. gondolom utobbi most az erdekes.
itt igy nez ki az 5-os MFT ami a rootdir:
MFT#5: size=984/1024 offs=0x38 flags=0x3 seq=5 refcnt=1 attr type=0x10 len=96 aflags=0x0000 resident=0 aid=0 start=0x48 name='' attr type=0x20 len=320 aflags=0x0000 resident=0 aid=92 start=0xA8 name='' ATTRlist: type=0x10/size=32 ref=0x5000000000005 (5) vcn=0 id=0 name='' ATTRlist: type=0x30/size=32 ref=0x5000000000005 (5) vcn=0 id=1 name='' ATTRlist: type=0x40/size=32 ref=0x200000000001F (31) vcn=0 id=0 name='' ATTRlist: type=0x50/size=32 ref=0x1000000004A76 (19062) vcn=0 id=0 name='' ATTRlist: type=0x90/size=40 ref=0x5000000000005 (5) vcn=0 id=89 name='$I30' ATTRlist: type=0xA0/size=40 ref=0x5000000000005 (5) vcn=0 id=91 name='$I30' ATTRlist: type=0xB0/size=40 ref=0x5000000000005 (5) vcn=0 id=90 name='$I30' ATTRlist: type=0x100/size=48 ref=0x5000000000005 (5) vcn=0 id=32 name='$TXF_DATA' attr type=0x30 len=96 aflags=0x0000 resident=0 aid=1 start=0x1E8 name='' NAME: 562 1 3 . 5 attr type=0x90 len=184 aflags=0x0001 resident=0 aid=89 start=0x248 name='$I30' attr type=0xA0 len=80 aflags=0x0000 resident=1 aid=91 start=0x300 name='$I30' VCN 0 - 15 (16/16) Size: 65536/65536/65536/0 Name: '.' compr=0 runs.offs=72 (0x338) RUNdata: 41 10 c0 5f c5 01 00 00 RUNlist: [(121702711296, 65536)] attr type=0xB0 len=40 aflags=0x0000 resident=0 aid=90 start=0x350 name='$I30' attr type=0x100 len=104 aflags=0x0000 resident=0 aid=32 start=0x378 name='$TXF_DATA' {'flags': 3, 'c': [], 'd': 0, 'n': '.', 'p': 5}es ha a RUNlist-ben levo poziciorol beolvasod a 65536 byteot (vagy ami a runlistben van) abban 'INDX' kezdetu rekordok lesznek, amik a direntry-ket tartalmazzak. csak ezekkel en nem foglalkozom, mert nekem ugyis kell az osszes file, nem keresgelek.
> miért nincs egy $DATA stream attribjük is, mint a sima fájloknak?
fentiek alapjan van, csak nem a $DATA (0x80), nem is az INDEX_ROOT (0x90) hanem az INDEX_ALLOCATION (0xA0) az ;)
Hát a doksi így híjja eztetet... :-) Meg hát gondoltam ott van alatta a hexdump (egyébként én is jobb szeretem a sima hexa kódokat, nem értem, minek ez a dollárosdi bele, define nincs rá így, az biztos). Mármint azon túl, hogy FILES11 alatt így volt, és a megszokás nagy úr, más okát nem látom.
Felesleges volt, direkt belinkeltem a doksit minegyikhez.
Jaja, nagyon szépen köszönöm a fáradozásodat! Így már minden világos! Ezt azért beleírhatták volna a doksiba... :P Szerintem egyelőre maradok az MFT-s megoldásnál, mert az működik, és ami működik, azt nem piszkáljuk, amíg nem muszáj! De tényleg köszönöm, ezer hála! Ma is okosabb lettem egy kicsivel!
> Felesleges volt, direkt belinkeltem a doksit minegyikhez.
hat a doksi olvasas nem szokasom, csak ha nagyon nem ertek valamit :) es az altalaba a doksiba sincs benne vagy nem egyertelmu...
mondjuk ezek alapjan csoda hogy mukodik a parserem, ami eleg empirikus modon szuletett :)
amugy epp egy olyan ntfs adatmentessel szivok most ahol az mft eleje (kb az elso 8k entry) hianyzik, de a tobbi megvan, igy amit lehet az alapjan allitok helyre, a maradekot pedig photorec futtatas utan (szerencsere nem tul fragmentalt a tartalma) file tipus, meret es datum alapjan heurisztikaval atnevezem az indx-ekbol kinyert direntry-k alapjan. jo moka :)
nagyobb fileok eseten eleg ritka hogy tobb filenak pont ugyanaz a merete, a kicsi ole-vel (doc/xls) van nyug mert azok ugye blokkmerettel szamolnak es igy sok az azonos meretu, viszont abbol ki lehet nyerni a modositas idopontjat es az alapjan sok beazonosithato automatikusan (persze miutan lekezeltem az idozona eltereseket...).
Ez érdekes a projekt szempontjából?
Nem hiszem. Szerintem elég jól levédtem buffer overflow ellen, forrás (ez minden, csak indexed RLE TGA támogatott logóként). A for-ban az l < w * h nézi a kitömörített hosszt, az m < size pedig a bementi buffer túlcsordulást akadályozza meg. A belső while-nál külön le van kezelve, hogy indulásánál a k (csomagméret) nem lehet nulla. De ha valaki mégis hibát talál belle, feltétlen szóljon és javítom!
Mondjuk ha module-ként betöltetsz vele egy képet és átadod azt a kernelnek, hogy jelenítse meg, na az ellen nem véd... Akkor továbbra is fennáll a LogoFAIL, mert a buffer overflow a kernelben keletkezik, nem az Easyboot-ban.
Azt hiszem nevet válthatsz Mr. Bootz-ra :D
// Hocus Pocus, grab the focus
winSetFocus(...)
http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation
Kösz, de sok egyébbel is foglalkozok: font raszterizálás, Blender plugin meg 3D-s JavaScript polyfill írása, videók beágyazása SDL-be, vagy épp adatbázis titkosítás, csakhogy párat említsek. A rendszerbetöltők írása csak mellékes, amolyan szükséges rossz a számomra.
Az igazság az, hogyha az FSF.hu nem ígért volna támogatást hozzá, akkor bele sem vágtam volna ebbe a projektbe, nekem elég a Simpleboot is. Valószínűleg a TirNanoG-on dolgoznék helyette.
Na, felkerültek az újjabb beépülők. Végül is hagytam a fenébe az egész $INDEX_ROOT-ot, helyette közvetlenül az MFT-ből veszem ki (ha a gyökérkönyvtárból kell a fájl, akkor egyszer megy végig rajta, ha alkönyvtárból, akkor kétszer, stb.) Nem túl optimális, de bootnál belefér. Így legalább működik mindenféle NTFS verzióval is.
Meg ha arra jártam, akkor beraktam a BeFS támogatást is, mert mindenképp akartam, hogy tudjon Haiku-t is bootolni.
Kissebb update:
- lett -e kapcsoló, ami hibrid El Torito lemezképet gyárt. Ennek hatására nemcsak USB-ről, diszkről stb. lehet a végeredményt bebootolni, hanem módosítás nélkül ki lehet írni CD-re és EFI CDROM alól is menni fog (ezt egy füst alatt beraktam a Simpleboot-ba is, ott található teszt hozzá, "make eficdrom").
- bekerült az UFS meghajtó, ezzel már régóta adós voltam, tökre kiment a fejemből.
- wyx és Zahy kollégák kérésére (és remélem örömére) lett XFS beépülő. Támogatja a v2/v3-at, illetve pár apró v5 funkciót is (pl. short form directory, extent dir2/dir3, b+tree extents, b+tree dirs, stb.). Elég alaposan kiteszteltem, de azt nem merem állítani, hogy minden lehetséges edge-case-t kipróbáltam volna, hogy megfelelően működik-e.
A binárisokat is frissítettem, ha most letöltitek, akkor már minden újdonság benne lesz.
kosz, megnezzuk majd
influencer kérdezte:
Igen, jól olvasod. Sőt mi több, a BOOTX64.EFI fájlja egy polyglot bináris, azaz pontosan ugyanaz a bináris futtatható BIOS és UEFI gépeken egyaránt.
De nem kell MBR partíciós táblával szívni, azaz a régebbi BIOS-os gépeken is pontosan ugyanazt a GPT partícionált lemezt használhatod egy-az-egyben, mint a legmodernebb UEFI-s gépeken, nincs különbség. Szóval ez jobb, mint vártad, mert GPT-t használ BIOS-on (meg RPi-n) is.
Nem, és bocs, de nem is lesz ilyen opció. Ehhez ugyanis módosítani kéne a partíciós táblát, holott mind a Simpleboot, mind az Easyboot esetén az az alapvető filozófia, hogy a boot folyamat során csak olvasás megengedett, azaz a rendszer nem változhat meg csak attól, hogy elindítasz róla egy oprendszert.
Ettől függetlenül nem lehetlen megoldani, ha implementálod a lemezre írást egy Easyboot beépülőben, és ami módosítja a partíciós táblát és ezáltal elrejti a partíciókat az egyes bootopciók elől, akkor simán menni fog.
Ami az elsődleges partíciók számát illeti, 248-at használhatsz. Első körben bármennyit megengedtem, de az kiverte a biztosítékot néhány BSD kernelnél, ami 1024-ben maximalizálja a partíciók számát. Aztán meg hozzáadtam az opcionális EFI CDROM opciót, ami miatt tovább kellett csökkenteni a partíciók számát, hogy a GPT még véletlenül se ütközzön az El Torito Boot Catalog-gal.
De még ez a többszáz partíció is igazából rohadt sok, én még soha életemben nem használtam 30 partíciónál egyszerre többet még a legelvetemültebb tesztkonfigurációmban sem.
És egy kis igazi nyalánkság bitpornó: mostantól használható BIOS és UEFI nélkül is, direktbe ROM-ba égetve. Ez qemu-n frankón működik, de jó lenne igazi vason is kipróbálni.
Ehhez mindjárt kérném is a HUP-os közösség segítségét, hátha tud valaki segíteni. Pár napja már keresek, de még nem találtam olyan kici óccó kínai mini PC alaplapot (amire kerestem: Mini-ITX / Micro-ITX / Nano-ITX), ami flashelhető és ezen chipset-ek valamelyikét tartalmazza. Sajnos a lista nem épp a legfrissebb, van ugyan egy újabb is, de ezen meg nem szerepelnek a konkrét chip azonosítók, csak a gyártók és a termékcsalád kódja.
Ha minden kötél szakad, akkor azzal is megbékélek, ha ezen a listán nem szerepel az adott alaplap chipset-je, de bejáratott, blob-mentes Linux kernel driver van hozzá. Nem okoz gondot a Linux-os driver portolása, de első körben inkább elkerülném az ezzel járó szívást, szóval ez inkább csak B-terv.
Szóval olyan mini PC-t keresek, ami csak alaplap, ház, stb. nem kell. Nagyon nagy valószínűséggel az első pár próbálkozást el fogom kúrni és brickelem, ezért fontos, hogy olcsó kínai legyen, mert az FSF.hu támogatásból származó büdzsé nem valami sok. (Megj. a legközelebbi találatom eddig ez, de ennek húzós az ára, mert komplett gép mindenestül, nemcsak egy alaplap.)
dual biosos desktop lap nem jatszik? akkor nem brickeled legalabb...
Nem igazán, mert igaz, hogy nem brickelem, de PoC-nak nem jó. Valami ilyesmiben gondolkodtam egyébként (ha jól látom, ennek pont ugyanaz a specifikációja, mint Star Labs-é, csak épp kb. negyede csak az ára...)
https://www.aliexpress.com/item/1005006017107552.html?algo_pvid=e0c5670…
Viszont ez is dobozos, csili-vili mindennel, házzal stb., nekem csak az alaplap kéne úgy pőrén, még olcsóbban. Táp meg ram jöhet hozzá, más nem kell. De mivel ezek már mind usb-c táposok, talán még a táp is elhagyható, és ramot is tudok külön venni.
Egy ilyennek az alaplapját tudok küldeni:
https://www.dhgate.com/product/fanless-mini-pc-intel-celeron-n2810-dual…
„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)
Hát nemtom'. Ez sem csak alaplap, és semmit sem találtam a linkelt oldalon a chipsetjéről, így azt sem tudom, támogatott-e egyáltalán (ráadásul drágább is, mint az aliexpresses). Ha felajánlásnak szántad, akkor azt nagyon szépen köszönöm, de nekem most egy konkrét rendelhető típusra lenne szükségem, amiből PoC-ot csinálhatok. (Egy alaplap nem elég, reprodukálható eredményre van szükségem.)
Haswell chipset. Ez is az aliról van csak megsérült a háza.
https://www.aliexpress.com/item/32764964322.html
Felajánlásnak szántam.
„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)
Ez esetben nagyon szépen köszönöm, de nekem kifejezetten egy rendelhető alaplapra lenne szükségem, amihez PoC-ot csinálhatok. Abba nem igazán írhatok olyant, hogy működik, mert egyszer valaki adott valamit amire sikerült már feltenni, ugyanis az nem megismételhető. Ráadásul mivel még sosem csináltam ilyent, egész biztos, hogy az első pár próbálkozást el fogom szúrni, szóval csak menne a vasad a levesbe, én meg - egyedi vas lévén - nem tudnám megismtéleni a lépéseket és kitalálni, hogy mit rontottam el.
Ha már itt emlegetve vagyunk, kérnék egy választ a levélre, amit küldtem neked.
Hát, látod, látod! Ha odafigyeltél volna, amikor direkt kifejezetten kértem, hogy milyen levelezési címet használj, akkor nemcsak velem nem szúrtál volna ki, hanem a választ is tudnád. Maradjunk annyiban, hogy ezt már tavaly novemberben megválaszoltam Neked.
Többen is próbáljuk folyamatosan felvenni veled a kapcsolatot privát üzenetben, e-mailben, sőt még issue-t is nyitottam, de semmi választ nem kaptunk. Az a szomorú, hogy nem csak magaddal szórsz ki, mert nem tudjuk elküldeni az adóbevalláshoz szükséges dokumentumaidat, hanem a többiekkel is, mert a könyvelő addig nem tudja beküldeni senki más bevallását, amíg hiányos az adat. Kérlek, hogy azonnal küldd el nekünk édesanyád nevét!
Na itt azért álljunk már meg egy szóra, én nem szúrok ki senkivel, Ti szúrtok ki saját magatokkal és mindenki mással.
Ezt már számtalanszor megtettem, először a
- szerződéses adatok kérésre írt válaszlevelemben (
Date: Tue, 10 Oct 2023 12:19:13 +0200, Message-ID: <CADYoBw0UAi83fi8j8gA=Jw2R_Fh_v9rFXvuT_vp7UGsh3_7vcA@mail.gmail.com>),- aztán ismét (
Date: Mon, 16 Oct 2023 14:08:23 +0200, Message-ID: <CADYoBw01sJK5Q2CaEbi60=15tvZ7FuVCpWZpV0=+fsPo_B9Vmg@mail.gmail.com>),- aztán újfent (
Date: Thu, 14 Dec 2023 11:58:14 +0100, Message-ID: <CADYoBw24AtvQKonF-pqFm7PmM3in7YvM+1ynvFXzf1mRKWrpDg@mail.gmail.com>).Már megbocsáss, nem szándékozom vádaskodni, de még arra sem vettétek a fáradságot, hogy a megadott postacímre küldjétek a szerződést, pedig direkt kértem, emiatt az hetekig kavargott a postán, és csupán csak a vakszerencsén múlt, hogy végül egy ismerős postás kezébe került és egyáltalán kézbesítve lett.
Az igazán szomorú az, hogy most meg itt háborogtok, hogy nem adtam meg édesanyám nevét, holott valójában több alkalommal is megírtam már nektek. Ez a Ti saratok, én megtettem, amit megkövetelt a haza.
Bocs, hogy mellément a levél, de ne haragudj, ez a gyerekes dac nevetséges. Átnéztem a levelezést, nyilván nem viccből spamellek már egy ideje. Az anyja neve értelemszerűen a leánykori nevét jelenti, ezt kérik mindenhol. A születési dátum meg szintén év, hónap, nap. Légy szíves küldd el ezt a két adatot nekem, és akkor nincs szükség további szájtépésre.
NEVETSÉGES? Felfogod egyáltalán, hogy a hibátokból simán rossz kezekbe kerülhetett volna az a levél, benne az ÖSSZES személyes adatommal?
Akkor is nevetségesnek tartanád, ha megkeresne a rendőrség azzal, hogy valakik a nevedben hitelszámlákat nyitottak az ország másik végén? Ez konkrétan megtörtént velem, és telefonban győzködtem a rendőrt, hogy higgye már el, én a telefon túlsó végén vagyok, nem náluk... Viccesnek hangzik? Hát kurvára nem volt az. El kellett utaznom az ország másik végébe, hogy elhiggyék végre, az, akivel telefonon beszéltek, meg az, aki náluk előzetesben ül, na az két különböző ember... Hát bocs, de azóta kifejezetten háklis vagyok a személyes adataim védelmére, és bocs, de rohadtul nem érdekel, ha gyerekes dacnak képzeled.
Aligha nézted át, mert akkor tudnád. Nem viccből mondom már sokadszorra, hogy megírtam. IGEN, a leánykori nevét, mivel anyám doktor, így a leánykori nevét használja, elébiggyesztve, hogy Valakiné. De persze ezt is tudnád, ha valóban átnézted volna a levelezést.
Tessék elolvasni a leveleket, és kérlek szépen hagyjátok abba a spammelést. Köszönöm!
Találtam egy bugot.
A hiba az volt, ha több modul is meg volt adva, amiből nem az utolsó tömörített volt, akkor a következő felülírta az előző végét, mert véletlenül rosszul állítottam be a kicsomagolt mérettel növelt következő modul mutatót (a kernelnek átadott hossz helyes volt). Eddig nem tűnt fel, mert az esetek 99.99999%-ban csak egyetlen egy initrd modul van megadva (mindegy, hogy tömörített vagy sem), de most kibukott és javítva lett.
A Simpleboot nem volt érintett, mert ott csak a zlib támogatott, ami meg úgy működik, hogy előbb lekérem a kicsomagolt méretet, a következő szabad hely plusz ennyire töltöm be a betömörített modult, majd kicsomagolás után ez utóbbi memória továbbra is szabadnak lesz jelezve. Easyboot alatt kicsit körülményesebb a dolog, mert ott beépülők is támogatva vannak, emiatt nem mindig tudható a kicsomagolt modul mérete előre (számos formátum ugyanis nem tárolja ezt, csak kicsomagolás végeztével derül ki, mennyi is az annyi).
Nézegettem a pluginokat, érdekelne, tud-e GRUB-hoz hasonlóan ISO-t mountolni és bootolni.
Mire szeretném használni: van egy kis partició a pendriveon, rajta a bootloader, ami moutolja a nagyobb particiót (exFAT pl.) és rajta lévő ISO-król be tudom bootolni a Linux/Windows telepítőket. Lehetséges ez most?
Köszi!
a'la ventoy?
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Pontosan, csak ahelyett ezt használnám :-)
Mert a Ventoy-jal mi a bajod?
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Semmi bajom nincs vele, használom és jó cucc. De megnéztem a repójukat, gusztustalan az egész telehányva binárisokkal, GUI kódokkal és csomó más bloattal. Ez egy sokkal karcsúbb alternatíva lenne a feladatra és szívesebben használnám helyette.
Üdv!
Érdekes felvetés!
Ez pontosan így működik Easyboot alatt...
...viszont a nagyobb partícióról a kernelt próbálja betölteni.
Magyarán ehhez egy kernel beépülőre lenne szükség, ami képes értelmezni az ISO-t, mintha az egy kernel lenne. Nem lehetetlen feladat, de nem kicsi: ugyanis a teljes boot folyamatot le kell duplikálni hozzá a beépülőben. Ha csak EFI-t kell támogatni, akkor egyszerűbb a dolog, de ha általános ISO bootolás a cél, az nem kis fejsze.
Amennyiben megfelel az EFI, akkor a beépülőben a következő lépések szükségesek (részben magamnak is jegyzetelek, meg informatív is):
1. meg kell keresni a betöltött ISO El Torito Boot Catalog-jában az EFI partíció kezdő címét
2. valahogy el kell távolítani a már meglévő FS0: mappelést az EFI-ben, és lecserélni erre, memdisk-es MediaPath-al
3. végig kell járni a BootOrder-ben megadott fájlneveket, és a legelsőt, ami van, betölteni erről az új FS0:-ról LoadImage-el
4. átadni a vezérlést rá StartImage-el
Ami a szopás részét adja, hogy mindezt Secure Boot-al nehezített pályán kell megtenni, márha Windows bootolás a cél. (Ennek sajnos nem kevés API oldali függősége is van, értelme ellenben nem sok).
Még pár dolog, ami eszembe jutott: mintha a Secure Boot nem szeretné a memdisk-et. Ha az ISO-k nem fájlokban vannak, hanem partíciókon, az probléma? Ilyenkor egyszerűbb lenne a dolog, mert biztos töredezettmentesek az ISO-k ha partíciók, és elég csak a MediaPath kezdő- és végszektor számát átírni a cseréhez, és így a Secure Boot is biztos szeretni fogja. Ez esetben mondjuk fájlrendszer beépülőt kell írni, és nem kernel beépülőt.
Legacy boot hiánya szerintem (pontosabban nekem) nem probléma.
Kényelmesebb lenne ha fájlokban vannak, de ha már particiókról be tudnék bootolni vele az is jó lenne :-)
Amit leírsz probléma valóban elég körülményesnek hangzik. Még mielőtt ide írtam, keresgéltem egy kicsit és szembejött az EFI_LOAD_FILE_PROTOCOL meg egy ISO9960 fájlrendszer támogatás. De ezzel az ISO9960 támogatással is az lenne amit írsz, hogy át kéne adni a vezérlést a startimage-re valószínűleg.
Fogom figyelni a threadet, ha van ebben az irányban bármi aktivitás szívesen segítek tesztelni.
Ez tény, de ilyenkor töredezett lehet az ISO. Jelenleg a nagyobb partícióról a megadott fájlt teljes egészében betöltöm a memóriába, ez gondját viseli a tördezettségnek, meg még tömörített fájlokat is lekezeli, viszont valahol azt olvastam, hogy memóriából nem működik a Secure Boot. Ennek jobban utánna kell járnom. Ha nem sír be a memdisk-re a Secure Boot, akkor nincs gond, ha fájlokban van. Ha besír, akkor kell alternatív megoldások után nézni.
A meglévő FS0 mappelést és a MediaPath-ot azért kell lecserélni, hogy az ISO-n lévő programok is tudják használni az EFI_LOAD_FILE_PROTOCOL-t.
Az EFI-s ISO9660 sajnos használhatatlan (az még elméletben is csak akkor működne, ha az egész EFI_BLOCK_IO_PROTOCOL-os eszközön detekálja a formátumot, de igazából nekem még sosem működött TianoCore-al). És itt egyébként is partíciókról vagy fájlokról van szó, tehát nem a teljes eszközről, szóval még elméletileg sem működhetne, ezt mindenképp implementálni kell. Annyira nem vészes, mert igazából csak az ESP kezdőszektorát kell kihalászni belőle, az ISO9660-ás fájlokat egyáltalán nem is használja: To boot from a CD-ROM or DVD-ROM in the boot services environment, an EFI System partition is stored in a “no emulation” mode as defined by the “El Torito” specification. [...] EFI interprets the “no emulation” image as an EFI system partition, valamint The file system supported by the Extensible Firmware Interface is based on the FAT file system.
Ezt az ISO partíción van részt úgy gondolod, hogy veszem a pendrive-ot, felteszem rá a bootloadert, majd felpartícionálom 8-10-20 partícióra? Csinálok rá 1 gigásat, meg 2 gigásat, meg 4 és 8 gigásat, és aztán az éppen aktuálisan felrakandó ISO függvényében kiválasztom, hogy annak mekkora hely kell, és egy akkora partícióra dd-zem fel az iso-t? És ha nincs megfelelő méretű partíció, akkor a maradék helyből kivágok egy újabbat, és arra dd-zek. Szerintem kissé kényelmetlenebb, mint csinálni egy VFAT-ot (FATx nem jó, mert néhány ISO nem fog felférni a méretkorlát miatt) / EXT2-t (szerintem ehhez naplózás tök fölösleges, és kb minden OS-en lehet ma már írni / olvasni ), és simán feldobálni az éppen szükségesnek gondolt ISO-kat. De ha a megvalósítása ennek egyszerűbb, akkor hajrá. Ez kb olyan mint a chainloader egyéb boot szoftverekben, ha jól gondolom.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Valahogy így:
1. partíció: EFI System Partition a betöltővel
2. partíció: Linux telepítő ISO
3. partíció: Windows telepítő ISO
4. partíció: FreeBSD telepítő ISO
5. partíció: ...
Ja, nem. Az easyboot tool már most is létrehozza az ESP-t és felpakolja rá a betöltő fájljait, valamint a -r kapcsolóval hozzáad egy root fájlrendszer partíciót. Ezt bővíteném csak ki annyival, hogy a több partíció is megadható lehessen, szóval nem kell méretekkel szívni, csak fel kell sorolni az ISO képfájlokat, az easyboot telepítője megoldaná a többit. Csináltam már ilyent, ott egy JSON fájl "partitions" tömbjében kellett felsorolni a képfájlokat, valami hasonlóra gondoltam itt is. Vagy egy kapcsoló és konfigfájl, vagy pedig egyszerűen többször megadható lenne a mostani -r kapcsoló a parancssorban.
Ez tény, viszont ilyenkor ha fájlokban vannak az ISO-k, akkor töredezettek lehetnek. Ezt az EFI nem kezeli. A mostani megoldás erre az, hogy betöltöm az egész fájlt egy szép, egybefüggő memóriaterületre. Ez menne ISO-val is, lenne belőle egy memdisk, azzal nincs baja az EFI-nek (viszont nagyon úgy rémlik, hogy a Secure Boot-nak igen, de ezt még alaposan körbe kell járni).
Alternatívának javasoltam a partíciókat, mert akkor tutira töredezettségmentes marad minden ISO, továbbá a MediaPath így néz ni: (ACPI eszköz)(PCI eszköz)(diszk specifikáció)(partíció kezdőcím, végecím). Namost ha ebben csupán csak a legutolsó tagban lecserélem a szektorcímeket (partíció kezdőcíme helyett lesz partíció kezdőcíme + El Torito Boot Catalog EFI bejegyzés "no emulation" image kezdőcíme), akkor igazából továbbra is egy lemezes Path marad, szóval 1000%, hogy továbbra is megeszi a Secure Boot. Na meg ilyenkor gyorsabb is lenne a bootolás, mert nem kéne a teljes ISO-t betölteni, csak pár szektort, amíg a kezdő szektorcímet kihámozom.
Jobban belegondolva, ha maguk a telepítők viszont használnák az ISO9660-os fájlokat, nemcsak az ESP-n lévő fájlokat, akkor egyik sem jó megoldás. Akkor az egyetlen lehetőség, ha csinálok egy EFI eszközmeghajtó programot, ami EFI_BLOCK_IO-nak látszik, átkonvertálja a szektorcímeket, majd továbbpasszolja az eredeti EFI_BLOCK_IO eszköznek, a visszatérési értéket meg változatlanul visszaadja. Ezzel meg csak az a baj, hogy nem tiszta, hogy lehet ezt a MediaPath-ba belehekkelni, hogy amikor az ISO-n lévő program az EFI_LOAD_FILE_PROTOCOL-t hívja, akkor ezt a blokkeszközmeghajtót használja, és ne az eredetit.
Na, ez most fecsigázta az érdeklődésemet, megnézem már, a GRUB hogy oldotta meg ezt!
Továbbgondolva: Annyit még jó lenne, ha lenne valami *nagyon* *egyszerű* megoldás arra, hogy
- ls: azaz láthassam, hogy milyen ISO-k vannak "felrakva" a pendrive-ra, hogy el tudjam dönteni, hogy kell-e frissítenem, vagy éppen hiányzik-e a szerszámosládából valami
- valami overwrite / append mód, hogy ha fent van a FreeBSD-14.0-s ISO, de helyette menjen fel a 14.1, akkor nem kelljen jelen lenni az összes többinek is a cseréhez, illetve ha a lemezen már minden ott van, de hiányzik a 15-ös Slackware, akkor a szabad helyre azt is feltolhassam a többi
közémögéÖtleteim szerintem lennének még :-)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Van, nagyon egyszerű is, úgy hívják, fdisk -l :-)
Ez viszont nagyon nem cél. Ez egy lemezkép készítő, nem a partíciómenedzser. Esetleg egy külön toolt el tudok képzelni rá, de semmiképp sem ebbe a parancsba való ez.
Mondjuk egy GTK-s ablakos csili-vili tool, aminél ha rákattintasz egy partícióra, feldobná az open file modalt, és a partíció méretét meg tartalmát lecserélné a kiválasztott ISO fájléra, vagy valami ilyesmi. Az Easyboot-nak tök mindegy a partíció szerkezet, mert UUID-val hivatkozik a partíciókra, és a GPT-t bootoláskor olvassa be. De még az sem nehéz ügy, hogy ez a tool magától frissítené az első partíción az easyboot/menu.cfg fájlt, partíciónként egy menuentry-t generálva, és akkor lehetne a felületén [-] meg [+] gomb is.
De ez csak ötletelés, előbb mindenképp meg kell oldani magát a bootolást, azaz meg kell előbb még írni az a bizonyos Easyboot beépülőt. Most még csak hozzáadni lehet a partíciókat a lemezkép generáláskor, de nem csinál velük még semmit bootolásnál, ha ISO formátumúak.
Megj: azért az írtó szánalmas, hogy sem az fdisk, sem a gdisk, sem a parted nem képes feltölteni az új partíció tartalmát egy fájlból. Végignéztem a man page-ket, és hirtelen eszembe jutott, miért is van lemezképkészítője az Easyboot-nak...
Na kérem, függetlenül attól, hogy mi lesz a vége ennek az ISOsdinak, átvariáltam a parancssori kapcsolókat kicsit.
A -b szolgál mostantól arra, hogy a boot partíció méretét megadjuk (eddig -p volt).
A -p pedig arra, hogy partíciót adjunk a kigenerált lemezképhez, ez utóbbi kacsoló most már többször is megadható, azaz tetszőleges számú partíciót lehet hozzáadni (eddig -r volt, mint root partíció, és csak egyszer lehetett megadni).
Lett egy új beépülő, a debugger. A bekapcsolásához csak fel kell másolni a boot partícióra az architektúrának megfelelő változatot. Ha egy kernel elszáll, akkor automatikusan meghívódik, és egy interaktív promptot ad a soros vonalon.
Nagy előnye az összes többi debugger megoldással szemben, hogy igazi vason is működik, bármilyen kernellel.
Hátránya, hogy csak minimális (regiszterdump, memóriadump, utasítás diszasszemblálás) funkciókkal bír.
Ha már erre jártam, írtam egy szösszenetet a doksiba a többi debugger használatáról is. Remélem lesz, aki hasznosnak találja, mert végül is más betöltőkhöz is jó.