Simpleboot, a szopásmentes GRUB helyettesítő

Fejlesztés

Egyszer csak telelett a tö... hócipőm azzal, hogy mennyire szar minden Linux kernel betöltő, ha arról van szó, hogy egy indítható lemezképet kell csinálni. Ezért nekiültem, és pár nap alatt írtam egy rendeset.

https://gitlab.com/bztsrc/simpleboot

Ez ad egy parancsot (Linuxon és Windowson egyaránt elérhető), ami hasonló a grub-mkrescue-hoz, csak sokkal egyszerűbb és kényelmesebb használni, és a libc-n kívül az egyégadta világon semmi függősége sincs. Nem kell neki sem mtools, sem xorriso, sem semmilyen függvénykönyvtár és még root jogosultságot sem kér, mint a syslinux-nomtools!

Használata:
simpleboot (bemenő könyvtár) (kimenő lemezkép)

...és ennyi! Az elkészült lemezkép bebootolható virtuális gépen, vagy dd-vel, USBImager-el lemezre írható és valódi gépen is indítható. A lemezképre felmásolódik a megadott könyvtár tartalma, ezen kívül mindössze egyetlen egy plusz fájl kerül fel (nem úgy, mint a grub, ami telepakolja sokmegányi mindenféle szarral a boot partíciót, nálam most "du -hs /boot/grub" azt mondja, 13M).

Ez a fájl annak ellenére, hogy csak 40k, funkcionalitásban simán felveszi a versenyt bármelyik másik boot loader-el:

- egyaránt indítható UEFI-s és BIOS-os gépeken is
- többféle boot protokollt is ismer: Linux/x86 Boot Protocol-t és Multiboot2-t.
- kernel formátuma lehet Linux kernel, ELF32, ELF64, COFF/PE vagy PE32+ is, ezt ráadásul autodetektálja.
- a kernel belépési pontja lehet SysV ABI, Microsoft fastcall ABI és CDECL is (ez is automatikus).
- a kerneleket tisztán 64-bites módban indítja, szóval nem kell többé prot mode - long mode trampoline kóddal szopni, mint a grub esetében.
- mindenki megnyugodhat, bootlogót is képes megjeleníteni!

Ezen túlmenően tud olyant is, amit még a grub és a syslinux sem: betöltést jelző progressbar! Fantasztikus, hol tart ma már a tudomány!

Minta kernelek találhatók itt: https://gitlab.com/bztsrc/simpleboot/-/tree/main/example a teljes dokumentáció meg itt: https://gitlab.com/bztsrc/simpleboot/-/tree/main/docs
A MEG-4 projektemben (aminek van egy bare metal platformja), máris lecseréltem a syslinux-ot simpleboot-ra, szóval már élesben is tesztelve lett és remekül működik!

Kívncsian várom a véleményeiteket,
bzt

( zitev v | 2023. 07. 17., h – 21:13 )

Respect, kivancsi vagyok idovel atfut-e a rendszeren..

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( locsemege v | 2023. 07. 17., h – 23:15 )

Hogyan van ez a bemenő könyvtár, kimenő lemezkép? Hogyan adok meg kernel paramétereket, initram image-et? Valami hevenyészett magyar nyelvű doksit írsz ide? Aztán a Fedora build szerveren miért nincs belőle még csomag? :) Különben kíváncsi vagyok, szóval lehet, hogy valamikor lefordítom forrásból, s kipróbálom, csak csinálj hozzá kedvet! Nem kell halál precíz doksi, csak valami érthető, fontos dolgokat tartalmazó valami jó lenne.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hát én végigfutottam a doksiján, és azt látom, hogy csinálsz egy könyvtárat, amibe 3 fájlt tegyél:

kernel

initrd

simpleboot.cfg

Ez utóbbiba pedig írd bele:

kernel /kernel kparam1 kparam2 kparam3 ...

module /initrd iparam1 iparam2 ...

(meg ha egyéb modulokat akarsz tölteni, akkor azokat is module kezdetű sorral)

és futtasd le

a simpleboot -i initrd /dir outfile parancsot, és kész.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Még a "-i initrd" kapcsoló sem kell. Az csak a default initrd nevét állítja, arra az esetre, ha nem lenne simpleboot.cfg fájl, vagy abban nem lenne "module" sor. Ha van cfg fájl és van benne "module", akkor a default név már tök mindegy, mert úgysem a defaultot használja onnantól.

( locsemege v | 2023. 07. 17., h – 23:22 )

Szerkesztve: 2023. 07. 17., h – 23:35

Egyébként senki sem akart még megverni téged amiatt, hogy egy sorba több utasítást írsz? :) Ezért szerintem kukoricán kellene térdepelned:

while(a > s && a[-1] == ' ') { a--; } *a = 0;

Lehet, így írtam volna:

while (a > s && a[-1] == ' ') a--;
*a = '\0';

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, ízlés kérdése. Abban igazad van, hogy a nagy kódolási módszertanok meg a nagy projektek gyakorlatai azt ajánlják, amit te írsz, hogy lehetőleg minden külön sorban legyen, de a gyakorlatban én is jobbnak látom, ha egy nagy rövid ciklus vagy elágazás csak egyetlen sort foglal el, olvashatóbb, jobban látja az ember az egészét, és nem szaporítja a sorokat feleslegesen.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

a gyakorlatban én is jobbnak látom, ha egy nagy rövid ciklus vagy elágazás csak egyetlen sort foglal el, olvashatóbb, jobban látja az ember az egészét, és nem szaporítja a sorokat feleslegesen

Hat nem tudom, van az eszszerusegnek is hatara. Ezt pl. ugy dobnam vissza code review-n, hogy laba nem erne a foldet:

while (a > s && a[-1] == ' ') a--;

Tok egyszeru benezni refaktoralaskor, de legalabb "nem szaporitottuk a sorokat feleslegesen". :)

Igen, közben rájöttem, hogy ez a nyűgje. Szerintem ez a megoldás valóban veszélyes, ha új sorba van írva, de ha ugyanabba kerül, akkor nincs vele baj. Szerintem ez nem jó:

if (cond)
    statement;

Ellenben ezzel nem látok problémát:

if (cond) statement;

Az első esetben odakerül még egy sor, és kész a baj.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Izebize, ezeket mar reg kitalaltak okos emberek: https://wiki.sei.cmu.edu/confluence/display/c/EXP19-C.+Use+braces+for+t…

Szinte osszes C coding szabvany szerint mindket pelda hibas. A standard pedig nem hiaba szuletett ... Meg lehet nezni hany CVE van hianyzo kapcsos zarojelek miatt :)

konnyen osszetevesztheto hogy az if kifejezesbe tartozik. nyilvan nem az if (a>0) felenel, hanem ahol van egy csomo operator is.

veletlenul ket statement is kerul az if utan, aztan kesz a baj.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

if (((a>0) && (a<1232)) || (((b>12) && (b<323)) || ize(b))) bigyo(a+ 1234 > 4343 ? : a+12, bb);

siman be lehet nezni hogy most akkor a bigyo a kifejezes resze vagy sem. nyilvan nem te, hanem egyszeru kodernek

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

> siman be lehet nezni

dehogy lehet. egyreszt a ) utani bigyorol messzirol sut hogy ott valami veget ert, masreszt minden ide (meg az mcedit is) mutatja a zarojelek parjait.

> hanem egyszeru kodernek

azok maradjanak a php-nel, es ne nyuljanak c-hez, meg foleg ne refaktoraljak azt.

Értem, mire gondolsz. Az nem túl nagy baj, ha a kódot el is olvassa valaki, nem csak elképzeli, mi van odaírva. Amít nagyon könnyű elszúrni, ha valami copy-paste módon keletkezik, de az új helyen nem visszük bele azt a picike módosítást, amit kellene, mondjuk egy offset az indexhez, vagy valami efféle.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az a baj, hogy mindenki magabol indul ki :) Kulonbozo szintu emberek nyulnak a kodhoz, igy szukseg van szabalyokra, best practice-ekre amiket be lehet tartatni, konnyu ellenorizni. Alapvetoen ez lehet egy baj, ha valaki hozzatesz valamit:

if (cond) statement1; statement2;

Ezt te nem szurnad el, de mas igen ...

Na jó, de miért tenne egy sorba két utasítást? Amúgy, ha kiírom a kapcsos zárójelet, azt is törölheti valaki. Ha azt írom, hogy if (*(int8_t *) func(parm1, parm2) == -2), akkor ezt is elronthatja valaki. A *--*p kedvencembe is belerondíthatnak. Csak le kell ültetni egy majmot a kód elé, a napi munkáját fel kell commitolni, aztán meg is vagyunk.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Na jó, de miért tenne egy sorba két utasítást?"

Mondom, hogy mindenki magabol indul ki ... ez hiba! De ertem, hogy nehez elvonatkoztatni :D

Sokminden lehet ... mondjuk mert egy junior? Orul ha egyaltalan lefordul a kodja...

Itt mi tortent: https://embeddedgurus.com/barr-code/2014/03/apples-gotofail-ssl-securit… ?

De stiluson en nem akarok vitatkozni ... csak informaciot kozoltem!

Ha kitorli a bracketeket, akkor azt legalabb a linterek megfogjak, ha ugye cel, hogy betartassanak valami coding szabvanyt...

C-ben az életveszélyes, ha valaki nem érti, mit csinál. Teszem azt, próbálgatással tesz dereferáló * karaktert, vagy címet adó & karaktert valahova, s ha lefordul a kód, akkor úgy érzi, akkor ez úgy jó is. Nem kell a nyelv, a fordító minden képességével tisztában lenni az utolsó betűig, de azt érteni kell, mi az, amit csinál.

Teszem azt, van egy char **s; majd átadja valaki 's' pointert egy memcpy() vagy stpcpy() függvénynek, abból azért lesz baj.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

tisztában lenni az utolsó betűig, de azt érteni kell, mi az, amit csinál

Hahahahah. 5-10% talan erti...

Tetszik, amikor valaki aki opcode szinten vagja mi tortenik (mint te) egy MCU-ban, naivan azt feltetelezi, hogy a legtobb ember is beleteszi az energiat, hogy a-z megertse, hogy mi tortenik :D

Sok programozo egy oprendszert nem tud feltelepiteni a gepere, nemhogy azt vagja, hogy indul el es irjon egy bootoadert ...

Ugyhogy ertem amit irsz, de a valosag sajnos nem ez. Nem, nem erti, hogy mit csinal! De hat kell a munkaero ...

Én nem tanultam hivatalosan soha C-t, de könnyű dolgom volt, mert korábban sokat programoztam assembly-ben, így van rálátásom a memória modellre. Nem esek kétségbe egy uniontól, mert assembly-ben is simán megcsináltam, hogy ugyanazt a területet többféleképpen használtam fel, ha úgy láttam indokltnak. Hasonlóképpen az indirekciók, pointerezések, mikor számít, hogy valami atomikus, s mikor mindegy ez. Mondhatnám, hogy kötelezővé tennék minden programozónak assembly-t valamilyen mikrokontrollerre. Ha az megy, akkor fogja érteni kellő mélységben, hogy mi micsoda.

Persze nem mondom, hogy assembly ismeret nélkül nem lehet megtanulni programozni, de semmiképp sem úgy kell csinálni, hogy írok valami hülyeséget, végig sem gondolom, hogy ez most a változómra mutató pointer, vagy a változómra mutató pointerre mutató pointer, aztán addig írom a csillagokat, amíg egyszer csak lefordul.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igazad van! En is felhaboritonak tartom ... :) Legtobb ember csak takol, ez van. De kellenek a takolo lapatolok is.

Ha mernokok epitenek fel hazakat az eleg draga lenne es talan meg hazak se lennenek...

Igy a kepzett emberek terveznek, ellenoriznek es szabvanyokat, metodologiakat dolgoznak ki es vigyaznak ra, hogy a takolok ne csinaljanak nagy kart.

Egy heterogén programozó csapatban nem az az elvárás, hogy mindenki 100 százalékos legyen - mert ezt lehetetlen megvalósítani -, hanem hogy a csapatmunka minél hatékonyabb legyen. Produktivitás, fenntarthatóság szempontból egyáltalán nem jó, ha valaki félreérthető, nehezen értelmezhető és módosítható kódot produkál.

Egy egyszemélyes, hobbiprojektben azt csinálsz, amit akarsz, de hosszú távon ott is (meg karrier szempontból is) nagy valószínűséggel inkább kiszúrsz magaddal ha nem így csinálod. Már ha valamennyire fontos, amit csinálsz. :)

Ezzel egyetértek, olyannyira, hogy igyekszem érthető változó- és függvényneveket adni, jól olvasható kódot írni, és ami talán ennél is fontosabb, következetes vagyok. Tehát mindenhol ugyanúgy formázom a swittch() case szerkezetet, meg a többit, nem csinálom azt, hogy egyik helyen így, máshol meg úgy.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

igy van.

de most nezd meg business oldalrol is ezt.

egy manager azt latja, hogy a java team-be felvesz junior fizetesert kezdoket, akik alapvetoen kepesek leimplementalni a felmerulo igenyeket. kell egy senior mellejuk, aki a hajat tepi, de egyben tartja a kodbazist kozben.

vs. a c csapat, ahova csupa senior kell, valag penzert, es egymast turjak technikai trivialitasokon (marmint business szempontbol trivialitas; nyilvan a boost vs. stl kurvara nem mindegy :D ).

ehhez vedd hozza, hogy mig junior-t toborozni relative egyszeru, OKJ-s kepzeseken meg egyetemen kitett flyer-ekkel megoldhato olcson, addig senior-t nem fogsz csak ugy felvenni. Vagy sok penzt kinalsz neki (de az csak ideig-oraig tartja meg), vagy erdekes munkat (... az sok-sok lead engineer ora, amig olyan kodbazis lesz, ami alkalmas erre), kulonben elmegy hamar. headhunter meg tipikusan 2 havi berert hoz neked embert (!!! nem vicc, es ez csak az alja !!!). Nem fog neked osszebaszni egy css-t, mert azt mondja, 'nem ert hozza', meg 'spagetti fos a frontend kod, nincs az az isten hogy komplett refaktor nelkul hozzanyuljak'.

 

na, ezert van az, hogy java-t meg hasonlot tolnak mindenhol. c-t csak ott, ahol nincs mas lehetoseg. illetve most jon a rust, amig otvozi a kettot, csak marha kevesen ertik/csinaljak meg.

a c csapat, ahova csupa senior kell, valag penzert, es egymast turjak technikai trivialitasokon

Ez keremszepen "rasszizmus"! :D Java-s osztalyon is turjak egymast ugyanigy!

De ja ertem, ahogy irtam fentebb, kell a lapatolo takolo is, hisz azok csinaljak a penzt, a seniorok valojaban csak viszik...

Mi vele a bajod? Így kellene?

while (a > s && a[-1] == ' ') {
    a--;
}

Vagy az a-- a megütközés tárgya? Mi a jó? --a? a -= 1? Esetleg a = a - 1? Vagy legyen a += ~0LL? Nem próbáltam ki, de szerintem működne.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem értek vele egyet. Ha ilyen van, akkor legyen static inline függvény, amit a fordító az adott helyre be fog tenni, s nem lesz hívás, nem lesz stack művelet. De nem tartom jó iránynak, hogy azért írunk több dolgot egy sorba, mert logikailag összetartozik. Ezzel az erővel komplett függvényeket írhatnánk pontosvesszőkkel szeparálva egyetlen sorba.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Egyébként senki sem akart még megverni téged amiatt, hogy egy sorba több utasítást írsz?

Ingyé csinálom a saját szabdidőmben, ha bárki főnökösdit akarna játszani velem, azt kupánvágom, hogy térjen már észhe', ha meg abból sem ért, akkor kukoricára térdepeltem.

Egyébként meg nincs igazad, csakis azt írom egy sorba, ami logikailag egybe tartozik. A fenti példád konkrétan egy RTRIM, bármelyik részét is vennéd el belőle, már nem lenne működőképes. Szóval az, hogy 132 karakternél tördelem a sorokat nemcsak amiatt van, mert a monitorom sokkal szélesebb, mint magas és mert már a DOS-os időkben is condensed EGA módot használtam; ebben az esetben szemantikai haszna is van.

Nyilván jó a kódod, ízlésekről vitatkozunk. :)

Logikailag egy függvény is egybe tartozik, de csak nem írod az egészet egy sorba.

bármelyik részét is vennéd el belőle, már nem lenne működőképes

Ez akkor is igaz, ha több sorba írod a kódot, nem? :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Ez akkor is igaz, ha több sorba írod a kódot, nem? :)

Ahogy azt Elbandi kolléga demonstrálta https://hup.hu/comment/2943480#comment-2943480 nem. Mivel több sorba volt írva, jól le is felejtette a nullával lezárást, így a define-ja hibás lett.

Egyébként tök más téma, sehol sem találok súgót a poszt formázáshoz (idézetek, linkek stb., amiket próbáltam, HTML, MD, phpBB, stb. egyik sem működik). Biztos kell lennie ilyen oldalnak, csak én vagyok a béna, hogy nem találom, tudnál segíteni? Már nagyon zavar, hogy nem tudok formázni.

Ez egy jQuerys HTML-t dob ki, tele guglis meg klódferes nyomkövető kódokkal, amik meg csúnyán crash-elnek, jpeg képet még véletlenül sem... :-(

curl -sI https://snipboard.io/IA5GF9.jpg | grep content-type
content-type: text/html; charset=utf-8
x-content-type-options: nosniff

Tényleg nincs egy HUP súgó oldal, hogy hogyan kell formázni? Nálam nem jelenik meg semmi a doboz tetején.

nemvolt celom tokeletes define gyartasa, amugy is illik a "tobbsoros" definet egy {} koze rakni.

igazabol amig one-man-show moka van addig tokmind1 milyen a kod, lenyeg hogy a dev ertse. csak amikor mar tobben kezdenek el dolgozni rajta, akkor ajanlott valami standard codestyle hasznalni (vannak is erre jo ellenorozo progik). aztan majd a hackerek megmutatjak miert is hasznos igy csinalni (lasd apple bug)! ;)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ezt nem próbáltam ki. Tényleg így lenne, mert inicializálja az 'a' pointer által mutatott területet egy üres stringgel? Gondolom, ez az ellenszer:

char s[] = "ABC";
char *a;

a = s + 2;

Szerk.: Már kipróbáltam, nem bántja s-et.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem az eredeti jobban tetszik, mert latvanyos, hogy az a-- az sokszor fut le, majd a vegen a *a=0 csupan egyszer, kvazi lezarja a kolto altal gondolt logika veget.

A kapcsok ilyenten valo kirakasa megved a goto fail fele hibaktol, es mivel egy sorba irja a trivialis es logikailag egybetartozo kodot, nem pazarolja feleslegesen a helyet.

Nekem bejon ez a stilus! :-)

A doksi a szukseges rossz, mert megteremti a lehetoseget, hogy elterjen a kodtol, es ezzel dezinformacio keruljon a rendszerbe.

Ezert is (meg mert lusta vagyok es utalok doksit irni) csinaltam az egyik programomat ugy, hogy a konfiguracio bemenet egy xlsx, amit ertelmesen kitoltve es csv -be generalva majd rafuttatva egy generatort letrejon a bash config file. Az excel pedig mar dokumentacionak minosul, mert vannak benne szinek. :-)

ezt csak most csak nektek:

    fsize=read(fd,raw,fsize);
    for(char* q=raw;q<raw+fsize;){
        char* p=q; while(q<raw+fsize && *q!=10) q++; *q++=0;
        if(!username || (!memcmp(p,username,unlen) && p[unlen]==':')){
            for(i=0;i<n && strcmp(db[i],p);i++); if(i>=n) db[n++]=p;
    }   }

( Zahy v | 2023. 07. 18., k – 00:24 )

FreeBSD gyorsteszt :-) :

- a letölthető bináris egy chmod a+x után csont nélkül fut

- és teszi a dolgát

- mint utóbb egy -vv jelzi, nem szereti a FreeBSD gyári kernelt, Multiboot2 high half life-nak (vagy  minek) minősíti

- mindent megcsinál (image), aztán a boot jó lassan betölti a kernelt, újrarajzolja a takeittux bootsplash-t, aztán mintha egy kernel panic lenne, valami hexdump és végtelen ciklusban bootol és hanyattesik.

De mivel deklaráltan nem Linux, gazából már ez is szép. Az külön tetszik, hogy némi CFG-szintaxis ellenőrzés is van benne.

(Érdekes módon nem EFI, hanem MBR módban bootolt ezen a gépen - hasonlót a régebbi FreeBSD bootloader is csinált - az új emlékeim szerint már ment.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> Multiboot2 high half life-nak (vagy minek) minősíti

Nem egészen. Alapból Linux kernel betöltő, ha nem sikerül a kernelt Linuxnak felismerni, akkor minden esetben fallback-el Multiboot2-ra (jelenleg. Dolgozom rajta, hogy tudjon FreeBSD-t is betölteni).

A Multiboot2 egyébként nem képes higher-half kerneleket kezelni, ennek a problémának az orvoslására írtam már évekkel ezelőtt egy másik rendszerbetöltőt, a BOOTBOOT-ot (ez nyilván nem Multiboot2-ot használ, hanem saját protokollt, ami támogatja a lapozást és a többmagos processzorokat is). https://gitlab.com/bztsrc/bootboot

Érdekesség, hogy a BOOTBOOT hivatalos Coreboot payload lett évekkel ezelőtt https://github.com/coreboot/coreboot/tree/master/payloads/external/BOOT… :-)

Huh, rövid FreeBSD helyzetjelentés. Hát, őszintén szólva többet vártam a FreeBSD-től.

TL;DR: alakul, mint púposgyerek az úthenger alatt, de még nem megy, viszont már tudom, mi volt a baja.

És akkor egy szösszennet arról, miken mentem keresztül. Először is, ledöbbentett, mennyire használhatatlan a doksi. Nagyon bő, meg sok infó van benne, csak épp olyanok, amiket millió másik helyen is megtalálsz. Arról, ami igazán FreeBSD specifikus, konrkétan egy mukkot sem ejtenek. Érdemes megnézni, mennyit írnak a boot loaderről és a kernel handoverről, az egyetlen dologról, ami igazán érdekelne a doksiból: https://docs.freebsd.org/en/books/arch-handbook/boot/#boot-loader és akkor nézzük meg a hivatkozott loader(8) man oldalt is...

Másodszor, a FreeBSD na az bizony egy higher-half kernel, így élből page faultot dobott az első adatelérésnél. Mivel nincs IDT-je, ezért ez tripple fault, amit CPU úgy kezel, hogy újraindul. Sebaj, beraktam a támogatást a Simpleboot-ba. mostantól támogatja a higher-half kerneleket is! :-) Viszont itt még nincs vége. Továbbra is triple fault.

Alaposan körbejártam, ezúttal azért van a hiba, mert a FreeBSD-t rosszul írták meg. Komolyan. Erre tökre nem számítottam. A hibát az okozza, hogy egy iskolapéldaszerű segfault-ot produkál. Olvasni próbál egy olyan adatterületről, ami a szegmensein kívül helyzkedik el. Konkrétan a 0xffffffff80000000 címről, a 0020:ffffffff80c55f93 címen található "mov edx, dword ptr ds:[rax]" utasítás okozza. Csakhogy

readelf -l kernel

Elf file type is EXEC (Executable file)
Entry point 0xffffffff8038b000
There are 11 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040
0x0000000000000268 0x0000000000000268 R 0x8
INTERP 0x00000000000002a8 0xffffffff802002a8 0x00000000002002a8
0x000000000000000d 0x000000000000000d R 0x1
[Requesting program interpreter: /red/herring]
LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000
0x000000000018aa98 0x000000000018aa98 R 0x200000
LOAD 0x000000000018b000 0xffffffff8038b000 0x000000000038b000
0x0000000000dfd150 0x0000000000dfd150 R E 0x200000
LOAD 0x0000000000f88150 0xffffffff81188150 0x0000000001188150
0x0000000000675154 0x0000000000675154 R 0x200000
LOAD 0x0000000001600000 0xffffffff81800000 0x0000000001800000
0x0000000000000140 0x0000000000000140 RW 0x200000
LOAD 0x0000000001601000 0xffffffff81801000 0x0000000001801000
0x00000000001c38e8 0x00000000005ff000 RW 0x200000
DYNAMIC 0x0000000001600000 0xffffffff81800000 0x0000000001800000
0x0000000000000140 0x0000000000000140 RW 0x8
GNU_RELRO 0x0000000001600000 0xffffffff81800000 0x0000000001800000
0x0000000000000140 0x0000000000000140 R 0x1
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x0
NOTE 0x00000000015fd1d4 0xffffffff817fd1d4 0x00000000017fd1d4
0x0000000000000024 0x0000000000000024 R 0x4

Jól látszik, hogy ez a címterület bizony kívül esik az összes szegmensen. Ez még hagyján, de úgy nyúlkál a fordító által definiált memórián kívülre, hogy előtte nem állított be page fault handlert.

Hogy minek kéne lennie ezen a címen, az passz, sehol nem találom a doksikban. Valószínűleg valami rendszerbetöltő által átadott struktúrának kéne lennie, vagy ilyesmi. Gondoltam teszek egy próbát, és belapoztam ide egy üres lapot. És itt ért a második meglepetés. A kód most már tovább fut, viszont nem ellenőrzi az adatokat, így persze előbb utóbb hülyeséget csinál, és továbbra is segfault a vége.

Szóval röviden összefoglalva: a FreeBSD kernel nem képes maga belapozni a területeit, olyan adatterületekre nyúlkál, ami a fordító által definiált tartományon kívülre esik, és az innen beolvasott adatokat még csak nem is ellenőrzi, hogy érvényesek-e. Na szép, mondhatom.

Folyt. köv., próbálok rájönni, mit is kéne rakni a 0xffffffff80000000 címre, hogy ne crasheljen el. Talán ha step-by-step végrehajtást használok úgy, hogy közben mellette olvasom a locore.S (nem túl bő) kommentjeit, kiderül.

Köszönöm, már néztem, de fájóan használhatatlanok.

A loader(8) manuálból csak annyi derül ki, hogy a konfigfájlját Luában kell írni... A loader.efi(8) meg megint semmitmondó, pl "loader.efi will load the kernel into memory that is 2MB aligned below 4GB.", hát persze, hova máshová is tölthetné be? A kérdés nem is ez, hanem hogy hova kell leképezni... és erről semmi sincs :-( Ami meg van, az tényszerűen hibás néha, pl. "Because it executes in x86 protected mode, the amd64 version of loader.efi is..." hát nem, az amd64 verzió még csak véletlenül sem protected módban fut, hanem long módban. Rohadt nagy e kettő között a különbség (csakhogy egyet említsek, long módban kötelező a virtuális címtérleképezés, protected módban meg nem).

( hnsz2002 v | 2023. 07. 18., k – 12:44 )

Szerkesztve: 2023. 07. 18., k – 12:50

Fú ha. Pár nap alatt? Respect. Grat!

Jó ránézni a kódra, és jó látni, hogy van aki még tud rendesen programozni egy (két) rendes nyelvben. :)

Én simán eldobnám a linket pár disztrónak, hátha valaki berakja. :)

"Sose a gép a hülye."

Kösz! Igényeltem hivatalos loader ID-t a "Linux Boot Protocol"-hoz. Remélem adnak egyet, és akkor könnyebb lesz berakatni disztrókba.
Egyébként ér segíteni, ha a programozásban nem is egyszerű, azt nagyon megköszönném, ha valaki felhívná néhány disztró figyelmét rá.

No, nézelődtem picit a Debian oldalán..

Debian -- Kapcsolatfelvétel

 

Itt találtam egy debian-devel levilstát, ez egy általános fejlesztői lista. Fel lehet rá iratkozni.

Fogalmazz meg egy levelet amiben pár mondatot írsz a szoftveredről, igazóból az is jó amit ide írtál csak fogalmazd át angolra.

Szerintem érdemes lehet rápróbálni.. Lehet nyersz még pár tesztelőt.

( iwanabeguru | 2023. 07. 18., k – 13:28 )

Le a kalappal! Pár nap alatt egy bootloader ami ráadásul teli van assembly kóddal is, nem semmi. Egyszerűen lenyűgöznek azok az emberek akik képesek ilyen low level cuccokat írni.

Megnéztem a kódot, de persze nem sokat értettem belőle :D

Lehet ez nem 100%-ban az én hibám. Valszeg soha nem fogok egy betűt sem hozzátenni, de biztos vagy benne hogy jó az abban a formában?
Csak a loader.c 1952 sor, teletűzdelve 100+ soros függvényekkel. Jövőbeli maintainerek szerintem megköszönnék ha kevésbé lenne egybeömlesztve a kód.

Ezt leszámítva, gratz!

// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

> Le a kalappal! Pár nap alatt egy bootloader ami ráadásul teli van assembly kóddal is, nem semmi. Egyszerűen lenyűgöznek azok az emberek akik képesek ilyen low level cuccokat írni.

Kösz!

> biztos vagy benne hogy jó az abban a formában?

Igen.

> Csak a loader.c 1952 sor

Na de annak a negyede komment! És egyébként is, az szerinted sok lenne ennyi minden funkcióra (ne felejstd el, tényleg ez az összes kód, nincs más)? Csak összehasonlításképp, a grub

ansic: 275224 (92.31%)
asm: 11345 (3.81%)

és akkor ebben a függőségek (mtools, xorriso stb.) benne sincsenek! De legyünk megengedőbbek, nézzük el a modulokat meg a többi függőséget, vegyük csak a betöltőt magában (sloccount grub-core/loader) és csak azzal hasonlítsuk: az még úgy is 7.8-szorosa, 15389 sor... (pedig nem is jó az összehasonlítás mert a grub-core/loader önmagában nem is működőképes, míg a Simpleloader loader igen).

A teljes Simpleboot ezzel szemben mindössze:

ansic: 3461 (96.03%)
asm: 143 (3.97%)

Amiből a loader:
ansic: 1560 (100.00%)

> teletűzdelve 100+ soros függvényekkel

Szerinted melyik függvény az, ami nem egy jól definiált feladatot lát el, precízen definiált absztrakciós rétegként és jól meghatározott ki-bementi értékekkel? Nem kötözködök, tényleg érdekelne, szerinted melyik.

És ha már grub, a grub-install.c-ben a "main()" függvény 1096 sor! Ehhez képest a simpleboot.c-ben a "main()" csupán 195 sor (amiből 100 sor egyetlen "if (verbose)" printf tenger a végén, ami ellen nem tudsz mit tenni, dump esetén ki kell írni a dolgokat).

> Jövőbeli maintainerek szerintem megköszönnék ha kevésbé lenne egybeömlesztve a kód.

Haha, ne érts félre, de úgy bírom, amikor valakinek fogalma sincs arról, hogy milyen ára van, ha kismilló függvényre robbantjuk szét a kódot. Lehet hogy egy hostolt alkalmazásnál belefér, hogy elherdáljuk az erőforrásokat, azonban egy ilyen alacsonyszintű kódnál ez nagyon nem kivitelezhető.

Hogy számszerüsítsük: egyetlen függvényhívás legalább 16 byteot foglal a vermen, minimum, mindenképpen (stack frame és visszatérési érték); plusz ehhez jönnek még a lokális változók, amiket ugye függvényeken átívelve nem tudsz újrahasznosítani (értsd: minden függvénynek külön le kell foglalnia egy i ciklusváltozót). Sok apró függvény hívása pillanatok alatt felzabálná azt a 256 byteot, amit engedélyeztem a veremnek...

Sokan azt hiszik, hogy a szépen írt kód a fontosabb, de ez nem igaz, a hatékony és jól működő kód az, ami igazán fontos. Alacsony szinten meg hatványozottan igaz ez. Érdemes elolvasni a témában, mert nem csak dumál ez a cikk, hanem konkrét mérésekkel bizonyítja, mennyire borzalmas végeredményt képes produkálni valami, ami az "okosak" szerint "clean code": https://www.computerenhance.com/p/clean-code-horrible-performance

Ha pedig valakinek az bántja a szemét, hogy hosszúak a sorok, akkor bármelyik IDE egyetlen kattintással áttördeli, emiatt nem érdemes zsörtölődni.

> Ezt leszámítva, gratz!

Köszönöm mégegyszer!

> > teletűzdelve 100+ soros függvényekkel

> Szerinted melyik függvény az, ami nem egy jól definiált feladatot lát el, precízen definiált absztrakciós rétegként és jól meghatározott ki-bementi értékekkel? Nem kötözködök, tényleg érdekelne, szerinted melyik.

Ejnye, ez most tényleg zavar, hogy melyik függvény lehet az, amit szerinted szét kéne robbantani, Szerintem mindnek egyértelmű, jól definiált szerepe van.

gethex - hexa sztringet alakít int-é
getint - decimális sztringet alakít int-é
console_init - inicializálja a boot konzolt
console_putc - kirak egy betűt a konzolra
printf - kirak egy formázott sztringet a konzolra
pb_init - inicializálja a progrsszbárt
pb_draw - frissíti a progresszbart
pb_fini - bezárja a progresszbart
efi_gop - videómód állítása UEFI alatt és siker esetén a paraméterek visszaadása
efi_memmap - memóriatérkép lekérése UEFI alatt
efi_alloc - egy üres lap lefoglalása UEFI alatt
efi_open - fájl megnyitása UEFI alatt
efi_read - olvasás fájlból UEFI alatt
efi_close - fájl bezárása UEFI alatt
efi_systables - rendszerleíró táblák lekérdezése UEFI alatt
bios_loadsec - alacsony szintű szektor olvasás BIOS alatt
bios_vbe - videómód állítása BIOS alatt és siker esetén a paraméterek visszaadása
bios_e820 - memóriatérkép lekérése BIOS alatt
bios_alloc - egy üres lap lefoglalása BIOS alatt
bios_nextclu - következő kluszter lekérése a FAT-ból
bios_open - fájl megnyitása BIOS alatt
bios_read - olvasás fájlból BIOS alatt
bios_close - fájl bezárása BIOS alatt
bios_systables - rendszerleíró táblák lekérdezése BIOS alatt
fw_init - firmware inicializálása (implementációtól független API)
fw_bootsplash - logó kirakása
fw_open - fájl megnyitása (implementációtól független API)
fw_read - olvasás fájlból
fw_close - fájl bezárása
fw_loadconfig - konfiguráció bekérése
fw_loadmodules - modulok betöltése
fw_map - virtuális memória leképezése
fw_loadseg - egy teljes szegmens beolvasása fájlból (az fw_read-et hívja, és ha kell, akkor az fw_map-et)
fw_loadkernel - kernel beolvasása (detektálja a formátumot és az fw_loadseg-et hívja ciklusban)
fw_fini - firmware erőforrások felszabadítása, boot paraméterek véglegesítése
_start - fő függvény, belépési pont. A legnagyobb része egyetlen "switch(kernel_mode)", ami a különféle vezérlésátadást kezeli.

Tényleg érdekelne, hogy melyiket kéne szétrobbantani, mert túl sok mindent csinál. Nem látom, ezek közül melyik lehet az. (Nem gúnyolódok, tényleg kíváncsi vagyok, mert ha az erőforrások engedik, akkor szétszedném.)

Hi,

Pl

efi_gop() 90 sor, 2 hatalmas if block benne

bios_open() szintén 90 sor, szintén két hatalmas if block benne

fw_init() 100 sor, 4 if-else block benne

fw_loadconfig() 130 sor, szintén több if-else block és több ciklus

 

Szerintem ezeket lehetne leginkább "felpucolni", és ahogy sejtem ezek a legfontosabbak is. Nem is az hogy egy függvény más dolgot is csinál mint a neve, hanem egy funkciónak 3-4 módja is bele van sűrítve egybe.  Például a fw_loadconfig mondjuk be tudja tölteni a configot kb4 féle képpen, ezt a 4 féle módot kivenném egy-egy alacsonyabb szintű függvénybe. A másik hogy az ifek belsejét kivenném egy függvénybe aminek a neve leírja hogy mit jelent az a feltétel, pl "if(!memcmp(s, "kernel", 6))", de ez már csak hab a tortán. Valszeg csak nekem nem mond semmit.

A másik a progress bar, tök jó hogy van de nem része a core funkcionalitásnak, én kicsapnám egy külön modulba.

A clean code lényege az olvashatóság, ez nehezen olvasható szerintem, persze ha ez az ára a hatékonyságnak és a hatékonyság a legfontosabb akkor nincs mit tenni. Valóban nem értek a low level programozáshoz, és meghajlok az előtt hogy ha ezernyi kis függvényed van akkor nem fér bele az erőforrásba.

Megkérdezhetem hogy miért ragaszkodsz a 256KB-hoz?

// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

kedves, hogy ezután többen ilyen általános kódolási alapelvekre akarják "tanítani".

Szerintem senki nem akarja alapelvekre tanitani, de ha igy is lenne, attol meg hogy valamiben zseni vagy, meg lehet, hogy masok, masban tudnak ujat mutatni.

Amig egy projekt one-man-show, addig tok jol elvannak a zsenik, csak amikor egyutt kell dolgozni hetkoznapi kepessegu emberekkel, abbol lesznek az olyan balesetek, mint az Apple bug fentebb. Lehet vitatkozni azon, hogy a coding standardoknak van-e letjogosultsaga, de meg a sajat regi kodjaimmal is be tudom magam szopatni, ha nem vagyok konzekvens, nemhogy akkor, amikor 800 (nem typo!) fejlesztovel dolgoztam egy kodbazison.

> bzt kodja meg sokkal szebb, mint az OpenSSL-e, amit amugy olyan szivesen hasznal mindenki 600x minden nap. :)

Remélem nem gúnynak szántad, mert az OpenSSL tényleg ótvar. Ha valakinek C-ben SSL/TLS kell, akkor javaslom inkább az ARM-ék MbedTLS-ét (ők írták, nem azt jelenti, hogy csak ARM-re lenne). Na, az tényleg szépen és olvashatóan van megírva, már amennyire ez egy erősen optimalizált titkosítókönyvtárnál lehetséges. Nagyon átgondolt és jól használható az API-ja is, nem úgy, mint az OpenSSL-é. Egy-két hülyesége van csak, amit meg könnyű megszokni (és egyébként amiről mindig kiderül idővel, hogy security oka van).

ARM-ék MbedTLS-ét (ők írták...

Nem ők írták, csak 'karbantartják'.
Volt anno az XySSL, valamikor 15 évvel ezelőttig (Az SSLv3/TLSv1-et tudott.)
Aztán az bezáródott és lett belőle PolarSSL, amiért már fizetni kellett, ha beépítetted saját termékbe.

És a PolarSSL-t vette meg az ARM és nevezték át MbedTLS-re.

általánosságban egyetértek, csakhogy:

- ez itt egy one-man-show, és semmi nem utal arra, hogy ez megváltozna a jövőben.

- itt nem arról van szó, hogy nem használ semmilyen coding standard-et, hanem hogy a low-level szempontok figyelembevétele, és más - praktikus - szempontok miatt MÁS standard-et használ, mint amit a sok okos megszokott, és ész nélkül, bármilyen környezetben használna.

- nem gondolom, hogy itt bárki bármi újat mutatott volna neki, de ha én siklottam át valami fölött, kérlek hivatkozd be, mire gondolsz.

> efi_gop() 90 sor, 2 hatalmas if block benne

Mámint? Az egyik az egészet öleli körbe, és azt nézi, hogy van-e gop támogatás. Nem szétvágható. A másik meg a paraméterátadást, hogyha sikerült az üzemmódot váltani, csak akkor csapja felül az értékeket. Nem látom be, hogy mi értelme lenne ezt szétszedni, különös tekintettel arra, hogy külön-külön egyik kódrészlet sem működőképes önmagában. Talán nem tűnt fel, de az első blokk végigfut a lehetséges módokon, és amit talál, azt állítja be a második. Szorosan összetartoznak, egyiknek sincs értelme a másik nélkül. Ráadásul ha szét akarnád venni, akkor át kéne adni paraméterben a lokális változók felét, a harmadát meg duplikálni kéne (mint a gop, status, mode info stb.).

> bios_open() szintén 90 sor, szintén két hatalmas if block benne

Igen, van ebben is if... és az feltűnt, hogy egy ciklus az egész, mert a könyvtárfa és elérési út bejárás rekurzív algoritmusát átkonvertáltam iterációra? Van fogalmad arról, hogy veremköltsége lenne annak, ha ez szétbontanád?

> fw_init() 100 sor, 4 if-else block benn

Újfent, minek? Semmi értelme, nem lehetséges "félig inicializálni". Vagy megteszed, vagy sem. Ráadásul itt kőkemény hardware-s függőségek is vannak benne, nem lehet csak úgy szétcincálni. Nem véletlenül vannak ott azok a kommentek. Esetleg efi_init-re és bios_init-re szétvágható.

Nem mindegy, mit mikor hívsz (például a memóriatérkép lekérés BIOS-on előbb kell történjen, mint a kernelbetöltés, mivel tudnod kell, hogy melyik régiók szabadok. Ezzel szemben UEFI alatt csakis a legeslegvégén, közvetlenül az ExitBootServices hívása előtt lehetséges, ugyanis a memóriatérkép folyamatosan változik időközben!)

> Például a fw_loadconfig mondjuk be tudja tölteni a configot kb4 féle képpen

De nem tudja, és minek is kéne tudnia? Ennek az egész projektnek pont az a lényege, hogy mindenre pontosan egy megoldást, méghozzá a lehető legegyszerűbb megoldást nyújta.

> hanem egy funkciónak 3-4 módja is bele van sűrítve egybe.

Megint meg kell kérdeznem, ne csak a levegőbe lógjon, amit mondasz, mire gondolsz konkrétan? Minden függvények pontosan egyetlen egy, jól definiált funkciója van. Alábbi posztomban meg is találod a leírást. TÉVEDÉS, amit mondasz, hogy többféle módja is lenne, mert nincs.

> A másik hogy az ifek belsejét kivenném egy függvénybe aminek a neve leírja hogy mit jelent az a feltétel, pl "if(!memcmp(s, "kernel", 6))", de ez már csak hab a tortán

Valóban, aranyba foglalnám a kezét annak, aki ilyet merészel csinálni, hogy soha a büdős életben ne tudjon többé programokat írni. Ettől mászok a leginkább a falra, ez a kontraproduktivitás nonpluszultrája meg csimborasszója. Nem lesz olvashatóbb a kód egy csöppet sem, viszont hazavágod a karbantarthatóságot: most egy úgy parancs bevezetéséhez pontosan egyetlen egy ponton kell belenyúlni a kódba, a Te a megoldásoddal meg a fasz tudja hány helyen kéne! Normááááális...?

> A másik a progress bar, tök jó hogy van de nem része a core funkcionalitásnak, én kicsapnám egy külön modulba.

Édes drága öcsém. Már hogy ne lenne része a core funkcionalitásnak az user visszajelzés??? Az egyik legfontosabb, máskülönben azt hinnéd, lefagyott a géped bekapcsolás után! Semmi más visszajelzés nincs, ez az egyetlen! És miféle modulról hablatyolsz itt, az egész betöltő egyetlen egy fájl (forrásban és binárisban is). Miféle modulok? Nagyon el vagy tévedve.

> A clean code lényege az olvashatóság, ez nehezen olvasható szerintem

A clean code arra való, hogy szar, nehezen karbantartható, és ótvar performanciájú programokat alkossanak, hogy aztán tripla áron refaktorálni kelljen félévente, és azért hívják úgy, hogy ez ne tűnjön fel nagyon a mánádzsereknek. Egyszer már ideraktam, de iderakom mégegyszer a linket: https://www.computerenhance.com/p/clean-code-horrible-performance

FONTOS, ez a cikk nemcsak dumál meg mellébeszél, ez nem marketingbullshit, hanem konkrét, kézzelfogható mérési eredményeket tartalmaz.

> persze ha ez az ára a hatékonyságnak és a hatékonyság a legfontosabb akkor nincs mit tenni.

Még mindig nem érted. Alacsony szinten nem lehet bohóckodni meg szórakozni. Ha négy-öt függvényhívás mélységed van, akkor máris betelik a verem, és itt nincs run-time stack-protektor, vagy canary ellenőrzés, mert bare metalon futsz. Akkor veszed csak észre, hogy baj van, amikor lefagy valami a stacksmashtől. Nemcsak arról van szó, hogy fontos-e a hatékonyság, hanem hogy mi lehetséges és mi nem erőforrásszegény környezetben.

Nem kell ez a lekezelő hangnem. Már mindenki elismerte a zsenialitásod. Egy másik zseni aki szintén járatos a bootloader írásban valszeg úgy olvassa a kódodat mint egy megfejtett keresztrejtvényt, ha nekem kéne meg kb olyan lenne mintha kínai keresztrejtvényt kéne megfejtenem.

Azt látom hogy nem vagy képes felfogni hogy ha van egy ifed akkor már két dolgot is csinál az a függvény néha ezt néha azt. De nem akarok erről vitatkozni mert nem értek hozzá.

// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Félreértesz. Szó sincs semmiféle lekezelő hangnemről, próbálok rájönni, mit is akartál mondani. Megtanultam már, hogy a legidiótábbnak tűnő hibabejelentésben is lehet igazság.

És hogy neked legyen: kettévágtam az fw_loadconfig-ot, valamint szétszedtem az fw_init-et efi_init-re és bios_init-re. Mármint azt a részét, ami nem közös.

(Na jó, a progressbaroson kicsit tényleg kibuktam, beismerem. Az egész három függvény, rendre 15, 12 és 11 sorosak, emiatt kifejleszteni egy modulkezelőt, hát... Bocs a korábbi hangnemem miatt)

> Azt látom hogy nem vagy képes felfogni hogy ha van egy ifed akkor már két dolgot is csinál az a függvény

Na ez viszont totál hülyeség. Az, hogy egy függvénynek hányféle módja van, az határozza meg, hogy hányféleképp hívható. Csak azért, mert egy elágazás is van a törzsében, attól még nem lesz több módja (az efi_gop például mindig három paramétert vár, szélesség, magasság, bitmélység, tök mindegy, hány if van benne, attól még csak egyféle módon hívható.) Szépen is néznénk ki, ha minden elágazást kötelező lenne függvénnyé alakítani, hulla felesleges, de legalább erőforrászabáló. Lassan kezdem érteni, miért több Gigányi a Firefox meg a Chrome...

> Megkérdezhetem hogy miért ragaszkodsz a 256KB-hoz?

Mire gondolsz, milyen 256KB?

A verem mérete 256 BÁJT, és nem KILObájt. Ez azért van, mert a processzor valós módban mindössze 64KB-ot enged címezni egyszerre, és azt is csakis a fizikai memória első 640KB-jából (pontosabban 1M, csakhogy ide van leképezve a ROM meg a VGA MMIO is, azt a területet nem használhatod fel magadnak). A program 64 bites kódszegmensen, long módban fut ugyan, de ahhoz, hogy futás közben oda-vissza tudjak kapcsolgatni real mode és long mode között a BIOS hívásokhoz, úgy kell kialakítani a memóriát, hogy minden beleférjen és valós módból is elérhető legyen. Másra is szükség van, például a BIOS hívások által visszaadott adatokra, ezeknek is mind bele kell férnie a szűkös címtartományba. Ezen kívül a processzor és maga a BIOS is itt tárolja a belső változóit, amiket nem szabad felülírni (IVT, GDT, BDA). Ezért mindent levonunk a 64K-ból, akkor kb. 1K marad a teljes veremnek, amiből 256 bájtot engedélyezek a C kódnak, a többibe kerül, amit a hívott BIOS funkció visszaad (E820 memóriatérkép lista, VBE videómód lista, a beolvasott szektor tartalma, stb.)

Ezek olyan megszorítások, amikhez nem én ragaszkodom, hanem a hardware követeli meg (mind a címzésmódból eredő 64K korlát, mind a fix címterület, mind a rendszerváltozók rögzített címei). Sok trükközéssel maximum annyit tudnék elérni, hogy külön legyen a kód és adatszegmens, így a gépikódú rész kikerülhetne az első 64K-ból egy külön 64K-ba, összesen lehetővé téve 128K-t. Csakhogy nem éri meg, a komplett betöltő program ugyanis nem lehet nagyobb 64K-nál, mivel egy BIOS hívás egyszerre nem tud ennél több adatot betölteni (a boot.asm-ben). Ezért csinálom azt, hogy az első 64K-t használja a kombinált valós és long módú programrész. További 64K-t fenntartok kizárólag a long módú kódrész adatainak (COFF/PE inicializált adat és bss szegmenseinek), a "dinamikus" memória pedig 128K-tól, azaz 0x20000-tól indul, és 640K-ig, azaz pontosabban 0x9A000-ig tart (0x9FFFF lenne, csak néhány BIOS szeret adatokat pakolni 0x9A000 és 0x9FFFF közé, amiket ha átírnál, rendszerösszeomlás lenne a vége. Jobb biztosra menni.)

( locsemege v | 2023. 07. 18., k – 21:07 )

Jól gondolom, hogy minden kernelfrissítéskor új image-et kellene csinálni? Azért kérdezem, mert Fedorához néhány naponta, esetleg hetente szokott új kernel jönni. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> mindent megcsinál (image), aztán a boot jó lassan betölti a kernelt,

Javítva, a BIOSos betöltés kb. a százszorosára lett gyorsítva.

> Jól gondolom, hogy minden kernelfrissítéskor új image-et kellene csinálni?

Nem. Egyszer megcsinálod, az onnantól mindig bootolható lesz. Felmountolhatod, és a kerneleket meg a konfigot kényed kedved szerint változtathatgatod továbbra is bootolni fog, ha lecserélted, akkor az új kernellel.

Gondolkodom egy "-b" kapcsolón, ami nem lemezképet készítene, hanem bootolhatóvá tenne egy már létező device-t, azaz a megadott device-on megkeresné az ESP-t és felmásolná a loadert rá. Pl. "simpleboot -b /dev/sda". Szerinted jó ötlet? Lenne igény rá? Kicsit macerásabb már meglévő fájlrendszerre másolni, mint egy tök újat legyártani a nulláról, de ha van erre igény, belerakom.

Az biztos nem lesz benne, mert ez nem arra való. Nagyon leegyszerűsítve ez egy boot loader, és nem egy boot manager. (kb. mint az NTLDR vagy a LILO vagy a syslinux, csak épp többféle kernel és boot protokoll támogatással)

Max annyit el tudok képzelni, hogy a konfigba bekerül a "kernel" és "module" mellé "backupkernel" és "backupmodule" parancs is. Ha induláskor le van nyomva bármelyik billentyű, akkor a kernel helyett az azokban megadottat tölti be. Interaktív csilivili menü meg szövegszerkesztő ezer százalék, hogy sosem kerül bele, mert az ellentétes a projekt céljával (ami a legminimálisabb még jól működő megoldás).

> És miért fáj átnevezni boot managerré? Mert ha jól értem, csak adminisztratív akadály van.

Csak az, hogy ellenkezik a projekt célkitűzésével. Bloated boot manager már létezik, de olyan, ami szándékosan mindent a minimumon tart, és totál függőségmentes, na olyanból nem sok.

Ha csak annyit tennél bele, hogy felkínálná a kerneleket - helyesebben config bejegyzéseket -, s egy egyjegyű számmal [0-9] választani lehetne, az sokat hozna szolgáltatásban, de könnyű leprogramozni, nem egy hatalmas vagy bonyolult kód.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az én elképzelésembe kb. ennyi tartozik. Ugyanis ahogy (asszem) locsemege is írta, erre a funkcióra azért lenne szükség, hogy amikor elkefélődik valami az aktuális kernel+modul párossal és abszolút bootolhatatlan rendszert állítunk elő, akkor ne kelljen lennie egy alternatív médiának, amire már rá lehet bootolni és kijavítani ezt. Ha van ilyen backupkernel rész, akkor pl. lehet tartani egy stabil, megbízható kernelverziót talonban.

Tegnap láttam, hogy beletetted a memóriaméret kiírását - ideális esetben valahogy ehhez hasonlóan jó lenne egy üzenet, hogy a backupkernel eléréséhez legyen lenyomva az Any(kó) billentyű az első (mondjuk) 5 sec-ben.

(Amúgy jelzem, valamikor este olvastam, hogy gyorsítottál a BIOS betöltésen - akkor letöltöttem az éppen aktuális változatot, mindent újracsináltam, de ezen a memóriakiíráson kívül, meg hogy FreeBSD kernelnek és nem multiboot-nak hívja - más változást - sebességbelit se - tapasztaltam.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> Ugyanis ahogy (asszem) locsemege is írta, erre a funkcióra azért lenne szükség, hogy amikor elkefélődik valami az aktuális kernel+modul párossal és abszolút bootolhatatlan rendszert állítunk elő, akkor ne kelljen lennie egy alternatív médiának, amire már rá lehet bootolni és kijavítani ezt.

Igen, ez megvan, és be is fogom rakni. Beláttam, hogy a backup kernel tényleg szükséges funkcó, ha esetleg gáz lenne az új kernellel, akkor bootolhatatlan maradna a gép.

> 5 sec-ben.

Á, azt nem, ennyit sosem fogok várni. Azon gondolkodom, hogy a kernelbetöltés közben ellenőrzöm, legfeljebb újrakezdem a betöltést előről. Aközben úgyis várni kell. 5 másodpercet veszíteni MINDEN induláskor nagyon sok.

> Amúgy jelzem, valamikor este olvastam, hogy gyorsítottál a BIOS betöltésen - akkor letöltöttem az éppen aktuális változatot, mindent újracsináltam, de ezen a memóriakiíráson kívül, meg hogy FreeBSD kernelnek és nem multiboot-nak hívja - más változást - sebességbelit se - tapasztaltam

Az akkor van, ha Master ATA-ról bootolsz PIO módban, ezt külön lekezeltem. Egyébként a BIOS verzió az a BIOS-t használja szektorolvasásra, ami rohadt lassú. Minden szektorbetöltésnél long módból át kell kapcsolni compat módba, leállítani a lapozást, onnan protected módba, majd onnan valós módba, meghívni a BIOS interruptot, majd vissza protected módba, ott visszakapcsolni a virtuális címteret, aztán onnan vissza long módba. Izzad a proci közben rendesen. Most úgy van, ha olyan beállításod van, amit minden VM (qemu, VB, VMWare, bochs stb.) alapból támogat, és a mai modern masinák 90%-a hardveresen emulál, akkor gyors. Ha bármi mást használsz, akkor marad a lassú, de maximálisan támogatott BIOS.

De nem kell várni, kell valami olyan gomb, amit büntetlenül nyomva tudsz tartani folyamatosan már előtte is akár, megnézi hogy nyomva van-e, ha igen akkor backup, ha nem akkor rendes. (A windowsnak pl. ctrl volt, aztán lett hivatalosan F8, régebben még működött a ctrl is, már most nem tudom...) Az F gombokon elég sok minden van és elég változatos is lehet hardver függvényében. A CTRL+valami is sok minden szokott lenni (mondjuk az elsősorban szervereken, raid controller bios, nic firmware, diagnosztika...). Ezért írtam pl. a shiftet. És ráadásul minden billentyűzeten van, nem az van hogy jah ha maced van akkor nem ctrl hanem command... Egyik-másik notebookra már szinte fel sincs festve az Fx, csak a fényerő, hangerő és egyéb jelek... Vagy csak Fn-nel működik. A shiftet mindenhol meg lehet nyomni, minden user ismeri, az is, aki még a CTRL-t sem. :)

"Sose a gép a hülye."

Zahy javaslatát én is támogatom két ok miatt.

1) Dual boot, pl. Linux és Windows
2) Mi van, ha az új kernellel valami baj van? Téglásítottuk a gépet, csak live pendrive-ról lehet rendbe szedni? Jó volna, ha a régi kernelt vissza lehetne boot-olni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem semmi baj nincs, ha csak live pendrive-ról lehet helyrehozni. Persze a többiben igazatok van.

Saját gépem néha megszopat, sedutil-alapú hardveres NVMe öntitkosítást használok, és néha 1-1 hibás update-kor nem jól futott le az initramfs-generálás Arch alatt, és nem működött a jelszóbevitel a boot korai szakaszában lefutó sedutil-cli alatt. Na, azt óriási szívás volt helyrehozni, de megtanultam, felkészültem rá, boot partícióra felrakta egy szükséges toolokat hozzá. A sedutil sajnos nem része egyik telepített és live disztrónak sem, van ugyan hozzá hivatalos rescue lemezkép, de az meg ACPI hülyeség miatt áramtalanít újraindításkor, így elveszik a kititkosított állapot. Azóta minden fontosabb initramfs-t érintő update-nél inkább kézzel is lefuttatom az mkinitcpio parancsot, hogy tuti stimmeljen minden.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Egyszer megcsinálod, az onnantól mindig bootolható lesz. Felmountolhatod, és a kerneleket meg a konfigot kényed kedved szerint változtathatgatod továbbra is bootolni fog, ha lecserélted, akkor az új kernellel.

Tehát ebbe az image-be bele lehet pakolni több kernelt, fel kell mount-olni loop device-ként, s a config módosítása után boot-olja a másik kernelt? Új kernel hogyan kerül bele? Symlink?

Ugye a gondom az, hogy Fedorára havonta jön mondjuk öt új kernel, semmi kedvem szüttyögni új image készítésével mindig. Tekintve, hogy eddig csak PIC32 (MIPS core) architektúrára írtam boot loadert, az sem szabványos, csak mentem a magam feje után, mert megtehettem, így aztán fogalmam sincs, mi van egy PC-n, hol van az entry point, mit kell előtte tenni, hogy abból ne legyen baj, mi lesz az IT vektorokkal, a stack inicializálásával, mi van a hardware, például RAM frissítés initjével, ezekre kell-e figyelni, s ha igen, akkor kinek és hol.

(Amúgy vicces volt olvasni a commentben, hogy az NMI tiltása, tekintve, hogy az NMI nem maszkolható megszakítást jelent. :) Jó, tudom, a PC-k valóban annyira vackok, hogy ami nem az, azért mégis de, az.)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Tehát ebbe az image-be bele lehet pakolni több kernelt

Persze.

> fel kell mount-olni loop device-ként, s a config módosítása után boot-olja a másik kernelt?

Annyira, hogy példa kernelek mappájában a Makefilenak van egy "make mnt" opciója is, ami csuklóból megteszi ezt (Linux alatt, csak mert lusta vagyok mindig becsépelni a mount parancsot a sok kapcsolóval)
https://gitlab.com/bztsrc/simpleboot/-/blob/main/example/Makefile#L48

> Új kernel hogyan kerül bele?

Hát felmountolod és rámásolod. Ennyi. A fájlrendszert bootoláskor értelmezi, ezért új mappák, új fájlok, meg töredezettség tök mindegy, nem számít.

> így aztán fogalmam sincs, mi van egy PC-n, hol van az entry point, mit kell előtte tenni, hogy abból ne legyen baj, mi lesz az IT vektorokkal, a stack inicializálásával, mi van a hardware, például RAM frissítés initjével, ezekre kell-e figyelni, s ha igen, akkor kinek és hol.

Hát ez bizony jó sok kutatómunkát igényel, ráadásul többhelyről kell összevadászni.

- BIOS alatt a BIOS Boot Specification (https://www.scs.stanford.edu/nyu/04fa/lab/specsbbs101.pdf) a mérvadó, bár elég srendliánul implementálja néhány förmver. Ami biztos, hogy az elsődleges lemez (ha merevlemez nincs, akkor floppy) első szektora betöltődik a memóra 0:7C00-ás címére, és a meghajtó kódja a DL regiszterbe kerül. Ennyi, kábé semmi másban nem bízhatsz. Még abban sem, hogy az a cím tényleg 0:7C00 és nem 7C0:0 (vicces valós módú címzés miatt e kettő ugyanaz a lineáris cím, de tök más szegmenssel). Mindent neked kell csinálnod, a processzor inicializálst, a fájlrendszer értelmezést, stb. Simpleboot esetén a legnagyobb kihívás az volt, hogy egy egy szektornyi kód képes legyen inicializálni a processzort, betölteni egy fájlt a lemezről, majd értelmezni a COFF/PE futtathatót és relokálni a szekcióit... NAGYON kevés az a 446 bájt (512 a szektor mínusz a partíciós tábla mínusz magic bájtok).

- UEFI alatt az UEFI Specification (https://uefi.org/specifications) mondja meg, mi történik. Na ez az igazi agyfasz, de lényegében az első merevlemezről betölti a GPT-t, és megkeresi rajta az ESP partíciót. Ezt követően végigveszi a BootOrder nevű NVRAM változóban felsorolt fájlokat, és megpróbálja betölteni őket. Ha egyiket sem találja, akkor összerak egy "EFI/BOOT/BOOT(architektúrakód).EFI" path-ot, és azt is bepróbálja. Ennek egy relokálható, Picipuha COFF/PE futtathatónak kell lennie, speciális kóddal a fejlécben (a Simpleboot BIOS-os szektora ugyanezt a fájlt tölti be). Az igazi szívás vele az, hogy még a szabványnak megfelelő förmverek is totál inkompatíbilisek egymással, mivel valami agyhalott dinamikus interfészeket rakott bele... Az egyik hw gyártó ilyen interfészekkel szállít, a másik amolyannal. Szerencsére igyekeztem minimálisan tartani, így ami nekem kell, az a 2.0-ás förmverek mindegyikében benne szokott lenni. Régebbi gépeken, 1.0-ás förmverrel vagy megy, vagy nem. Inteles mac-eken tutira nem, mert azok nem szállítják a GOP interfészt, amire szükség van a framebuffer inicializáláshoz (Apple-ék UGA interfészt szállítanak ugyanis). Szóval ja, brainfuck a javából.

- kernel esetében pedig mind a formátum, az entry point, az elvárt lapozás, a bemeneti paraméterek, szóval minden tök más kernelenként (és még architektúránként is, ugyanannál a kernelnél). Ezért szokás ezek összességét külön "boot protocol"-nak hívni. A Multiboot2 nem egy nagy eresztés, sok szívás van vele (pl csak x86 32-bites kernelekhez írták, a 64-bitet utólag erőltették bele, nem is sikerült jól, több architektúra támogatás meg még mindig nincs), viszont annyi előnye van, hogy kernelfüggetlen szabvány, így senki nem túrkálhat önkényesen bele, többnyire stabil környezetet jelent.

> Amúgy vicces volt olvasni a commentben, hogy az NMI tiltása, tekintve, hogy az NMI nem maszkolható megszakítást jelent. :)

Igen. Ráadásul az AMD64 Developers Manual fapofával leírja, muszáj tiltani long mode-ba való kapcsolás előtt, azt, ami elvileg nem is letiltható :-) Ennél egyébként már csak a "Keyboard not found, press F1 to continue" BIOS hibaüzenet zseniálisabb!

Hm hm, A 2011-es es 2008-as gepeik UGA-sak voltak, ez tuti, a 2018-as gep pedig szerintem, mar GOP-os. De szerintem valamikor kozte lett GOP-os a dolog. Az is lehet, hogy valami FW update hozta el, illetve az is lehet, hogy nem mind1, hogy integralt, vagy dedikalt a GPU. Hogyan tudom szerinted megnezni, hogy GOP vagy UGA? 

Passz. Az egyetlen tutibiztos megoldás, ha összedobsz egy minimál EFI programot mindössze két függvényhívással, ami a BootServices LocateProtocol-nak átadja a GOP-os guid-et, aztán meg a UGA guidet, és megmondja, a kettő közül melyik dobott errort. Ennél biztosabb módszert nem tudok, arról meg nincs tudomásom, hogy valami parancssoros cucc megmondaná futó OS alatt (system_profiler talán?) Régen volt mac-em, de már nincs, nem tudom sajnos kipróbálni. (Nem kell egyébként a bootolást szétbarmolni ezért, mac-eken szokott lenni EFI Shell, szóval annélkül le lehet futtatni.)

( Hevi v | 2023. 07. 18., k – 22:33 )

Simpleboot, a szopásmentes GRUB helyettesítő

Jó ez a linugz, na!

A grubbal az a baj, hogy eszméletlen nagy. Lényegében szinte egy oprendszer. Sokat mond, hogy a configja gyakorlatilag egy shell program. Meg az is, hogy indirect, mert vannak template-ek, amelyek alapján a config scriptet egy utility generálja. Ugyan működik, de egy bonyolult undormány.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( bzt | 2023. 07. 19., sze – 20:53 )

Na, pár újdonság.

Lett -b kapcsoló, ezzel már létező lemezkép vagy akár igazi lemez is bootolhatóvá tehető (már léteznie kell rajta ESP partíciónak, és fájlokat sem másol fel, csak a bootolhatóságát állítja).

Lett vészhelyzeti backup is. Ha betöltés közben valaki leüt egy billentyűt, akkor újraindul a loader, de ezúttal a "backup" előtagos parancsokat olvassa ki a simpleboot.cfg fájlból. Mivel bármelyik parancs "backup" előtaggal látható el, ezért vészhelyzeti indulásnál más lehet a felbontás, a háttérkép vagy a logó is, nemcsak a kernel meg a modulok.

Korábban már akartam írni: ha a lemezképet dd-vel felrakom egy pendrive-ra, és azt bedugom egy működő FreeBSD-s gépbe, kapok pár sornyi hibát / warningot a konzolon:

GEOM: da0: unsupported GPT detected.
GEOM: da0: number of GPT entries: 8184, entry size: 128B.
GEOM: da0: maximum supported number of GPT entries: 4096, entry size: 1024B.
GEOM: da0: GPT rejected.
 

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Köszönöm a visszajelzést!

Faragok rajta. Több validátort is ráeresztettem (fdisk, de különösen a gdisk-nek van egy nagyon jó beépített ellenőrzője). Egyik sem dobott hibát (azaz először dehogy nem, egy teljes napom ráment, mire eltűntettem mindet :-)

> number of GPT entries: 8184

Aha, asszem ez meg is van, az első partícióig minden területet a GPT-nek adok: https://gitlab.com/bztsrc/simpleboot/-/blob/main/src/simpleboot.c#L147 Limitálom akkor 1024-re, biztos, ami biztos alapon. Ezzel még biztos szívni fogok, mert befolyásolja a Secondary GPT relatív címét... Az nem elég, hogy csak beállítod a kezdő szektor címét.

Még egy hibajegy:

-vv hatására kiírsz sok infót a normál bootparaméterekről, de a framebuffer / backupframebuffer valahogy összekeveredik:

$ cat DIR/simpleboot.cfg
kernel /kernel
bootsplash #007f7f /takeittux.tga
framebuffer 1680 1050 32
verbose 3
backupkernel /kernel.old
backupbootsplash #007f7f /takeittux.tga
backupframebuffer 640 480 32
backupverbose 3

$ ./simpleboot -vv DIR simpleboot.img
OK                                      

Loader:            start LBA 3115, size 83 sectors
Boot partition:    start LBA 2048, size 67584 sectors
Partition UUID:    1231B6E8-0E0C-6860-1D512B69C0E98036
Kernel:            "/kernel"
Format:            Multiboot2 ELF64 kernel (x86_64)
                   (invalid, not freestanding kernel?)
                   80200000 .. 8038aa98 r.. (invalid, higher-half kernel)
                   8038b000 .. 81188150 r.x (invalid, higher-half kernel)
                   81188150 .. 817fd2a4 r.. (invalid, higher-half kernel)
                   81800000 .. 81800140 rw. (invalid, higher-half kernel)
                   81801000 .. 81e00000 rw. (invalid, higher-half kernel)
                   (invalid, dynamically linked kernel?)
Number of modules: 0 file
Framebuffer:       640 x 480 pixels, 32 bits per pixel

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Köszönöm, a dumpot még nem húztam utánna, de most már megvan ez is :-)

A FreeBSD kernelt annak mondja, ami (jövőre nézve beraktam mindjárt az OpenBSD-t és NetBSD-t is). Rendesen jelzi a backupos opciókat, a framebuffer értékei nem keverednek többé. Kikerültek a "(invalid, higher-half kernel)" hibaüzenetek, mivel már képes a betöltő higher-halfba tölteni (volt egy olyan hibaüzenet is, hogy "(invalid, not page aligned)" ami itt ugyan nem látszik, de ez is kikerült, mivel megtrükköztem a betöltőben, hogy ezt is kezelje).

Az egyetlen, amivel nem tudtam mit kezdeni, az az "(invalid, not freestanding kernel?)" és komája, a "(invalid, dynamically linked kernel?)" üzenet. Ez azt jelzi, hogy a program header szerint host-olt alkalmazás, azaz "-ffreestanding" kapcsoló nélkül, és dinamikus függvénykönyvtárakkal, azaz "-shared -lX" kapcsolókkal lett fordítva. Nyilván nem, megnéztem a Makefilet és az ELF binárist, de attól még az interpreter és a dynamic sor bennmaradt az ELF fejlécében, ezért szól.

( arpi_esp v | 2023. 07. 20., cs – 19:32 )

gratula, tetszik! en is ruhellem a grubot, az elilo-val elvagyok de annak is vannak hulyesegei...

mondjuk a problemak mindig akkor kezdodnek, ha sok disk van, es a bios nem feltetlen olyan sorrendben latja oket mint a linux...

> gratula, tetszik! en is ruhellem a grubot, az elilo-val elvagyok de annak is vannak hulyesegei...

Köszönöm! Nem is annyira arról van szó, hogy rühellem-e, hanem hogy lemezképgyártásra alkalmatlan. grub-mkrescue még csak-csak, de elég gáz a végeredménye. Régen lilo-t használtam, elilo valahogy kimaradt, mert addigra grubos lett minden disztró.

> mondjuk a problemak mindig akkor kezdodnek, ha sok disk van, es a bios nem feltetlen olyan sorrendben latja oket mint a linux...

Ezt a problémát nagyon elegánsan oldom meg: nem foglalkozom vele :-) Ez csakis az első meghajtóról tud bootolni, és nem is tervezem továbbbonyolítani, lévén a minnél egyszerűbb a mottója. Az meg, hogy a kernel miként látja, nem számít, mert csak továbbpasszolom a "root=" command line-t, a Simpleboot maga nem használja.

Milyen mértékegység szerint első disk? Gondolom, a sorrend attól függ, milyen hamar válaszolnak már persze a kernelnek, éppen ezért nem szabad sda, sdb, sdc, stb. nevekkel hivatkozni, hanem UUID-dal célszerű. Persze, a kernel előtt lehet valamiféle hardware cím szerinti sorrendiség, ezt nem tudom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Milyen mértékegység szerint első disk?

A firmware szerinti. BIOS alatt az, amelyik a 0x1F0-ás IO címen érhető el (ez eredetileg az ATA master volt, de a modern gépek is hardware-sen emulálják ezt a portot, de hogy melyik vinyóval, az passz. Nem láttam még olyant, hogy mindig más lett volna, eléggé fix, hogy mi kerül ide.) UEFI alatt meg az a diszk, amelyik elsőként regisztrálja az FS0: meghajtót (itt már láttam olyant, hogy ugyanaz a hw, de bekapcsolásonként nem mindig ua.)

> a sorrend attól függ, milyen hamar válaszolnak már persze a kernelnek, éppen ezért nem szabad sda, sdb, sdc, stb. nevekkel hivatkozni, hanem UUID-dal célszerű.

Igen, pont ezért van a "-u <uuid>" opció a parancssorban, hogy kigenerált lemezkép ESP partíciójának fix UUID-t adhass.

BIOS alatt az, amelyik a 0x1F0-ás IO címen érhető el (ez eredetileg az ATA master volt, de a modern gépek is hardware-sen emulálják ezt a portot

Most akkor a BIOS INT 13h-t használod (ami nagyon nem egyenlő az 0x1f0-ás ATA porttal), vagy direktben támadod az ATA interfészt I/O műveletekkel? Ez utóbbit szerintem pl. nem emulálja senki SCSI meg RAID kártyák esetén, de abban sem lennék biztos, hogy az M.2 NVME flashről bootoló gépeken találni ilyet.

> Most akkor a BIOS INT 13h-t használod (ami nagyon nem egyenlő az 0x1f0-ás ATA porttal), vagy direktben támadod az ATA interfészt I/O műveletekkel?

Is-is. A boot szektor egyetlen INT 13h hívást használ, az EFI/BOOT/BOOTX64.EFI meg megnézi, hogy a BIOS drivekód 80h-e, és ha igen, akkor elérhető-e a port (ha FFh-t olvas a státuszportról, akkor úgy veszi, nincs). Ha minden oké, akkor direkt ATA, ha ezek közül bármi nem teljesül, akkor fallbackel INT 13h-ra. (Mindez persze BIOS alatt, ha UEFI-n töltődik be ugyanaz az EFI/BOOT/BOOTX64.EFI fájl, akkor nyilván EFI_SIMPLE_FILESYSTEM_PROTOCOL-t használ.)

> Ez utóbbit szerintem pl. nem emulálja senki SCSI meg RAID kártyák esetén

Általában de, a hw-s RAID kártyák mind emulálják. Muszáj nekik, ettől lesznek hw-s RAID-ek. SCSI-ban nem vagyok biztos, olyant kb. 20 éve használtam utoljára.

> de abban sem lennék biztos, hogy az M.2 NVME flashről bootoló gépeken találni ilyet.

Tipikusan minden ATA-nál későbbi kontroller (SATA, PATA stb.) emulálja, mert a PC-n a visszamenőleges kompatibilitás elsődleges. Ha hiszed, ha nem, még a legmodernebb HPET is használható simán IBM XT PIC-ként és RTC-ként. Gondolom emiatt az NVME-nél is elvárás, hogy emulálja (egyébként nem valószínű, hogy régi BIOS-os gépeken tényleg találsz NVME-t), de ha mégsem, akkor ott a BIOS fallback, annak kutya kötelessége kezelni bármilyen kontrollert. Sokkal valószínűbb, hogy bármilyen NVME-s gép már kizárólag UEFI-t használ, ott meg mindig a firmware-re bízza.

meg megnézi, hogy a BIOS drivekód 80h-e, és ha igen, akkor elérhető-e a port (ha FFh-t olvas a státuszportról, akkor úgy veszi, nincs). Ha minden oké, akkor direkt ATA, ha ezek közül bármi nem teljesül, akkor fallbackel INT 13h-ra.

Szerintem a logikád hibás. Semmi nem garantálja, hogy ha létezik az első IDE port, akkor az INT 13h 80h diszk az pont ezzel esik egybe. Ha mondjuk egy szép régi (mondjuk Adaptec 2940) SCSI kártya is van a gépben, bekonfigurálva bootolható diszkkel, meg egy classic IDE kártya is van a gépben, rajta egy IDE diszkkel, akkor a BIOS 80h diszk attól függően lesz az egyik vagy a másik, hogy az Adaptec BIOS-ában hogyan állítottad be (róla akarsz-e bootolni vagy sem).

De későbbi generációs alaplapok (olyan 2000-2010 magasságában), ahol több IDE kontroller is volt az alaplapra ráintegrálva, tudtak olyat, hogy a BIOS diszk boot sorrendet BIOS-ban lehetett felülbírálni. Ilyenkor a HW nem változott (azaz az IDE kontrollerek pont ugyanazon a címen maradtak), viszont hogy melyik a 80h a BIOS szerint, az változott a beállításoktól függően. Így megeshetett, hogy az első IDE kontroller címén elérhető első diszk nem pont a 80h volt.

Általában de, a hw-s RAID kártyák mind emulálják. Muszáj nekik, ettől lesznek hw-s RAID-ek. SCSI-ban nem vagyok biztos, olyant kb. 20 éve használtam utoljára.

Már miért lenne muszáj nekik? Ott a BIOS extension a kártyán, berakja magát az INT 13h-ra, aztán lesznek szívesek a boot loaderek azt használni. A DOS eleve az INT 13h-t használta, rendes modern OS alatt pedig amúgy is használhatatlan lenne egy ilyen IDE emuláció, ott nem nélkülözhető a rendes driver amúgy sem.

egyébként nem valószínű, hogy régi BIOS-os gépeken tényleg találsz NVME-t

Egy komplett "tick-tock" CPU generáció (Gen6 Skylake/Gen7 Kaby Lake) alaplapjain ott figyelnek az M.2 slotok, és a Gen8-ig nem volt szokásos az UEFI-only bootolás belső diszkről. Szóval de, vagy 2 éven át ez volt a helyzet.

> Szerintem a logikád hibás.

Nem, a Te logikád a hibás. Mindeféle, senki által nem használt, nyakatekert és elavult eset kezelését várod el egy olyan projekttől, aminek bevallottan sosem az volt a célja, hogy minden lehetséges konfigurációt támogasson, hanem az, hogy az estek 99.9999999%-át lefedő, legtipikusabb felállásra adjon egy faék egyszerű megoldást. Nem véletlenül Simpleboot a neve és nem Totalboot.

SZVSZ ha a Te eseted a nem tipikus felállás, akkor Te használj egy speckó és nyakatekert boot szoftvert. Az egyáltalán nem megoldás, hogy miattad mindenki mást is szopatunk egy túlbonyolított, 100 megás, agyhalott cuccossal, mint amilyen a grub. Szerény véleményem szerint.

> Egy komplett "tick-tock" CPU generáció (Gen6 Skylake/Gen7 Kaby Lake) alaplapjain ott figyelnek az M.2 slotok, és a Gen8-ig nem volt szokásos az UEFI-only bootolás belső diszkről. Szóval de, vagy 2 éven át ez volt a helyzet.

Azok mindegyikénél volt SATA emuláció (https://en.wikipedia.org/wiki/M.2). De ez egyébként sem a boot loader felelőssége, hanem firmware-é. Ha a firmware látja a diszket, akkor a boot loader is.

Szerintem nem érted a problémámat.

Az a problémám, hogy szemben a világ összes többi boot loaderével, amelyek BIOS módban standard módon az INT 13h-t használják a diszk elérésére, Te a Simpleboot projekt nevével ellentétben ezt a rém egyszerű (és nem utolsósorban: minden esetben jól működő) logikát felturbóztad, és beleraktad az IDE port direkt elérését, meg az elágazásokat, hogy akkor melyiket használd, és ezzel elérted, hogy bizonyos, nyilván elég obskúrus és a mai világban meglehetősen ritka esetekben még akár hasra is eshet.

Nem bántásnak szánom, csak próbálom megérteni: ez mire jó? Mert nyilván volt valami koncepciód, hogy miért vállaltad be ezt az extra elbonyolítást, ha már az volt a projekt célja, hogy egyszerű legyen.

> Az a problémám, hogy szemben a világ összes többi boot loaderével, amelyek BIOS módban standard módon az INT 13h-t használják a diszk elérésére

Nem, a Te problémád konkrétan az, hogy nem érted, hogy működik a Simpleboot. Na akkor mégegyszer: egyetlen egy esetben használ IO portot, amikor a BIOS kód 80h, és akkor is csak akkor, ha az ATA port elérhető. Minden más esetben BIOS INT 13h-t használ.

De idemásolom mégegyszer: "Most úgy van, ha olyan beállításod van, amit minden VM (qemu, VB, VMWare, bochs stb.) alapból támogat, és a mai modern masinák 90%-a hardveresen emulál, akkor gyors. Ha bármi mást használsz, akkor marad a lassú, de maximálisan támogatott BIOS."

> Nem bántásnak szánom, csak próbálom megérteni: ez mire jó?

Mint már korábban írtam, kb. 100x gyorsabb.

Ennek az oka pedig az, megintcsak idemásolom mégegyszer: "Minden szektorbetöltésnél long módból át kell kapcsolni compat módba, leállítani a lapozást, onnan protected módba, majd onnan valós módba, meghívni a BIOS interruptot, majd vissza protected módba, ott visszakapcsolni a virtuális címteret, aztán onnan vissza long módba. Izzad a proci közben rendesen."

Ráadásul a BIOS kizárólag az alacsonymemóriát képes elérni (1M alatt), tehát a betöltött adatokat még át is kell másolni a végleges helyükre (tipikusan 1M fölé). Az IO port ezzel szemben közvetlenül elérhető long mód alól (nincs semmiféle CPU mód váltás meg lapozás kikapcsolás-bekapcsolás MMU lapcímtár cache újratöltés overhead), és képes közvetlenül a magas memóriába írni, egyből a végleges helyre (tehát másolni sem kell az adatokat). Ennek az eredménye a 100x gyorsulás.

(És mielőtt még megkérdeznéd, a VM86 sem jobb, mivel long mód alól nem elérhető, csak protected mód alól. Protected módba akkor is át kell kapcsolni, és a lapozást akkor is ki kell kapcsolni, mert a long módú lapcímtáblák nem használhatók protected mód alól.)

( Zahy v | 2023. 07. 20., cs – 21:32 )

Szerkesztve: 2023. 07. 20., cs – 21:35

Csak FYI, most kipróbáltam egy netbookon. Azok elég jellemző tulajdonsága a kellően kicsi kijelző, meg az extrém gyenge hardver, és morbid BIOS-ok. Ez egy Acer Aspire One A150, majdnem a múlt évezredből, egy AMD C60-as, virtualizációt is támogató procival és 4 GB memóriával. Kijelző felbontása 1024 x 600. Nos a ma este letöltött verzió abban a pillanatban amikor valamit csinál induláskor a képernyővel, átvált villogó színes négyzetes valamivé. Próbáltam framebuffer sor nélkül, és 640x480x32-s kijelző előírással is, nem változott a dolog. (A BIOSa nem tud EFI módot, de az általam gyártott BIOS+UEFI módú FreeBSD-s pendrájv csont nélkül képes rajta bebootolni.)

Ez azért nem egy hibajegy, mert ennél többet nem nagyon tudok segíteni, de még egy verbose 3 tartalmú konfiggal is ezt csinálja.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Hmm, pedig nagyon jó lenne tudni, mit nem szeret. Biztos vagyok benne, hogy csak valami apró dolog nem tetszik neki.
Kérdés: ha adok többféle verziót, hajlandó lennél kipróbálgatni őket?

> Acer Aspire One A150, majdnem a múlt évezredből

Tudott az már VBE 2.0-át meg 64-bites módot? Úgy rémlik, az első x86_64-ek 2003 körül jelentek meg, nem régebbi ez annál?

> de az általam gyártott BIOS+UEFI módú FreeBSD-s pendrájv...

Ja, és milyen kernellel próbálkozol? A FreeBSD jelenleg lefagy, mert valamelyik boot infó, amit átadok nem tetszik neki, és nem ellenőrzi, amit kap, ezért page fault-ol (új gépen is, meg VM-ben is, nemcsak régin). Ez még nyomozás alatt.

SZERK: raktam fel új verziót. Beraktam egy csomó failsafe-t, így most akkor is mindenképp hiba nélkül kéne bootolnia, ha egyéltalán nincs VBE 2.0, valamint a biztonság kedvéért levettem a boot console felbontását 1024 x 768-ról 800 x 600-ra.

Az, hogy ez a BIOS miket tud, azt egyelőre nem kerestem ki. Mivel kb 5-10 perc kipróbálni egy új verziót, simán tudok próbálgatni. (Majd ha hazamegyek.) Amúgy változatlanul freebsd kernelt próbálok, de ezen a gépen sokkal hamarabb elhal, mint hogy egyáltalán bármit akarna csinálni.

Ja, egy pontatlanság a doksiban:

https://gitlab.com/bztsrc/simpleboot/-/blob/main/docs/ABI.md#bootstrapp…

On UEFI machines the very same 2nd stage file, called EFI/BOOT/BOOT.X64

ez a fájlnév ugyebár EFI/BOOT/BOOTX64.EFI

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

No kipróbáltam a legutolsót amit kb fél órája találtam. Pont ugyanúgy villódzik, annyi az extra, hogy lemorzézta, hogy tá - tá -tá - ti-ti.

Jav: amúgy InsydeH2O Setup Utility Rev 3.5 -nek mondja magát. Meg hogy System BIOS V1.12 VGA BIOS ATI Ver012.036.000.029.041054

Acer Aspire One 522, meg VGA Memory 256 MB

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Köszönöm a visszajelzést!

Soros port van ezen a csodamasinán? Rá tudsz kötni egy terminált vagy PC-t minicom-mal? (115200 baud, 8 bit, no parity, 1 stop bit)

Erős a gyanúm, hogy nem a VGA BIOS lesz az oka, egyrészről elvileg ez már VBE 2.0-ás, bőven elég a memóriája is, másrészről rengeteg failsafe-t tettem bele, mennie kell akkor is, ha egyáltalán nincs framebuffer. Másra gyanakszom, de ehhez kéne látni, milyen boot logot köp ki magából.

Sajnos ez ahhoz túl modern, hogy soros portja legyen. DSUB, 3 USB, Eth és egy HDMI. Azt majd még megnézem, hogy ha a HDMI-re rádugok egy nagyobb kijelzőt, attól jobb lesz-e (de ez biztosan nem most lesz). Illetve megnézhetem nagyobb felbontású külső VGA-csatlakozós kijelzővel is, bár nem emlékszem, hogy a BIOS-ban tudok-e a kijelzőkkel variálni.

Igazából abban bíztam, hogy a morzekód mond valamit, az korábban nem volt.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> Sajnos ez ahhoz túl modern, hogy soros portja legyen. DSUB, 3 USB, Eth és egy HDMI.

És a BIOS-ában van olyan opció, hogy USB soros emuláció?

No mind1, csináltam egy olyan verziót, ami egyáltalán nem kapcsolja a VBE-t, és tele van checkpoint logolással. Ha nem is látszik a boot log, arra jó, hogy lássuk, elindul-e. Van benne egy disk.img is az egyik példa kernel-el, bár ennek nem sok haszna, ha nem látszik a soros kimenet.
https://gitlab.com/bztsrc/simpleboot/-/issues/2

VGA text módja az van, ugye? Berakok egy VGA text mód putc-t, akkor majd látni lehet, mi a log.

És a BIOS-ában van olyan opció, hogy USB soros emuláció?

Szokott ilyen lenni? Én még nem találkoztam ezzel. Billentyűzetet, egeret, USB-s tárolóeszközöket már jó ideje támogatnak, de egyebet még nem láttam hagyományos BIOS esetén.

UEFI esetén már lehet esély a sikerre:

https://github.com/open-estuary/uefi/blob/master/OptionRomPkg/Bus/Usb/F…

No kipróbáltam az issue/2 -ben levő disk.img -t. Az eredmény: villogó képernyő, ellenben nem morzézik :-(

További érdekességek: az ebben a zip-ben levő simpleboot nem fut FreeBSD-n - ellentétben a főoldalról tölthető verzió igen. Az IMG-méret kiszámoló funkció szerintem hasznos, bár másodjára mindig megtaláltam a méretmegadáshoz szükséges opciókat is.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> No kipróbáltam az issue/2 -ben levő disk.img -t. Az eredmény: villogó képernyő, ellenben nem morzézik :-(

Érdekes, nem tudom, hogy villoghat a képernyő, mikor az a verzió nem is állít felbontást. Meg úgy egyáltalán nem is nyúl a framebuffer-hez.

> További érdekességek: az ebben a zip-ben levő simpleboot nem fut FreeBSD-n - ellentétben a főoldalról tölthető verzió igen.

Ez alatt mit értesz? Hibaüzenet? Egyébként mindegy, mert a főoldalról letölthető verzió a fontos, minden failsafe-t átraktam innen abba is.

> Az IMG-méret kiszámoló funkció szerintem hasznos, bár másodjára mindig megtaláltam a méretmegadáshoz szükséges opciókat is.

Igen, én is úgy voltam vele, hogy nekem sem kell, de nem volt nagy ügy belerakni (kb. 10 SLoC), és sokaknak hasznos lehet.

Egyébként a legújabb verzió is villogó képernyő? Ezt akkor szívás lesz kidebuggolni, ha semmilyen kimenetet nem látunk. Esetleg csinálok egy sor olyan verziót, amik különböző pontokon "lefagynak", és ha hajlandó vagy sorra bebootolni őket, akkor kiderül, hogy melyik kódrésznél kezdődik a villogás. Ez viszont nagyobb meló, nem tudom, vállalod-e.

A hiba az issue2-s simpleboot-ról. Az aktuális könyvtárbeli ez a speciállis, a ../simpleboot a "standard"

$ file simpleboot
simpleboot: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=1d80601627e7cd4df04e27bdaa0f376feeddd9b1, for GNU/Linux 4.4.0, not stripped
$ file ../simpleboot
../simpleboot: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6b5d5422e8f0bcd33b02762d117b270ddf80657e, for GNU/Linux 3.2.0, stripped
$ ./simpleboot
./simpleboot: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by ./simpleboot)
./simpleboot: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./simpleboot)
$ ../simpleboot
Simpleboot disk image tool, Copyright (c) 2023 bzt, MIT license
https://gitlab.com/bztsrc/simpleboot

 simpleboot [-v|-vv] [-k <name>] [-i <name>] [-s <mb>] [-p <mb>] \
   [-u <guid>] indir outfile
 simpleboot [-v|-vv] [-k <name>] [-i <name>] -b <device>

  -v, -vv     increase verbosity / validation
  -k <name>   set the default kernel filename (defaults to 'kernel')
  -i <name>   set the default initrd filename (by default none)
  -s <mb>     set the disk image size in Megabytes (defaults to 35M)
  -p <mb>     set the boot partition size in Megabytes (defaults to 33M)
  -u <guid>   set the boot partition's unique identifier (defaults to random)
  -b <device> no new image, make an already existing device bootable instead
  indir       use the contents of this directory for the boot partition
  outfile     output image file name

 Loader versions: edd7ba80 (x86)

$ 
 

Amúgy próbálgatni szívesen próbálok, semmi gond nincs vele.

A legutolsó verzió is ugyanúgy villódzik.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ja, én is agyfaszt kapok tőle. Egy tetszőleges függvénykönyvtárnál, még csak-csak megérteném, na de egy POSIX szabványos libc-nél???
<szarkazmus> Nagyon fontos a verziózás, mert a malloc, free, fopen meg a printf prototípusa és hívása folyton változhat a glibc-ben! </szarkazmus>

Megoldásként tartok egy VM-et ősrégi glibc-vel, és ott fordítom, így tutira jó mindenhol (az ősrégi glibc-ből úgysem kerül bele semmi a binárisba, csak a verziószáma). Próbáltam symbol alias-okat, de jujj. Csak Assembly-ben megoldható, és ott is folyton át kell írni a forrásodat, amikor frissül a glibc...

Ahhh, véletlenül azt a binárist raktam bele, amit a rendes gépemen fordítottam, és nem azt, amit VM-ben ősrégi glibc-vel... Bocs!

> A legutolsó verzió is ugyanúgy villódzik.

Na jó, de melyik? Amit legutóbb felraktam, abban van 16 lemezkép, ezek mind egyformák, kivéve, hogy különböző pontokon megakasztják a bootolást. Azt kellene tudni, melyik lemezképnél jelentkezik először a villódzás.

Érdemes a nyolcadikkal kezdeni. Ha ott villódzik, akkor jöhet a negyedik. Ha nem villódzik a nyolcadikkal, akkor következzen a tizenkettedik, és így tovább. Fokozatos közelítéssel (szukcesszív approximációval) hamarabb lehet eredmény. Hasonlóan célszerű csinálni, mint ahogy az A/D átalakítók egyes típusai működnek.

https://en.wikipedia.org/wiki/Successive-approximation_ADC

https://circuitdigest.com/article/how-does-successive-approximation-sar…

Én balga! Elfogadtam renard tanácsát. Nem kellett volna. (Szigorúan zárójelben jegyzem meg, hogy én is bináris kereséssel akartam végigmenni, azzal a különbséggel, hogy én elsőre a legelsőt akartam kipróbálni, és csak utána lépkedni így "felezve".)

Szóval rossz hírem van:

# history
     1    21:28    dd of=/dev/da0 bs=16M if=disk_008.img
     2    21:29    dd of=/dev/da0 bs=16M if=disk_004.img
     3    21:30    dd of=/dev/da0 bs=16M if=disk_002.img
     4    21:31    dd of=/dev/da0 bs=16M if=disk_001.img
     5    21:32    dd of=/dev/da0 bs=16M if=disk_000.img
 

Azaz már a 000-s imidzs is villódzik.

(Mellesleg nem vagy valahol BP közelében? Szívesen kölcsönadom az ominózus gépet egy-két hétre, ha van kedved vele vacakolni.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ugyanúgy az 5. lépésnél lett volna meg, mint most :-) Ha az első 2-ben van hiba, a te módszereddel 5 illetve 4 lépés, az enyémmel 1 illetve 5 lépés kellett volna. Azaz átlagban az enyém jobb :-D

De igazából arra akartam kilyukadni, hogy bennem a legesső sikertelen netbookos kisérlet óta motoszkál a fejemben, hogy valahol nagyon korán kezd el zűrölni a dolog, ezért akartam az első meglevővel kezdeni. De persze meggyőzött a matematika.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> Azaz már a 000-s imidzs is villódzik.

Ajaj, pedig az mindjárt a loader legelső utasításánál akasztja meg. Ezek szerint a probléma még a boot_x86.asm-ben van, nem is a loader_x86.c-ben. Gondolkodom mi lehet, mert túl sok mindent nem csinál, csak betölti a loader-t (szigorúan 1M alá), bekapcsolja a long mode-ot, és ráugrik az entry pointra. Asszem ebből is csinálok egy pár variációt, hogy kiderüljön, meddig jut.

> Mellesleg nem vagy valahol BP közelében? Szívesen kölcsönadom az ominózus gépet egy-két hétre, ha van kedved vele vacakolni.

Köszönöm, tényleg jó lenne, nagyon leegyszerűsítené a dolgot, de sajnos nem vagyok BP közelében, és mostanában nem is járok arrafelé :-(

Nem használom (mindössze egyetlen üzenetet jelenít meg a boot_x86.asm, azt is direkt MMIO-ba írással).

Egyébként ja, a sztringkiírás (https://www.ctyme.com/intr/rb-0210.htm) a legtöbb BIOS-ban bugos, mint állat, de leginkább nem is támogatott (alap BIOS-ban nem is volt ilyen). Nem véletlen, hogy egyetlen hivatalos boot szektor sem használja, csak a karakterkiírást (http://www.starman.vertcomp.com/asm/mbr/).

( dzsolt v | 2023. 07. 21., p – 22:23 )

Amikor először láttam ezt a szálat, meg akartam kérdezni, hogy mivel lenne ez jobb az efistub-nál amit most használok, de már látom :) A Backup indítás egyszerűsítésének lehetősége felvillanyozott, írtam hozzá egy ebuildet gentoo-ra:

sys-boot/simpleboot-9999.ebuild

# Copyright 2023 ......
# Distributed under the terms of the GNU General Public License v2

EAPI=7

inherit git-r3

DESCRIPTION="Dependency-free, suckless bootable disk image creator"
HOMEPAGE="https://gitlab.com/bztsrc/simpleboot"
EGIT_REPO_URI="${HOMEPAGE}.git"

LICENSE="MIT"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE="rebuild"

BDEPEND="
    rebuild? (
        dev-lang/fasm
        sys-devel/llvm
        sys-devel/lld
    )
"

src_prepare() {
    default
    # Nothing specific to prepare
}

src_compile() {
    if use rebuild; then
        emake -C src distclean || die "Failed to execute 'make -C src distclean'"
    fi
    emake -C src -j1 || die "Failed to build simpleboot"
}

src_install() {
    dobin src/simpleboot || die "Failed to install simpleboot"

    # Create the /etc/simpleboot directory if it does not exist
    dodir /etc/simpleboot

    # Copy the example/simpleboot.cfg as simpleboot.cfg to /etc/simpleboot
    insinto /etc/simpleboot
    newins example/simpleboot.cfg simpleboot.cfg.example || die "Failed to copy simpleboot.cfg"
}

pkg_config() {
    einfo "Creating Simpleboot configuration file in /etc/simpleboot directory..."
    # Simpleboot configuration file creation in the /etc/simpleboot directory
    local simpleboot_cfg="${EROOT}/etc/simpleboot/simpleboot.cfg"
    local kernel_list=("${EROOT}"/boot/vmlinuz-*)

    # Find the latest and oldest kernel version
    local latest_kernel_version=""
    local oldest_kernel_version=""
    for kernel_file in "${kernel_list[@]}"; do
        kernel_version=$(basename "${kernel_file}" | cut -d- -f2-)
        if [[ -z "${latest_kernel_version}" ]] || [[ "${kernel_version}" > "${latest_kernel_version}" ]]; then
            latest_kernel_version="${kernel_version}"
        fi
        if [[ -z "${oldest_kernel_version}" ]] || [[ "${kernel_version}" < "${oldest_kernel_version}" ]]; then
            oldest_kernel_version="${kernel_version}"
        fi
    done

    echo "# New" > "${simpleboot_cfg}"
    echo "verbose 2" >> "${simpleboot_cfg}"
    echo "kernel vmlinuz-${latest_kernel_version}" >> "${simpleboot_cfg}"
    echo "module initramfs-${latest_kernel_version}.img" >> "${simpleboot_cfg}"
    echo "framebuffer 1920 1080 32" >> "${simpleboot_cfg}"
    echo "bootsplash #af00d7 splash.tga" >> "${simpleboot_cfg}"

    echo "" >> "${simpleboot_cfg}"

    echo "# Backup" >> "${simpleboot_cfg}"
    echo "verbose 3" >> "${simpleboot_cfg}"
    echo "backupkernel vmlinuz-${oldest_kernel_version}" >> "${simpleboot_cfg}"
    echo "backupmodule initramfs-${oldest_kernel_version}.img" >> "${simpleboot_cfg}"
    echo "backupframebuffer 640 480 32" >> "${simpleboot_cfg}"
    echo "backupbootsplash #af00d7 backup_splash.tga" >> "${simpleboot_cfg}"

    # Print the content of the configuration file
    einfo "Content of Simpleboot configuration file:"
    cat "${simpleboot_cfg}"

    # Check if the configuration file exists in /etc/simpleboot
    if [[ -e "${EROOT}/etc/simpleboot/simpleboot.cfg" ]]; then
        einfo "Configuration file successfully copied to /etc/simpleboot."
    else
        ewarn "Failed to copy configuration file to /etc/simpleboot."
    fi
}

A használata: emerge -av sys-boot/simpleboot vagy USE="rebuild" sys-boot/simpleboot. Ez utóbbi a distclean-t valósítja meg. Ezen túl az emerge --config sys-boot/simpleboot kikeresei a két legutóbbi bejegyzést a /boot alatt és elmenti a /etc/simpleboot/simpleboot.cfg-ba a találtakat és a régebbit beállítja backupnak. 

Eddig működik is, de az optimalizációm nem teljes és a dracut initrd-je túl nagynak bizonyul, mert miután másolom a cfg-t a boot-ba és elindítom, akkor az eredmény:

$ simpleboot -vv ./ /simpleboot.img
Adding: initramfs-6.3.5-gentoo-dist.img                                       
simpleboot: not enough space

Hely van bőven, nem az a baj! A fordítás gcc-vel megy, az llvm és az fasm csak akkor kerül képbe ha a rebuild jelző be van állítva.

Az ebuild használható, hátha valaki kipróbálná, az initrd-n még dolgozom, mert a firmware csomagot érzésem szerint teljesen belerakja a dracut. Ha esetleg van valami a dracut helyett ami ajánlott és használjátok,  szívesen kipróbálnám.

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

> Amikor először láttam ezt a szálat, meg akartam kérdezni, hogy mivel lenne ez jobb az efistub-nál amit most használok, de már látom :)

Plusz az efistub nem tud normál ELF meg PE kerneleket tölteni Multiboot2-vel ;-)

> írtam hozzá egy ebuildet gentoo-ra:

Nagyszerű, köszönöm! Ezt érdemes lenne valahogy berakni a repóba, ha hozzájárulsz. Attribution requirements?

> az llvm és az fasm csak akkor kerül képbe ha a rebuild jelző be van állítva.

Tökéletes!

> Hely van bőven, nem az a baj!

Félreérted, a generálandó lemezképen nincs elég hely! Alapból 33 Mb-sre csinálja (a lehető legkissebb FAT32, ami létrehozható). Add meg "-p <mb>" kapcsolóval megabájtban, hogy mekkora boot partíciót szeretnél. (Ez azért kell, mert előre, még a másolás elkezdése előtt tudni kell, mekkora területet fog lefoglalni a FAT tábla.)

> Plusz az efistub nem tud normál ELF meg PE kerneleket tölteni Multiboot2-vel ;-)

Úgy értettem,hogy nekem mivel lenne jobb :) A backup egyszerűbb indítása már előny!

> Nagyszerű, köszönöm! Ezt érdemes lenne valahogy berakni a repóba, ha hozzájárulsz. Attribution requirements?

Előbb legyen egy 0.0.1-es verzió, mint mérföldkő és mellette a -9999 git verzió, aztán mehet. Csak git verzió azért nem jó, mert ha épp egy olyan pillanatban készül bináris ami eltörik, nincsen hová visszalépni és úgy sosem kerülhet be a hivatalos repóba. 

> Félreérted, a generálandó lemezképen nincs elég hely! Alapból 33 Mb-sre csinálja (a lehető legkissebb FAT32, ami létrehozható). Add meg "-p <mb>" kapcsolóval megabájtban, hogy mekkora boot partíciót szeretnél. (Ez azért kell, mert előre, még a másolás elkezdése előtt tudni kell, mekkora területet fog lefoglalni a FAT tábla.)

Ahh... :) Szóval csak optimalizálni kell valahogyan az initrd generálást, a dracut legutóbbi initrd-je 60+ Mb.

 

Épp dolgozom egy minimalizált hypervisoron gentoo alapokon. A képességei az összes járatos konténer technika és virtualizáció telepítésének  lehetősége, de választhatóan: egyik vagy másik konténer, minden konténer akár, virtualizációval vagy nélküle. A telepítőt írom éppen és mivel a minimalizált helyfoglalás a célom, a projekted nagyon is beleillik! Egyelőre a rootfs-el voltam elfoglalva, kicsit ránézek az initrd generálásra, mert ez eddig fel sem tűnt, hogy ekkora bazi nagy és ezt a szálat követem. 

Szerk: közben látom, hogy 6 órája megszületett a 0.0.1-es verzió, így a módosított ebuild a következő:

# Copyright 2023 .....
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Dependency-free, suckless bootable disk image creator"
HOMEPAGE="https://gitlab.com/bztsrc/simpleboot"

LICENSE="MIT"
SLOT="0"
IUSE="rebuild"

# If PV starts with 9999, use git-r3 for version control
if [[ ${PV} == 9999* ]]; then
    inherit git-r3
    EGIT_REPO_URI='https://gitlab.com/bztsrc/simpleboot.git'
else
    inherit vcs-snapshot
    EGIT_COMMIT="28164466"
    SRC_URI="https://gitlab.com/bztsrc/simpleboot/-/archive/${EGIT_COMMIT}/simpleboot-${EGIT_COMMIT}.tar.gz -> ${P}.tar.gz"
    KEYWORDS="~amd64 ~x86"
fi

BDEPEND="
    rebuild? (
        dev-lang/fasm
        sys-devel/llvm
        sys-devel/lld
    )
"

src_prepare() {
    default
    # Nothing specific to prepare
}

src_compile() {
    if use rebuild; then
        emake -C src distclean || die "Failed to execute 'make -C src distclean'"
    fi
    emake -C src -j1 || die "Failed to build simpleboot"
}

src_install() {
    dobin src/simpleboot || die "Failed to install simpleboot"

    # Create the /etc/simpleboot directory if it does not exist
    dodir /etc/simpleboot

    # Copy the example/simpleboot.cfg as simpleboot.cfg to /etc/simpleboot
    insinto /etc/simpleboot
    newins example/simpleboot.cfg simpleboot.cfg.example || die "Failed to copy simpleboot.cfg"
}

pkg_config() {
    einfo "Creating Simpleboot configuration file in /etc/simpleboot directory..."
    # Simpleboot configuration file creation in the /etc/simpleboot directory
    local simpleboot_cfg="${EROOT}/etc/simpleboot/simpleboot.cfg"
    local kernel_list=("${EROOT}"/boot/vmlinuz-*)

    # Find the latest and oldest kernel version
    local latest_kernel_version=""
    local oldest_kernel_version=""
    for kernel_file in "${kernel_list[@]}"; do
        kernel_version=$(basename "${kernel_file}" | cut -d- -f2-)
        if [[ -z "${latest_kernel_version}" ]] || [[ "${kernel_version}" > "${latest_kernel_version}" ]]; then
            latest_kernel_version="${kernel_version}"
        fi
        if [[ -z "${oldest_kernel_version}" ]] || [[ "${kernel_version}" < "${oldest_kernel_version}" ]]; then
            oldest_kernel_version="${kernel_version}"
        fi
    done

    echo "# New" > "${simpleboot_cfg}"
    echo "verbose 2" >> "${simpleboot_cfg}"
    echo "kernel vmlinuz-${latest_kernel_version}" >> "${simpleboot_cfg}"
    echo "module initramfs-${latest_kernel_version}.img" >> "${simpleboot_cfg}"
    echo "framebuffer 1920 1080 32" >> "${simpleboot_cfg}"
    echo "bootsplash #af00d7 splash.tga" >> "${simpleboot_cfg}"

    echo "" >> "${simpleboot_cfg}"

    echo "# Backup" >> "${simpleboot_cfg}"
    echo "verbose 3" >> "${simpleboot_cfg}"
    echo "backupkernel vmlinuz-${oldest_kernel_version}" >> "${simpleboot_cfg}"
    echo "backupmodule initramfs-${oldest_kernel_version}.img" >> "${simpleboot_cfg}"
    echo "backupframebuffer 640 480 32" >> "${simpleboot_cfg}"
    echo "backupbootsplash #af00d7 backup_splash.tga" >> "${simpleboot_cfg}"

    # Calculate the size of the latest kernel file
    local latest_kernel_file="${EROOT}/boot/vmlinuz-${latest_kernel_version}"
    local latest_kernel_size=0
    if [[ -f "${latest_kernel_file}" ]]; then
        latest_kernel_size=$(stat -c %s "${latest_kernel_file}")
    fi

    # Calculate the size of related initramfs and splash files
    local initramfs_file="${EROOT}/boot/initramfs-${latest_kernel_version}.img"
    local initramfs_size=0
    if [[ -f "${initramfs_file}" ]]; then
        initramfs_size=$(stat -c %s "${initramfs_file}")
    fi

    local splash_file="${EROOT}/boot/splash.tga"
    local splash_size=0
    if [[ -f "${splash_file}" ]]; then
        splash_size=$(stat -c %s "${splash_file}")
    fi

    # Calculate the total size of the latest files
    local latest_total_size=$((latest_kernel_size + initramfs_size + splash_size))

    # Calculate the size of the oldest kernel file
    local oldest_kernel_file="${EROOT}/boot/vmlinuz-${oldest_kernel_version}"
    local oldest_kernel_size=0
    if [[ -f "${oldest_kernel_file}" ]]; then
        oldest_kernel_size=$(stat -c %s "${oldest_kernel_file}")
    fi

    # Calculate the size of related backup initramfs and splash files
    local backup_initramfs_file="${EROOT}/boot/initramfs-${oldest_kernel_version}.img"
    local backup_initramfs_size=0
    if [[ -f "${backup_initramfs_file}" ]]; then
        backup_initramfs_size=$(stat -c %s "${backup_initramfs_file}")
    fi

    local backup_splash_file="${EROOT}/boot/backup_splash.tga"
    local backup_splash_size=0
    if [[ -f "${backup_splash_file}" ]]; then
        backup_splash_size=$(stat -c %s "${backup_splash_file}")
    fi

    # Calculate the total size of the oldest files
    local oldest_total_size=$((oldest_kernel_size + backup_initramfs_size + backup_splash_size))

    # Calculate the overall total size
    local overall_total_size=$((latest_total_size + oldest_total_size))

    # Print the sizes of the latest and oldest files
    einfo "Size of the latest files: ${latest_total_size} bytes"
    einfo "Size of the oldest files: ${oldest_total_size} bytes"

    # Check if the total size is too large
    if [[ ${overall_total_size} -gt 33000000 ]]; then
        ewarn "Total size of related files is too large (${overall_total_size} bytes). The generated image exceeds the allowed 33 MB size."
    fi

    # Print the content of the configuration file
    einfo "Content of Simpleboot configuration file:"
    cat "${simpleboot_cfg}"

    # Check if the configuration file exists in /etc/simpleboot
    if [[ -e "${EROOT}/etc/simpleboot/simpleboot.cfg" ]]; then
        einfo "Configuration file successfully copied to /etc/simpleboot."
    else
        ewarn "Failed to copy configuration file to /etc/simpleboot."
    fi
}

ezt kell menteni simpleboot-9999.ebuild néven majd másolni a simpleboot-0.0.1.ebuild fájlba. Ezen a ponton a 28164466 Commit lesz a 0.0.1-es verzió amíg nem lesz egy hivatalos letölthető 0.0.1 kiadás. Egyúttal a --config kiírja a konzolra az méreteket is és figyelmeztet ha a méret túl nagy.
A telepítés menetét is beleteheted a doksiba ha gondolod.

Saját repo létrehozása után a fájlokat a repo alatt a sys-boot/simpleboot mappába kell helyezni, majd

ebuild simpleboot-0.0.1.ebuild digest

parancs ami létrehozza a Manifest fájlt. Ezután a 

echo "sys-boot/simpleboot ~amd64" >> /etc/portage/package.accept_keywords/sys-boot

engedélyezi a nem stabilnak kikiáltott csomagunkat és így telepíthető a

emerge -pv sys-boot/simpleboot
emerge -pv =sys-boot/simpleboot-9999
USE="rebuild" emerge -pv sys-boot/simpleboot

parancsok valamelyikével (a -p elhagyása után települ, így csak megmutatja, hogy mi történne ha...)

PS: az EGIT_COMMIT="28164466" helyett jobban tetszene egy kiadott verzió, egyszerűbben karbantartható az ebuild, mert akkor nem commit alapján kezeljük a verziót, hanem kiadás alapján.

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Jól érted, de a tervezett rootfs jelenleg 35MB, nevetséges lenne egy 130MB-s boot :) A dracut hostonly rögtön 12800K környékére csökkentette az initrd-t, majd még optimalizálok amit lehet! Közben az ebuild is változott, hozzáadtam ezt:

    # Calculate the overall total size in MB and round up to the nearest integer
    local rounded_space_mb=$(( (overall_total_size + 999999) / 1000000 ))

    # Check if the total size is too large
    if [[ ${overall_total_size} -gt 33000000 ]]; then
        ewarn "Total size of related files is too large (${overall_total_size} bytes). The generated image exceeds the allowed 33 MB size (by default)."
        einfo "Command usage example: simpleboot -vv -p ${rounded_space_mb}MB ./ simpleboot.img"
    fi

így példaként kiírja az épp elégséges -p értéket egész MB-re kerekítve (már nem tudom szerkeszteni az előző hozzászólásom).

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

> nevetséges lenne egy 130MB-s boot :)

Igen... amikor a partíciólétrehozót írtam, azért erősen elgondolkodtam, hogy 1M az elvárt alignment hivatalosan GPT esetén. Ebbe bőven beleférne egy komplett MS-DOS 5.0 oprendszer...

> Közben az ebuild is változott, hozzáadtam ezt:

Csak egy apróság, MiB-ben számold (1000000 helyett 1048576). Erre nem is gondoltam, hogy kiírható az "MB", de tényleg működik így is az atoi miatt, és olvashatóbb.

Egyébként egyelőre beraktam az eredeti ebuild-edet, majd ha lesz végleges verzió, szólj, és frissítem!
https://gitlab.com/bztsrc/simpleboot/-/tree/main/distrib

> Csak egy apróság, MiB-ben számold (1000000 helyett 1048576). Erre nem is gondoltam, hogy kiírható az "MB", de tényleg működik így is az atoi miatt, és olvashatóbb.

Megtörtént:

    # Calculate the overall total size in MB and round up to the nearest integer
    local rounded_space_mib=$(( (overall_total_size + 1048575) / 1048576 ))

    # Check if the total size is too large
    if [[ ${overall_total_size} -gt 34603008 ]]; then
        ewarn "Total size of related files is too large (${overall_total_size} bytes). The generated image exceeds the allowed 33 MiB size (by default)."
        einfo "Command usage example: simpleboot -vv -p ${rounded_space_mib} ./ simpleboot.img"
    else
        einfo "Command usage example: simpleboot -vv ./ simpleboot.img"
    fi

> Egyébként egyelőre beraktam az eredeti ebuild-edet, majd ha lesz végleges verzió, szólj, és frissítem!
> https://gitlab.com/bztsrc/simpleboot/-/tree/main/distrib

Láttam, így fedeztem fel, hogy van 0.0.1-es deb-ed. Végleges ebuild akkor lesz ha lesz 0.0.1-es kiadás, hogy ne commit-ra támaszkodjunk, mert akkor minden nagyobb változáskor kell az ebuild tartalmát is változtatni. Ha van kiadás, onnantól ha nem változnak a függőségek és a Makefile, csak az ebuild nevében kell a verziószámot megváltoztatni és már aktuális is. Ehhez az ebuilden nem sokat kell változtatni, csak a commit helyett a megfelelő verzió tömörítvényét kell letölteni. Figyelem a repódat, ha látom, hogy van, módosítok!

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Kis módosítás: a hibaüzenet "no space left on boot partition" lett, másrészről beleraktam, hogyha nincs megadva a "-p" vagy "-d" kapcsoló, akkor alapból számolja ki a partíció méretét a megadott könyvtár tartalma alapján. Szóval erre már nincs többé szükség. (Ha meg van adva a "-p", akkor a partíció pont akkora lesz, így ilyenkor még megjelenhet ez a hibaüzenet.)

Mindjárt próbálom, de kérlek csinálj egy valami release-t, azzal kész lenne az ebuild.

Szerk:

félreértettem! Csak egy release kell és akkor ez a végleges ebuild:
sys-boot/simpleboot-9999.ebuild 

# Copyright 2023 .....
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Dependency-free, suckless bootable disk image creator"
HOMEPAGE="https://gitlab.com/bztsrc/simpleboot"

LICENSE="MIT"
SLOT="0"
IUSE="rebuild"

# If PV starts with 9999, use git-r3 for version control
if [[ ${PV} == 9999* ]]; then
    inherit git-r3
    EGIT_REPO_URI='https://gitlab.com/bztsrc/simpleboot.git'
else
    SRC_URI="https://gitlab.com/bztsrc/simpleboot/-/archive/${PV}/simpleboot-${PV}.tar.gz -> ${P}.tar.gz"
    KEYWORDS="~amd64 ~x86"
fi

BDEPEND="
    rebuild? (
        dev-lang/fasm
        sys-devel/llvm
        sys-devel/lld
    )
"

src_prepare() {
    default
    # Nothing specific to prepare
}

src_compile() {
    if use rebuild; then
        emake -C src distclean || die "Failed to execute 'make -C src distclean'"
    fi
    emake -C src -j1 || die "Failed to build simpleboot"
}

src_install() {
    dobin src/simpleboot || die "Failed to install simpleboot"

    # Create the /etc/simpleboot directory if it does not exist
    dodir /etc/simpleboot

    # Copy the example/simpleboot.cfg as simpleboot.cfg to /etc/simpleboot
    insinto /etc/simpleboot
    newins example/simpleboot.cfg simpleboot.cfg.example || die "Failed to copy simpleboot.cfg"
}

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

> Csak egy release kell és akkor ez a végleges ebuild

Erre miért van szükség? Az SRC_URI-ban simán lehetne a PV "main".

Illetve most alaposan átnéztem pontról pontra, és találtam még egy hibát:

> # Copy the example/simpleboot.cfg as simpleboot.cfg to /etc/simpleboot

Ez így biztos nem jó. A simpleboot.cfg-nak semmi keresnivalója az /etc-ben. Ennek abba a könyvtárba kell kerülnie, amiből a lemezképed gyártod, és majd bootoláskor fogja a loader használni. Kb. mint a /boot/grub/grub.cfg (bár ott nyakatekert, hogy mikor ki használja...) Illetve semmi értelme az example/simpleboot.cfg-t másolni, mert az úgy működésképtelen, csak a szintakszist demózza (meg lustáknak van, hogy legyen honnan copy'n'paste-elni).

> Erre miért van szükség? Az SRC_URI-ban simán lehetne a PV "main".

Ha van egy csak git-re alapozott csomagod, az mindig fejlesztői állapotban van és nem nevezhető stabilnak ha egyetlen kiadott verziója sincsen! A release egy rögzített állapot! Ez még ha lehetnek is hibái, egy stabil amibe új funkció már nem kerül csak hibajavítások. Ha a git-ről telepített 9999-es nek nevezett verziót lehet csak elérni az nem tekinthető állandónak és így stabilnak sem. Ebben az esetben nem lesz a gentoo stabil ágának sem a része soha. Ez igaz bármely szoftverre. Valamiért a deb verziót is elnevezted 0.0.1-nek.

> Ez így biztos nem jó. A simpleboot.cfg-nak semmi keresnivalója az /etc-ben. Ennek abba a könyvtárba kell kerülnie, amiből a lemezképed gyártod, és majd bootoláskor fogja a loader használni. Kb. mint a /boot/grub/grub.cfg (bár ott nyakatekert, hogy mikor ki használja...) Illetve semmi értelme az example/simpleboot.cfg-t másolni, mert az úgy működésképtelen, csak a szintakszist demózza (meg lustáknak van, hogy legyen honnan copy'n'paste-elni).

Ez benne maradt véletlenül, korábban arra gondoltam, hogy automatizálva a telepítést lehessen egy meghatározott stabil kernelt backup-ként használni (jellemzően egy kernel frissítés utáni simpleboot paranccsal) és egy időben frissebbet pedig mint elsődlegest. Ezeket a /boot mappában ellenőrizte az ebuild és abból gondoltam generáltatni a cfg alapján az image-t. Ehhez a /etc alatt gondoltam az állapotot rögzíteni és az example mellé generált cfg-t használni ahol az example a puska, mint sok más konfig esetében is. Ez már azért sem volt jó, mert a programod a mappa teljes tartalmával dolgozik, a /boot alatt meg lehet több is időnként, mint ez a két verzió, így mindenképpen másolgatni kell a fájlokat valahová a cfg-vel együtt. Ez az én félreértésem volt, természetesen nincs ebben az értelemben semmi keresnivalója a /etc alatt, hanem valahová a csomag dokumentációjába való. A pkg_config rész törlésével egy időben kellett volna törölnöm, de elfelejtettem, így most ez a maradék a végleges, ahol ha lesz release, akkor kezeli, ha nem akkor pedig az aktuális git verziót telepíti a fájl nevétől függően. Fentebb írtam, hogyan működik az ebuild esetében ez.

# Copyright 2023 .....
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Dependency-free, suckless bootable disk image creator"
HOMEPAGE="https://gitlab.com/bztsrc/simpleboot"

LICENSE="MIT"
SLOT="0"
IUSE="rebuild"

# If PV starts with 9999, use git-r3 for version control
if [[ ${PV} == 9999* ]]; then
    inherit git-r3
    EGIT_REPO_URI='https://gitlab.com/bztsrc/simpleboot.git'
else
    SRC_URI="https://gitlab.com/bztsrc/simpleboot/-/archive/${PV}/simpleboot-${PV}.tar.gz -> ${P}.tar.gz"
    KEYWORDS="~amd64 ~x86"
fi

BDEPEND="
    rebuild? (
        dev-lang/fasm
        sys-devel/llvm
        sys-devel/lld
    )
"

src_prepare() {
    default
    # Nothing specific to prepare
}

src_compile() {
    if use rebuild; then
        emake -C src distclean || die "Failed to execute 'make -C src distclean'"
    fi
    emake -C src -j1 || die "Failed to build simpleboot"
}

src_install() {
    dobin src/simpleboot || die "Failed to install simpleboot"
}

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

> Ha a git-ről telepített 9999-es nek nevezett verziót lehet csak elérni az nem tekinthető állandónak és így stabilnak sem.

úgy látszik, túlságosan hozzászoktam a rolling release disztrókhoz :-) Rendben, lesz release, majd szólok. (Be akarom fejezni a RPi támogatást meg a FreeBSD-s ügynek pontot teszek a végére, utánna).

> Valamiért a deb verziót is elnevezted 0.0.1-nek.

Csak mert ott kötelező feltüntetni valamit a fájlnévben.

> így most ez a maradék a végleges, ahol ha lesz release, akkor kezeli, ha nem akkor pedig az aktuális git verziót telepíti a fájl nevétől függően.

Remek! Nagyon köszönöm! Az ebuild-et frissítettem (annyit nyúltam csak bele, hogy rakja fel a man page-t, mert időközben lett olyanja is, illetve a kommentet átírtam, mert MIT-s, nem GPL), téged pedig megneveztelek contributor-nak! Köszönöm!

> úgy látszik, túlságosan hozzászoktam a rolling release disztrókhoz :-)

Azért a gentoo elég rolling szerintem :)

> Rendben, lesz release, majd szólok.

Csak másold az ebuildet és nevezd át, a simpleboot-9999.ebuild marad és lesz mellette egy simpleboot-valamiverzió.ebuild ahol a valamiverzió lesz amit te kiadtál verziónak. Ha lesz újabb, akkor megint másol/átnevez.

> Az ebuild-et frissítettem (annyit nyúltam csak bele, hogy rakja fel a man page-t, mert időközben lett olyanja is, illetve a kommentet átírtam, mert MIT-s, nem GPL)

az ebuild maga az GPL, a te licenced alatta van a szkriptben, az vonatkozik az alkalmazásra.

DESCRIPTION="Dependency-free, all-in-one OS loader and bootable disk image creator."
HOMEPAGE="https://gitlab.com/bztsrc/simpleboot"
LICENSE="MIT"

> téged pedig megneveztelek contributor-nak!

ezt kihagyhattad volna :) nem tartok rá igényt (ezért pontoztam ki).

> Köszönöm!

Szívesen!

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Az EFI stub bootot én is szeretem, amikor a kernelbináris (vminuz-linux) közvetlenül bootol el UEFI-ból. Kár, hogy csak Gentoo-n tudom használni, Arch/Artix-on az initramfs bezavar neki, és nem tudtam működésre bírni soha, így systemd-bootot használok, aminek persze semmi köze nincs a systemd-hez, igazából a Gummiboot projekt átnevezve. A Void Linux sajnos rákényszeríti a bloat GRUB-ot a felhasználóra, ahogy sok mainstream disztró, feleslegesen. Bár néha nem felesleges a GRUB, ha valami egzotikus fájlrendszerről kell bootolni, vagy RAID-ről, de átlag desktop usernél ez rikta.

Viszont azt elismerem, hogy az EFI stub boot nem játszik, ha a felhasználónak szüksége van extrákra, kernel parancssor szerkesztése, btrfs snapshotok bebootolása, stb..

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Zahy v | 2023. 07. 24., h – 09:42 )

Látom, hogy RPi3 (4)-hez is jelentek meg módosítások. Ugye tudod, hogy egy ideje a málna tud UEFI környezetet is használni? ( lásd https://github.com/pftf/RPi4 - vagy RPi3 ) Pl. ha valaki játszani (használni) szeretne VMware ESXi -t málnán, akkor ahhoz UEFI bootot kell beállítani.

Értelemszerűen akkor a szabvány elnevezésű boot loader: EFi / BOOT / BOOTAA64.EFI

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ja, csak épp értelme nem sok, eléggé használhatatlan. Még egy PC-s erőgépen is tetves lassú az UEFI, hát még egy pici RPi boardon...
(Összehasonlításképp: qemu + kvm, image ugyanaz, a kernel csak lekapcsolja a qemu-t, time-al mérve. TianoCore-al egy futtatás legalább 6 másodperc. BIOS-al indítani ugyanez kb. 0.2 másodperc... legalább 30-szoros különbség, nagyon nem mindegy!)

Képzeld el ezt PI-n! Ha valaki Multiboot2-vel akarna bootolni valamit RPi-n, akkor fel kell pakolnia sokmegányi UEFI firmware-t, megint sokmegányi arm-uefi GRUB-ot (ebből egy lenne a BOOTAA64.EFI fájl), ami majd Multiboot2-al meghívja a kernelét. Éveket várhat, mire elindul a Pi-je...

Ezért csináltam meg a RPi támogatást, mert Simpleboot-al mindez kevesebb 64K-t igényel, és kevesebb, mint 1 másodperc alatt bootolja ugyanazt a kernelt.

A teljesség kedvéért FYI, található a github-on pár hasonló kezdeményezés, csak sajnos nem az igaziak. Speciális kernel formátumot igényelnek (pl ez https://github.com/libreliu/aarch64-boot), csak Multiboot1-et tudnak és az sem igazán kompatíbilis (pl https://github.com/jncronin/rpi-boot/), vagy épp olyan bloatedek, mint a GRUB, U-boot vagy a limine. Olyan, ami egyszerűen használható, és sima, nem speciális ELF kernelt képes bebootolni Multiboot2-vel, na olyan tudtommal nem volt még.

( bzt | 2023. 07. 24., h – 20:36 )

Rossz hír FreeBSD fronton. Most már látom, hogy működik, meg is tudnám csinálni, de sajnos rettenetesen túl van bonyolítva. Ez tényleg egy dinamikus futtatható, ami azt jelenti, hogy speciális címre kell betölteni, relokálni kell, interpretert kell a számára biztosítani (szkriptértelmezőkkel egyetemben), és gyakorlatilag egy komplett linkerre van szükség a betöltéséhez.

Mindezt figyelembe véve arra jutottam, hogy egy komplett linker implementálása a boot loaderbe egyszerűen nem fér bele a Simpleboot filozófiájába. Sajnálom, a jegyet "nem lesz implementálva" státusszal lezártam https://gitlab.com/bztsrc/simpleboot/-/issues/1#note_1485900127

Sajnálattal hallom, de azért eléggé logikus lépés. (De kezdem érteni, hogy miért van boot, zfsboot, gptboot és gptzfsboot és ezen kívül loader és loader.efi FreeBSD-n - és ez csak az i386 és az Amd64 platform. Hol van még az Arm, az Arm64 (khmm Aarch64), meg a RiscV, meg a többi architektúra.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( bzt | 2023. 07. 26., sze – 11:54 )

Sajnos az OpenBSD bootolás sem megoldható.

Technikailag nincs ugyan semmi akadálya, sokkal átgondoltabb, mint a FreeBSD-é. Nincs szükség interpreterre, és a dinamikusan linkelni sem kell, "freestanding"-nek lett fordítva, pont ahogy egy kernelhez illik. A gond itt ellenben az, hogy az ELF fejléce egy az egyben úgy néz ki, mint bármely 64-bites futtathatóé, holott a belépési pontja egyáltalán nem long módú SysV ABI, ahogy azt a fejléc állítja.

Őszintén nem értem, minek regisztráltattak be OpenBSD ABI azonosítót az ELF formátumba, ha nem is használják. Pedig az alapján el lehetne dönteni, hogy a belépési pontot nem szabványosan, hanem 32-bites protected módban, speciális veremparaméterekkel kell hívni. De igazából bárminek örülnék, egyetlen bit eltérés a normál 64-bites ELF fejléctől már elégséges lenne. A FreeBSD kernele az legalább becsülettel FreeBSD OS/ABI-t jelez az ELF fejlécben, kár, hogy ott meg mást bonyolítottak túl.

Szóval csalódás, marad a Linux meg a Multiboot2. :-( (Pedig őszintén szólva, a BSD-ket összeségében sokkal jobban megírt kernelnek tartom, mint a Linuxot. És mégis, a Linux kernel freestanding és egyértelműen beazonosítható, a BSD-k meg nem.)

( Zahy v | 2023. 07. 26., sze – 23:08 )

No tesztelem az Acer netbook-on a második készletet.

disk_009.img - még jó a képernyő

disk_010.img - villódzik a képernyő

disk_011.img - villódzik a képernyő

disk_012.img - villódzik a képernyő és morzézik (tá-tá-tá-ti-ti) - ellenben ezt (fütyülés) nem tudom stabilan reprodukálni - de mivel nem is ez a lényeg, csak érdekességképpen írtam

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Köszönöm!

Ezek szerint nem tudja a laptopod procija a long módot?

| disk_009.img |               125 | EFER MSR configured                        |
| disk_010.img |               127 | long mode enabled                          |

A kérdéses sorok https://gitlab.com/bztsrc/simpleboot/-/blob/main/src/boot_x86.asm#L125:

122            rdmsr
123            bts         eax, 8                  ; enable long mode
124            wrmsr
125            mov         eax, 0C0000011h         ; clear EM, MP (enable SSE) and WP
126            mov         cr0, eax                ; enable paging with cache disabled
127            lgdt        [510h]                  ; read 80 bit address (16+64)

Mint látszik, képernyőhöz egyáltalán nem nyúl ez a pár sor, csak két rendszerregisztert állít. Gondolom nincs a procidnak EFER MSR regisztere, és ezért nem is tudja beállítani, így amikor CR0-ban engedélyezem a lapozást, nem tudja a 64-bites laptáblákat értelmezni, 32-bitesnek próbálja feldolgozni és ennek ilyen villódzás az eredménye.

Megnézem ki tudok-e csikarni még pár bájtot egy CPU family >= 6 ellenőrzésre.

Köszönöm a visszajelzést!

De tudja, ott van az AMD Features sor legvégén az LM (ez a natív 64-bites FreeBSD bootüzenet elején látszik.)

 

CPU: AMD C-60 APU with Radeon(tm) HD Graphics (997.53-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x500f20  Family=0x14  Model=0x2  Stepping=0
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x802209<SSE3,MON,SSSE3,CX16,POPCNT>
  AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
  AMD Features2=0x35ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,IBS,SKINIT,WDT>
  SVM: NP,NRIP,NAsids=8
  TSC: P-state invariant, performance statistics

 

(Ezt az MSR-t nem tudom hogy tudnám kinyerni, bár korábban valami kapcsán rémlik, hogy láttam.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

No megtaláltam, ha be van töltve a cpuctl nevű kernel modul, akkor egyrészt a csomagból telepíthető, általános

# x86info -m

másrészt a FreeBSD sepcifikus

# cpucontrol -m 0xXY /dev/cpuctl0

paranccsal lehet kérdezgetni MSR-t. Csak épp azt nem tudom, hogy hanyas számú az, ami neked kell.

root@acer:~ # cpucontrol -m 0x0 /dev/cpuctl0
MSR 0x0: 0x00000000 0x00000000
root@acer:~ # cpucontrol -m 0x01 /dev/cpuctl0
MSR 0x1: 0x00000000 0x00000000
root@acer:~ # cpucontrol -m 0x10 /dev/cpuctl0
MSR 0x10: 0x000001d7 0x338f5161

 

0x12-ig próbáltam, a többi hibát adott.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Köszönöm a roppant hasznos visszajelzést!

Nem tudok róla, hogy az EFER MSR letiltható lenne, lévén az egy CPU control register. Legalábbis sem az AMD64, sem az Intel Manualban nem találtam ilyesmit, de majd mégegyszer alaposan átnyálazom.

> AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>

A kimenet alapján egyébként tudnia kéne a long módot. Legalábbis szerintem az "AMD Feature" felel meg a cpuid[0x80000001].edx-nek, ahol a 29. bit lenne az "LM" (azaz long mode). Ez mondjuk nem változtat a tényen, hogy amikor bekapcsolom a lapozást, akkor elszáll, mint a magyar ételinfláció.

> Csak épp azt nem tudom, hogy hanyas számú az, ami neked kell.

Brute force-al eltartana egy darabig eljutni odáig :-) A száma 0xC0000080. https://en.wikipedia.org/wiki/Control_register#EFER Itt a 8. bit állítja, hogy a lapozás engedélyezésével aktiválódjon a long mód. A PGE bit is kell, ez jelenti a 64-bites lapozótáblát, de elvileg olyanod is van.

Ezen kívül engedélyezek még pár egyéb funkciót (SSE főként), lehet azokkal lesz baja? Mindjárt összevetem, a kimenetedben melyik kódszó lehet melyik bit, és hogy támogatott-e mind. Ezekre igazából nincs szükség a betöltéshez, csak azért engedélyezem őket, mert a betöltött kernelnek valószínűleg kell: fordítók alapból ugyanis SSE optimalizált kódot generálnak (hacsak nincs "-mno-sse -mno-sse2" kapcsoló explicit megadva, de akkor sem mindig https://stackoverflow.com/questions/16079340/can-not-disable-sse-in-gcc). Ezen a nyomon indulok tovább!

Csináltam egy új verziót, ebben csak a legminimálisabb funkciókat kapcsolom be. Felraktam egy disk.img.gz-t az issuehoz, ami ezt használja. Remélem így már működni fog (mondjuk a listád alapján kéne lennie OSFXSR támogatásnak, de inkább lekapcsoltam, ha nem muszáj). Ez most a loader_x86.c legelején van lefagyasztva, szóval ha villogás nélkül indul, akkor az azt jelenti, hogy sikeresen túljutott a boot_x86.asm-en. Ha viszont továbbra is villog, akkor kezdek kifogyni a tippekből, mi lehet a baja.

Nem teljesen felhőtlen a mosolyom. Semmi épkézláb ötletem nincs, hogy mi eredményezi, de kb 40:60 arányban nem villog / villog. Mindegy a 3 portjából melyikbe van bedugva, mindegy, hogy hosszabb vagy rövidebb kikapcs után bootol, nem számít, hogy a boot manageréből helyből indítom, vagy előbb legalább át- (és vissza)lépek erre az eszközre - nem találom a rendszert benne.

Szóval ez a fent levő disk.img -ről bootol, de kissé változékony az eredménye.

De legalább lekérdeztem a gépen az msr-t:

# cpucontrol -m 0xC0000080 /dev/cpuctl0
MSR 0xc0000080: 0x00000000 0x00000d01
 

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Köszönöm a tesztelést!

Feltettem egy mégújabbat. Ez ugyanaz, mint az előző, csak annyiban más, hogy a irreleváns control register biteket nem piszkálja, úgy hagyja őket, ahogy voltak. Ha ez is villogásba kezd, akkor egyelőre tényleg nincs több ötletem :-( De majd még agyalok, hogy mi a fene lehet. Az biztos, hogy a long módba váltás során van a bibi.

Messziről figyelem a témát, és remélem kiforrja magát, a grub2 nekem se a szívem csücske. :) Viszont ezzel az ACER-es "mizériával" kapcsolatban eszembe jutott valami. Én is használok időnként egy netbúkot, és bootnál, amikor a (nem szeretem) grub2-ben kiválasztom, mi töltődjön, egy darabig kikapcsol a képernyő, valamilyen inicializálásig nincs is kép. Nem lehet, hogy itt valami olyan hibát kergetsz, ami nem is a te kódodban van? :) Értem ez alatt azt, hogy az adott üzemmód váltásnál, amit meg kell csinálnod, az után (bugos UEFI/BIOS, bugos hardver, bugos bármi miatt) amúgy is szétesik a megjelenítés? És kellene valami inicializációt, bármi hívni / csinálni, hogy helyre jöjjön? A gyártó ezt belehekkelte abba az egyetlen OS-be, amit ismert, "minden más meg le van ejtve" címszóval.

( bzt | 2023. 07. 27., cs – 22:02 )

Szerkesztve: 2023. 07. 27., cs – 22:03

Ettől az Acer-es mizériától eltekintve, beraktam egy gzip kitömörítőt (transzparensen kicsomagolja a modulokat, ha tömörítve lennének), ezzel minden bekerült, amit be akartam rakni, így kiadtam az első release-t. Az ebuild-et lemásoltam, 9999 helyett 1.0.0-ás verzióval.

Az OpenBSD-seknek meg írtam a levlistára, megkérdeztem, lehetne-e, hogy a betöltőjükben és a kerneljükben az ELF fejlécben az OS/ABI OpenBSD-re legyen állítva. Ha belemennek, akkor bekerülhet az OpenBSD bootolás is.

( dzsolt v | 2023. 08. 02., sze – 18:30 )

Látom halad a RPi támogatás, az ebuildba beletehetnéd így:
KEYWORDS="~arm64 ~amd64 ~x86"

Ha esetleg régebbi 32 bites ARM-re is jó, akkor az ~arm is mehet bele.
 

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

> Látom halad a RPi támogatás

Igen, azóta ki is debuggoltam, most már tökéletes.

> Ha esetleg régebbi 32 bites ARM-re is jó

Ezen most elgondolkodtam, hogy hogyan is kell érteni.

Az igaz, hogy a kernel, amit bebootol az lehet i386-os, x86_64-es és arm64-es ELF vagy PE; viszont maga a lemezkészítő applikáció, amit a csomag ténylegesen telepít gyakorlatilag bármin elfut, aminek van egy libc-je (32-bit, 64-bit tökmindegy, pl. RISC-en és MIPS-en is, de megy BSD-n, Minix-en, Haiku-n stb., lefordul és simán működik), vagy támogatja a WIN32 API-t (ReactOS, XP, Win7..Win11, stb. 32-bit, 64-bit megintcsak tökmindegy).

Szóval a csomag által telepített appliáció igazából mindenen elfut, mert csak egyetlen függőség nélküli C fájl.

( dzsolt v | 2023. 08. 02., sze – 18:30 )

Szerkesztve: 2023. 08. 02., sze – 18:30

dupla

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

( bzt | 2023. 08. 04., p – 12:06 )

Bekerült az utolsó funkció is, amit nélkülözhetetlennek tartottam.

Ha az egyik betöltött modul egy DSDT tábla, akkor az nem mint modul adódik át a kernelnek, hanem helyette megpecseli az ACPI táblát vele. Raspberry Pi alatt DTB-t is elfogad (RPi-n nincs ACPI, de azért generál egy fake-t, hogy egységesek legyenek a boot paraméterek). Szerencsére a DTB magic bájtjai, 0xD0, 0x0D, 0xFE, 0xED érvénytelen AML bájtkód, így remekül működik ez a megoldás. A fake ACPI RPi-n azért is jó, mert így át tudja adni, hogy hány magos a proci, illetve Memory Map Multiboot2 taget is generál, amiből meg szabványosan kiderül az MMIO címe).

Erre a modulos DSDT trükközésre azért van egyébként szükség, mert rengeteg a bugos firmware, illetve RPi alatt nincs semmi ilyesmi, ott mindenképp egy .dtb fájlt kell betölteni a boot partícióról.

Mostantól feature freeze van, csak bugjavítás lesz. (Megj. lehet leforkolom egy fullos verzióba, mert sokan kértétek a menüt és a mindenféle fájlrendszer támogatást. Ezek jó ötletek, de nem ebbe a repóba valók.)

( bzt | 2023. 09. 02., szo – 02:54 )

Szerkesztve: 2023. 09. 02., szo – 02:57

Egy kis frissítés, refaktoráltam a lemezkép készítőt (a betöltők nem változtak, az rpi-s crc-je csak azért változott, mert újrafordítottam a legfrissebb Clang-al).

Az új lemezképkészítő még egyszerűbb. Nincs már külön -b kapcsoló, hanem egyszerűen csak a lemezkép neve helyett lehet eszköznevet is használni (pl. /dev/sda Linuxon, /dev/disk0 BSD-n, vagy \\.\PhysicalDrive0 Windowson).

Ilyenkor nem generál GPT-t és ESP-t, hanem megkeresi az eszközön lévőt és azt használja. További újjítás, hogy a megadott könyvtárból a fájlokat ilyenkor is felmásolja a boot partícióra, és a betöltőket is telepíti (eddig a -b csak az x86-os betöltőt rakta fel, semmi mást nem csinált). Ugyanez történik, ha olyan lemezképet adtok meg, ami már létezik (ilyenkor a -c kapcsolóval lehet megmondani, hogy mindenképp kreáljon újat, és ne használja a meglévőt).

Más: a fullos verzió kapcsán megpályáztam az FSF-nél. Ha elnyerem, akkor meglesz az is, minden színes-szagos funkcióval, amit csak kértetek (interaktív menü, pluginok, mindenféle fájlrendszer meg kernel támogatás). Drukkoljatok!

( hnsz2002 v | 2023. 09. 19., k – 12:07 )

Szerkesztve: 2023. 09. 19., k – 12:07

Ha van időd és kedved, nincs kedved egy szopásmentes UPS daemont is írni? :D

Az apcupsd csak apc-t tud. A nut-hoz meg ahányszor hozzá kell nyúlnom, annyiszor hullik ki a hajam...

"Sose a gép a hülye."

Igen, ami esetleg véletlen kompatibilis vele. Régebben (5+ éve) vettünk sok powercom-ot, az ment vele meg viszonylag jó is volt. De az utolsó darabok már nem mentek vele. Aztán megszűnt, mást meg még nem találtam. Próbáltunk sok mindent, egyik másik orbitálisan kegyetlen pusztulatos szar volt, aztán azt mondtam, hogy jó, innentől akkor csak APC-t veszünk, nem érdekel mennyibe kerül, nem akarok szopni. Ettől függetlenül beesik egy pár más, főleg amit nem mi vettünk.

"Sose a gép a hülye."

( virtualm v | 2024. 01. 07., v – 17:12 )

Én most szerettem volna kipróbálni, használni, de félóra "homokórázás" után "kontroll C" nyomtam

wt@Z500:~$ simpleboot / /dev/sdb1/ubuntu.img
^C
Valószinű, hogy nem jól értelmeztem az egyszerűnek mondott dolgokat.
1 - letöltöttem, telepitettem a home könyvtárból futtattam / paraméterrel mint input könyvtárral.
2 - kimenetnek pedig a /dev/sdb1/ eszközt adtam meg az ubuntu.img fájlnévvel.

Mit csesztem el ? Mit csináljak másként ?

üdv: virtualm

Mit csesztem el ?

Úgy tűnik, hogy ezt:

kimenetnek pedig a /dev/sdb1/ eszközt adtam meg az ubuntu.img fájlnévvel.

Ha jól értelmezem a dokumentációt, akkor kimenetnek megadhatod pl. a /dev/sdb eszközt, vagy egy fájlt a teljes elérési útvonalával. Az esetedben először csatolnod kellene a /dev/sdb1-et a fájlrendszerhez, pl. a /mnt/akarmi-be, majd utána ilyesminek kellene lennie a parancsnak:

simpleboot / /mnt/akarmi/ubuntu.img

Ha az ubuntu.img már előzőleg létezett ott, és helyette egy újat akarsz létrehozni, akkor kell még egy -c a parancshoz:

simpleboot -c / /mnt/akarmi/ubuntu.img

Amennyiben egy bootolható pendrive-ot szeretnél készíteni, akkor talán ez a jó parancs:

simpleboot / /dev/sdb

Ugyan miért tettél ilyent???

futtattam / paraméterrel mint input könyvtárral.

És ezt mégis hogyan gondoltad? A könyvtárnak azokat a fájlokat kell tartalmaznia, amik a létrehozandó lemezkép boot partíciójára kerülnek. Minek akarod a teljes fájlrendszeredet egy szerencsétlen FAT partícióra szuszakolni (aminek a maximális mérete 4G)? Arról nem is beszélve, hogy a cél lemezkép is ugyanezen a fájlrendszeren található (/mnt a / alatt van, ugyebár), szóval...

kimenetnek pedig a /dev/sdb1/ eszközt adtam meg az ubuntu.img fájlnévvel.

Ismételten, mégis hogyan gondoltad? Ennek semmi értelme. Célnak vagy egy lemezképet adsz meg (pl. /home/virtualm/ubuntu.img vagy /mnt/ubuntu.img), vagy pedig egy teljes device fájlt (pl. /dev/sdb), de semmiképpen sem egy partíciót (mint ami a /dev/sdb1), arról nem is beszélve, hogy a /dev/sdb1/ubuntu.img-nek meg végképp se füle se farka. Persze technikailag megadható a /dev/sdb1, és a partíción belül lehetséges egy újabb GPT-t létrehozni, csak épp értelme nincs sok.

Szóval nem egészen világos, hogy mit szeretnél. De az biztos, hogy a könyvtárnak a boot partíció fájljait kell tartalmaznia, tehát a gyökér / mindenképp hülyeség, legjobb esetben is /boot (feltéve, ha oda van felcsatolva a mostani ESP partíciód). Célnak meg vagy egy lemezkép, vagy egy teljes device.

Remélem segít, bár tényleg nem értem, mi lett volna a célod ezzel a paranccsal.

Szerk: Nézd meg ezt. Ez magyarul van, igaz az Easyboot doksija, de a két parancs majdnem 100%-ig azonos (a Simpleboot-nak megadható a -k és -i kapcsolóval a betöltendő kernel és initrd neve, ha nem lenne konfig fájlod, ilyen az Easyboot-nál nincs, mert az több boot opciót is kezel, emiatt mindenképp kell a konfig fájl. Van viszont -r, amivel root partíciót adhatsz hozzá, neked az biztos nem kell. A konfig parancsai is hasonlóak, bár ott már jelentős különbségek vannak, de ettől függetlenül maga a parancs hívás doksija jó ahhoz is.)

( bzt | 2024. 01. 10., sze – 15:13 )

Megpróbáltam értelmezni, hogy mi is lehetett a célod.

Mit csesztem el ?

Először is szerintem azt, hogy ez nem egy oprendszer telepítő, hanem egy rendszerbetöltőtelepítő (mint a grub-install, az sem telepíti fel a rendszert, csak a betöltőt).

Szóval tegyük fel, hogy a /dev/sdb-re felraktál egy ubuntu-t, és le akarod cserélni az ott lévő grub-ot simpleboot-ra. Ekkor kell egy könyvtár, legyen a neve "konfig", ebben mindössze egyetlen "simpleboot.cfg" fájlra van szükséged, majd

simpleboot konfig /dev/sdb

Ennek hatására a simpleboot parancs megnézi a /dev/sdb-n a már meglévő GPT partíciókat, az ESP-re felmásolja a simpleboot.cfg fájlodat és a betöltő programot (mást nem kell, hiszen a többi fájlt már odarakta az ubuntu telepítő). Partíciót és fájlrendszert nem fog létrehozni, és az ESP-n (amit /boot-ra mountol az ubuntu) kívül más partíciót egyáltalán nem is fog piszkálni. Az ESP az egy olyan partíció, aminek speciális a típuskódja, és FAT32-re van formázva (ezt az ubuntu telepítő már megcsinálta neked, oda rakta ugyanis a grub-ot, a kerneled meg az initrd-éd).

Ez így érthetőbb?

Igen, az /dev/sdb (SSD drive) van egy Ubuntu. Az eredeti belső hdd-n van a régi ubuntu, amit egy darabig megtartanék, főleg a /home alatti cuccokat. Tehát ha úgytetszik, bootmanaggerként használnám a simpleboot tudományát. ( ha jól értelmeztem a dolgokat )

A probléma az, hogy nincs simpleboot.cfg file. Hol keressem, hogyan legyen simpleboot.cfg ?

üdv: virtualm

( influencer | 2024. 01. 10., sze – 15:32 )

Bzt, szép munka és gratulálok, hogy ezt létrehoztad.

Alternatíva, 10000 Ft körüli összegbe kerülő program: BootIt Bare Metal és persze van UEFI verziója is. Jó a teljes körű, parancssoros és grafikus boot manager feladatokon túl még biztonsági mentésre, klónozásra, file rendszer átméretezésre, javításra, mindenre, amire szükség lehet. Generál boot pendriveot vagy cédét, mindent megold. Számomra az a meglepő, hogy az egész pár száz kbyte méretű, ami kezel mindenféle operiációs rendszert, file rendszert, imaging, meg minden. Nagyon sok mindent tud, és megbízhatóan megy évek óta, soha nem okozott problémát, inkább segített megoldani.

Ne értsd félre, nem azt mondom, hogy felesleges amit létrehoztál, mert egyrészt te sokat fejlődtél tőle, másrészt biztos van akinek hasznos. Csak azért mutatom, hogy ennek a funkcionalitását megvalósítani talán több év folyamatos munkája lenne. Ez csak egy lehetőség, amit jobban megismertem, van még sok más, itt 23 lehetőséget szedtek össze, javasolnám a te programodat is ide tenni, hogy még könnyebben más is megtalálja. A BootItre meg 18 hasonlót szedtek össze. Szóval jó sok lehetőség van.

Bzt, szép munka és gratulálok, hogy ezt létrehoztad.

Kösz!

Alternatíva, 10000 Ft körüli összegbe kerülő program

Fizetős és zárt forráskódú, szó sem lehet róla, nekem semmiképp sem alternatíva.

Jó a teljes körű, parancssoros és grafikus boot manager feladatokon túl

Ez nem egy boot manager, hanem egy boot loader. Azaz egyetlen kernel-t tud csak betölteni, ugyanúgy, mint például a LILO vagy a syslinux. Ha boot managerre van szükséged, akkor arra ott van az

Easyboot

aminek van interaktív bootmenüje, amivel több opció közül választhatsz, valamint vannak beépülői is, amivel számos kernelt és boot protokollt támogat (a Simpleboot csak Linux-ot és Multiboot2-t tud, ezzel szemben az Easyboot tud Windows-t, FreeBSD-t, OpenBSD-t, Haiku-t, ReactOS-t, MenuetOS-t, KolibriOS-t, SerenityOS-t stb. is betölteni és képes emulálni a grub bootot minden bugjával egyetemben). Akárcsak a Simpleboot, az Easyboot is ingyenes és nyílt forráskódú.

Ne értsd félre, nem azt mondom, hogy felesleges amit létrehoztál, mert egyrészt te sokat fejlődtél tőle, másrészt biztos van akinek hasznos

Semmit sem fejlődtem tőle, ez nekem mellékprojekt volt, mert tele lett a tököm azzal, mennyire szar a syslinux, amit eredetileg a MEG4 bootolására használtam. Azért írtam a Simpleboot-ot, hogy egyszerűen tudjak bootolható MEG4 lemezképet készíteni, semmi másért. Szóval nekem máris hasznos, így mindenképp megérte, ha másnak is jól jön, az már csak a ráadás.

Csak azért mutatom, hogy ennek a funkcionalitását megvalósítani talán több év folyamatos munkája lenne.

Hát, nekem az Easyboot-ot megírni pár hónap volt, és ha jól látom, mindazt tudja, amit a BootIt (csak épp ingyenes és nyílt).

javasolnám a te programodat is ide tenni

Kösz, de inkább a nagytesó Easyboot-ot tolnám. Ha valaki, akinek van alternative.to accountja feltenné a listára az Easyboot-ot, azt megköszönném!

Oké, akkor beteszem.

Mégegy kérdés: a bootolható CD lemezképet végül is azért nem csináltam meg, mert nekem már 15 éve nincs optikai meghajtóm. De ha van rá igény, akkor könnyedén belerakhatom, ahogy tettem az efidsk-nél is.
Szóval a kérdés, szerintetek mennyire van még igény arra a XXI. században, hogy a bootolható lemezkép egyben CD-ről is tudjon indulni? Öszintén szólva szerintem nincs, jópár éve felhagytak a CD lemezek gyártásával is...

...marmint USB boot-ra gondolsz, hogy az mukodik....

Ööö, nem. A lemezformátum meghajtóagnosztikus (kivéve a CD-t, az külön állatfaj). Paraszti módon megfogalmazva a mostani lemezkép használható még pl. qemu-n "-fda", "-hda", "-drive format=raw" és "-drive if=sd" kapcsolókkal is, azaz nemcsak USBs tárhellyel (röviden bármivel elmegy, kivéve "-cdrom"). Az USB pendrive csak a legtipikusabb eszköz, amivel mostanában oprendszert telepít az ember, de nem az egyetlen lehetőség.

Na mind1, beraktam egy "-e" kapcsolót, ennek hatására a kigenerált lemezkép hibrid lemez és CD kép lesz, azaz CD-re egyaránt kiírható, és EFI CDROM-ként is bebootolható. BIOS CDROM boot támogatás túl nagy szívás, az nem lesz (szervereken úgyis EFI van).

Nézem ezt az XFS-t, de ez egy kihalt állatfaj. Akárhogy keresek a speckójára, csupa 404-be futok bele, a Linux kernelben meg nincs ledokumentálva (csak a Linux-os interfésze). Végül is ezt találtam a princetoni egyetem szerverén: xfs_filesystem_structure.pdf, most ez alapján dolgozok. A detektálás megvan, a szuperblokkot, allokációs csoportokat és az inode fejlécet már felparszolom, most jön egy adott inode betöltése a B+-treeből (kicsit szopó csak), a fájl offszetek leképezése blokkokra (ezt nem látom még, hogy megy) és a könyvtárbejegyzések végignyálazása (ez sima ügy). Szóval hamarosan érkezik az XFS támogatás, hacsak valami vis major közbe nem jön.

Azzal nincs is semmi baj, hogy régi. De azt a pdf-et, amit a princetoni szerveren találtam, és ami eredetileg az oss.sgi.com-on volt (megszűnt), aztán átrakták az xfs.org-ra (ugyancsak 404, meg lejárt tanusítvány), igazán berakhatták volna a https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git repóba, vagy a Linux kernel rtd-re a html változatát. A gitweb nem tud formázást, szóval a forrás asciidoc-okat olvasni eléggé szívás így. Ja és persze a linkeket sem ártana frissíteni, mert 99%-uk 404, kész csoda, hogy a kernel-org-os repóra rábukkantam (a Linux forrását grep-elve, a Documentation/filesystems/xfs-maintainer-entry-profile.rst lábjegyzetében... nem épp valami kiemelt, feltűnő hely. Remélem Hunk Csaba HUP-os és olvassa ezt, kacsint ;-) )

ah, OK, szoval minden lemezkep agnosztikus, kiveve a CD-t. Ezt nem tudtam. De kosz hogy elmondtad.

Az XFS-sel kapcsolatban. Rengetegen hasznaljak meg mindig ezt, bizonyos esetekben a sebessegi viszonyai jobbak a tobbinel.

Regi, de jol mukodik, az lehet, aluldokumentalt.

(Csak erre a félmondatra válasz.)

Nézem ezt az XFS-t, de ez egy kihalt állatfaj.

Hát nagyon nem. Az igaz, hogy ősöreg, de azért vedd figyelembe, hogy a (tetszik-nem-tetszik) egyik meghatározó disztró gyártója/szállítója, azaz a RedHat (tudom, IBM) a gyakorlatilag erősen hozzá köthető Ext[234] vonalat egy laza mozdulattal kukázta, és egyik napról a másikra ezt az XFS-t javasolja az Ext4 helyett alapértelmezetten. (Valamint pl. a magyarországi süsü-mérnökök körében hangzott el az, hogy ugyan gyárilag az Ext4 a preferált, de ha rajtuk múlik, ők XFS-t konfigurálnak.)

Persze örömmel olvasom, hogy a ledínózás ellenére most ezen ügyködsz.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem rossz összehasonlítás, csak épp kicsit sántít.
Pl. 4-es pont "Allocation Groups" ezt tökre úgy mondja, mintha az ext4 nem tudna ilyent. De, tud, csak ott "block groups" a nevük. Sőt, "flexible block groups" is van, ami pont úgy működik.

Egyébként szvsz mindkettőnek pont ugyanaz a baja, túlbonyolítják az egyszerű dolgokat B+tree-vel meg hashekkel, hulla feleslegesen. Például, az XFS az inode-okat is B+treeben tárolja, de minek? Ext4 alatt ugyanez egy sima tábla, ami O(1) elérésű, messze veri mind sebességben, mint felhasznált hely tekintetében. A könyvtárakra viszont, ahol még lenne is értelme, az XFS csak opcionálisan használ B+fát, az ext4 meg sehogy, helyette nyakatekert módon tárolt hashel szopik (oké, Ts'o bácsinak legyen mondva, úgy erőszakolta bele, hogy közben bitkompatíbilis maradt az ext2-vel, ami nem semmi teljesítmény, csak épp kérdéses, hogy volt-e értelme. Lehet egy mellékes data stream forkkal (mint az xattr) jobban járt volna).

> opcionálisan használ B+fát, az ext4 meg sehogy, helyette nyakatekert módon tárolt hashel szopik

mondjuk annyi elonye van, hogy a sima listazas is gyors marad, ez nem mondhato el pl. a btree-s reiserfs vagy btrfs-rol (nyilvan ez akkor erdekes, ha sok millio file van egy konyvtarban)

> hogy közben bitkompatíbilis maradt az ext2-vel

amit az extentek miatt el is veszit gondolom  (en vagy 10 eve implementaltam ext2/3/4 parsert, de ugy remlik annyira azert az ext4 nem volt visszafele kompatibilis, csak az ext3 nagyjabol, az talan csak ext2+journaling)

mondjuk annyi elonye van, hogy a sima listazas is gyors marad

Ez igaz, viszont az megmaradt volna akkor is, ha a hasht nem szuszakolja be a bejegyzések közé, hanem egy külön data streambe rakja. A kompatibilitást sem befolyásolta volna, és a hash tábla beolvasás hatékonysága sem lenne a béka segge alatt.

ez nem mondhato el pl. a btree-s reiserfs vagy btrfs-rol

Ezzel nagyon nagyon egyet értek. Szerintem is azért hülyeség a B+tree használata fájlrendszerekben, mert lehet, hogy egy elem keresése gyors vele, viszont minden más művelet (hozzáadás, törlés, listázás) meg nehézkes, körülményes és/vagy lassú. Ha csak a forrás olvashatóságát és minőségét nézem (a Linux kernelmodulokét), akkor ezt a B+tree-t legszebben a BeFS oldja meg, de még arra is érvényes mindez (pedig ott még beraktak egy overflow pointert is a node-okba, hogy a listázást gyorsítsák, mégis a hozzáadás és a törlés továbbra is lassú és körülményes).

Szerény véleményem szerint a Linux kernelmodulok közül az XFS B+tree implementációja a legcsúnyább, túltolták benne az absztrakciós szinteket, irdatlan mennyiségű függvényt használ feleslegesen. Ezek aztán alkalmasint beiktatnak egy indirekt függvényhívást, így szerencsétlen fordítónak esélye sincs, hogy fordításkor kioptimalizálja inline-ba ezeket, emiatt pedig megmarad a szükségtelenül hosszú függvényhívási lánc futási időben is. Függvénypointerek helyett szerencsésebb lett volna egy switch arra a pár esetre, ami előfordulhat (két-három lehetőségről beszélünk csak), akkor legalább a fordító ki tudná optimalizálni ezt a zagyva kódot. Arról nem is beszélve, hogy minden második függvény saját cache-t tart fenn, csak azt nem tudom, minek, mikor a Linux kernel önmagában megoldja a blokkok cache-elését. Nem baj, legalább rengeteg kernel memóriát elpazarol vele, és használhatatlanná válik tőle a kernel LRU...

> túltolták benne az absztrakciós szinteket, irdatlan mennyiségű függvényt használ feleslegesen

jajj hany ilyet lattam mar mashol is... anno ~25 eve egy java-ban irt iranyitasi rendszert, ahol 1 gomb lenyomasa utan ugy 20 fv hivason ment at mire a vegen atirt egy valtozot. vicc volt, az egesz progi 11 perc alatt indult el! (ennyi kellett hogy a jre betoltse es osszelinkelje a csillio classt)

legutobb meg a libloc geoip-alternativaban, raadasul bitenkent rekurzioval! en meg ujrairtam c-ben az egeszet 200 sorban.

> csak azt nem tudom, minek

eros a gyanum hogy ezt portoltak valahonnan, nem direkt a linuxhoz irtak...  vagy amikor irtak meg nem volt cache masik retegben, csak azota se nyult hozza senki.

Az összehasonlítást azért tettem be, hogy látható legyen, nem ugyanaz volt a két esetben a fejlesztők célja, vannak mindkét oldalon előnyök és hátrányok, ezek alapján eldöntheti, aki akarja, hogy mire melyiket használja. Akinek nincsenek speciális igényei, annak amúgy bármelyik jó, és általában egy disztribúció kiválasztásakor már el is dől, hogy milyen típusú lesz a fájlrendszer, mert a többség azt használja, ami alapértelmezésben települ.

Elismerem, félreérthető voltam. Nem arra utaltam a "kihalt állatfajjal", hogy magát a fájlrendszert ne használnák, hanem arra, hogy minden doksija eltűnt már a netről, sco.com már rég nincs, az xfs.org-nak meg lejárt a tanusítványa és senki sem frissíti, valamint még a Linux kernelbe is lusták voltak berakni a linket egy tisztességes doksira. Ilyenek. Magyarán fejlesztői szemszögből nem úgy tűnik, mintha karban lenne tartva, persze ennek semmi köze ahhoz, hogy hányan használják.

Egyébként funkcionalitásban nem rosszabb, mint az ext4, bár hogy mennyire jó a performanciája, azt nem tudom, mert használni nem használtam (csak a forráskód alapján mondom). Az biztos, hogy a Linux kernelbeli modulja enyhén szólva is ótvar kód, rettenetesen rosszul van megírva, és irtó sok erőforrást pazarol. Igazából azzal kezdtem a dolgot, hogy portoltam a Linux-os libxfs-t Easyboot-ra, de egész egyszerűen bootolásnál nincs annyi erőforrás, amennyit az megeszik. Úgyhogy tabula rasa, nulláról megírtam inkább én az egészet. Ez most így nagyon faja, kevés helyet foglal, és csak statikus memóriát igényel.

Akkor már el is készítetted az Easybootot, gratulálok hozzá, nem találkoztam vele sajnos, pedig évekkel korábban pont ilyet kerestem. Jól olvasom, hogy megy uefi nélkül régebbi gépeken és uefivel is, van mbr és gpt támogatás is?

Amire nem találtam első körben, hogy tud particiót, operációs rendszer elrejteni, hogy bármennyi elsődleges partició lehessen? Ha van mondjuk mbr esetén azonos ssdn több windows, megoldható, hogy ne lássák egymást, de particiót sem? A bootit ng nagy előnye, hogy ezt jól kezeli, így legyet egy ssdn akár több windows 10/11, retro windows xp, akár dos is, és nem látják egymást. Ha ilyenre nincs igény, akkor ennek a funkciónak nincs haszna talán.

Szerintem azt meg lehet csinálni, hogy ténylegesen sok filerendszer van a háttértáron, s a partíciós táblát kedvünkre cserélgetjük úgy, hogy pl. az első négy, a második négy vagy a harmadik négy filerendszer határai vannak az épp kiírt MBR-ben. Azt ugyan nem értem, hogy ebben mi a nagyszerűség, miért ne lehetne pl. egy GPT-be felvenni 12 partíciót, vagy MBR esetén három primary után egy extendedbe láncolt listaként még kilencet EBR-ben.

Mi abban a nagyon jó, hogy aktuálisan egy MBR nem tartalmaz olyan tartományokat, ahol valójában vannak filerendszerek, de most éppen nem tudjuk, ezek mettől meddig tartanak?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A boot manager tudja, és a boot esetén kiválaszott menüpont alapján az a tábla jön létre, amit beállítottál ott. El lehet rejteni, sorrendet beállítani ott, bármit. Az egyik rendszer csak magát látja, a másik lát még másik hármat, a negyedik lát egy megosztottat, amit a többi is lát. Ilyesmikre jó. Például retro játékokhoz. Vagy teszteléshez. Így lehet minden gépet használónak nem külön felhasználója, hanem külön operációs rendszere. Ami nem hat ki a többire, normál felhasználás esetén.

( bzt | 2024. 02. 17., szo – 10:00 )

Akit érint, változtak a parancssori kapcsolók, hogy szinkronba kerüljenek az Easyboot-al. A boot partíció méretét mostantól -b kapcsolóval lehet megadni.

( bzt | 2024. 10. 16., sze – 15:10 )

Szerkesztve: 2024. 10. 16., sze – 15:11

Egy ideje nem volt hír erről a projektről, de most van!

Új fícsörök:
- SMP támogatás (a "multicore" direktíva hatására a kernelt az összes processzormagon elindítja, pont úgy, ahogy az Easyboot is)
- ARM alapú Linux támogatás (megintcsak, az Easyboot már régóta tudta ezt, de a Simpleboot ezidáig csak Multiboot2-őt tudott ARM-on)
- ha nem találja a konfigját, bepróbálkozik az easyboot/menu.cfg-vel hátha alapon, és az első boot opciót megpróbálja betölteni (nem mind, de a legtöbb direktíva ugyanaz, vagy legalábbis kompatíbilis)
- a ROM-ba égethető változat is alaposan ki lett tesztelve (itt volt egy kis pitty-putty, mert a legújabb coreboot és CLang verzió tört pár dolgot, de már jó)
- tesztelve BIOS, UEFI és coreboot alatt; qemu-n, VirtualBox-on és bochs-on, valamint egy régi vason, amit nem sajnáltam.

Ennyi újdonság miatt hatalmasra nőtt a projekt, az x86-os egy szem futtatható fájl, amiből áll, immáron 55K :-) Az ARM változat meg 43K-ra dagadt. Most már jó bloated :-D (szarkazmus)
(FYI a függőség nélküli telepítők mérete most 148K (Linux) és 156K (Windows). Kaptak egy új kapcsolót, "-m", amivel a multicore-t lehet alapból bekapcsolni, ha nem lenne simpleboot.cfg fájl.)

Egy kis bosszankodás: a legújabb CLang előre sorolja azokat a függvényeket, melyeknek attribútuma van. Ez szopás volt az Easyboot-nál, mert a pluginok által hívható függvények ilyenek, ugyanakkor a valós módú címzés szűkössége miatt a text szegmens első pár függvényét menet közben felül kell írni, hogy a bootoló AP-k is használhassák a kódot. A megoldás ".text" és ".text$A" szekciónevek használata lett, de emiatt frissült az Easyboot is.

Ez így mindig kevés. Nincs átírva Rust-ba, nincsenek benne reklámok, AI, keylogger az NSA-nak. Nem Mac-en fejlesztetted a Starbuckban, nem támogattad a fejlesztés közben a LGBTQ+ közösséget, stb.. Sok kell még, hogy felzárkózz babzsákfejlesztői szintre, hogy hajbi lemérnökemberezzen téged is.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( bzt | 2024. 10. 17., cs – 11:53 )

Szerkesztve: 2024. 10. 17., cs – 11:58

Na még egy kis újdonság:
- Az "-e" kapcsolóval generált lemezkép mostantól nemcsak EFI CDROM-ként, hanem ősrégi BIOS gépeken is bootolható (ezidáig nem hiányolta ezt senki, azért nem volt)

Mivel lassan 15 éve nem volt olyan gépem, amiben lett volna optikai lemezolvasó, ezért sok jelentősége nincs, a gyakorlati haszna annyi, hogy az EFI tetves lassú, így viszont BIOS-al pillanatok alatt bootolható virtuális gépen a kigenerált lemezkép (szerintem ma már kizárólag VM-eken használnak csak CDROM-ot, igazi vason nagyon nagyon régóta pendrájvról meg a telepítés). Hogy hogyan valósítottam meg, na az megér egy misét, tovább fog tartani elmagyarázni, mint megcsinálni volt :-D Zseniális hekkelés, ha szabad ezt mondanom :-D

Eddig azért nem volt BIOS CDROM támogatás, mert míg EFI CDROM esetén transzparens a szektorméret, addig az idióta BIOS minden létező eszköznél 512 bájtos szektorméretet használ, kivéve a CD-t, mert annál 2048 bájtosat. Ez azért szopás a köbön, mert emiatt az LBA számozás elmászik, és a továbbiakban nem feleltethetőek meg a FAT kluszterek a lemezszektoroknak konvertálás nélkül. Hogy átírjam a betöltőt tetszőleges szektorméret kezelésére, na az ki volt csukva, mert már csak 10-20 bájtnyi hely maradt benne, eléggé ki lett már maxolva (bugos BIOS-ok miatt egyszerre 127 szektor olvasható csak be egyetlen hívással, azaz a második lépcsős betöltő maximális mérete emiatt 65ö24 bájt). Az elsődleges betöltő maximális mérete meg 480 bájtnyi, amiben már így is átkapcsolom a processzor üzemmódját, laptáblákat generálok, megszakításvezérlőt meg címbuszt inicializálok meg PE/COFF binárist parszolok (kb. 1-2 bájt maradt szabadon, szóval mégegy BIOS hívás szintén kicsukva).

Szóval más megoldást kellett találni. Ehhez tudni kell, hogy
- az eredeti IBM PC betöltötte a lemez legelső szektorát, az indította az OS-t. Ahogy nőttek a lemezméretek és felmerült az igény több partícióra, ide egy olyan kis MBR program került, ami aztán betöltötte valamelyik partíció első szektorát a VBR programmal. (Chainloading, a VBR nem tudja, hogy nem a BIOS töltötte be, hanem az MBR).
- namost a Simpleboot / Easyboot MBR szektora nem így lett megírva, hanem direktben a második lépcsős betöltőprogramot rántja a memóriába a partícióról, szóval mindegy neki, mi van a VBR-ben.
- EFI alatt maga a förmver értelmezi GPT, választja ki a partíciót és keresi meg rajta a fájlokat, így itt megintcsak nincs használva a VBR.
- EFI El Torito módban hasonló, csak ekkor GPT helyett a Boot Catalog-ból keresi ki a partíciót, de megint, a VBR nincs használva.
- BIOS El Torito módban azonban a Boot Catalog-ból kikeresett szektor töltődik be és fut le. Tehát ez az egyetlen eset, amikor a VBR kódja végrehajtódik.

Ezért azt találtam ki, hogy ide ebbe az ESP VBR-jébe rakok egy nyúlfarknyi programot, ami ráül a BIOS megszakításra és leemulál egy másodlagos merevlemezt, ami tulajdonképpen a CDROM 2048 bájtos szektorait olvassa, de 512 bájtos lemezként funkcionál. Miután ez megvan, betölti az MBR-t, mintha a BIOS töltötte volna be, és onnantól minden úgy megy, ahogy szokott (tehát itt unortodox módon a VBR tölti be az MBR-t, de miért is ne?). A memóriarezidens rész meg úgyis elveszik, amikor a kernel indulása előtt a betöltő kukázza az IVT-t és valós módból védett vagy long módú IDT-re kapcsol. Iszonyú hákolás ez az egész, de remekül működik (már ha valaki tényleg CDROM-ról akar még bootolni így a XXI. században).

hu jo ezt olvansi... 90-es evekben en is csinaltam ilyeneket, 256 byte introk, 1 szektorba bepreselni mindent is stb. meg pl dos-os ms word-hoz irni y2k patchet ami a datumot forditgatta ide-oda, elterelve a megszakitast, vagy io.sys-be valami szoveg helyere irni pici boot menut es hasonlok. de sajnos mar kioregedtem ezekbol es/vagy elkenyelmesedtem nemtom, de mar a pythonhoz is lusta vagyok neha :)