initrd maken die naar een ramdisk boot

[nzyme]

ik durf het bijna niet te vragen, maar wie kan me uitleggen hoe ik een initrd maak en naar een ramdisk boot .... Deze vraag komt n.a.v. het routerhacking topic: ik heb een sweex met custom 2.6 kernel en een met buildroot gemaakte rootfs met de daarop horende tools zoals 'sh' en bv 'mount'. Nu wil ik dat er een bz2 image geladen wordt door de kernel zodat ik mn rootfs niet "ergens" heb staan maar op /dev/ram0 en /tmp gemount onder /dev/ram2 en /home bijv. onder /dev/ram1.

ik heb al op google gekeken en ook op de linux doc site, maar het meeste gaat over lilo en grub icm met zo'n ramdisk en dat heb ik niet op de sweex

[nzyme]

schop

[irondog]

Hellraizer schreef op woensdag 02 november 2005 @ 10:41:
ik durf het bijna niet te vragen, maar wie kan me uitleggen hoe ik een initrd maak en naar een ramdisk boot

Een initrd image is een compressed ext2 filesystem. Bij het initialiseren van de kernel wordt een initrd image automatisch gedecomprimeerd (beschikbaar op /dev/ram0) en gemount als root filesystem. Na initialisatie is het root-filesytem (het initrd filesytem) vervolgens een normaal tmpfs filesystem.

.... Deze vraag komt n.a.v. het routerhacking topic: ik heb een sweex met custom 2.6 kernel en een met buildroot gemaakte rootfs met de daarop horende tools zoals 'sh' en bv 'mount'. Nu wil ik dat er een bz2 image geladen wordt door de kernel zodat ik mn rootfs niet "ergens" heb staan..

Je bent niet helemaal duidelijk. Volgens mij bedoel je dus, dat je niet wil dat het root-filesystem op een normaal block-device staat zoals een harddisk. Je wil een filesystem gebruiken dat reeds door de bootloader in het geheugen gezet is (op wat voor manier dan ook). Initrd is zoiets. Maar niet het enige die zoiets dergelijks kan bewerkstelligen

Nu zit je zeker met een filesystem gecreëerd door BUILDROOT, dat niet een initrd image is? => Dan zul je het moeten converteren. Probeer de image van BUILDROOT te mounten en maak er de gewenste image van.

maar op /dev/ram0 en /tmp gemount onder /dev/ram2 en /home bijv. onder /dev/ram1.

????

ik heb al op google gekeken en ook op de linux doc site, maar het meeste gaat over lilo en grub icm met zo'n ramdisk en dat heb ik niet op de sweex

Stel nu (ik ben niet bekend met sweex ofzo) dat initrd geen optie is omdat bijvoorbeeld de sweex bootloader helemaal geen initrd gebruikt en alleen één enkele _kernel_ image wil booten (en het rootfilesytem verwacht op een of ander blockdevice OF plaats in de image). Ik zou je in dit geval graag willen wijzen op het bestaan van initramfs. Initramfs is een gecomprimeerd filesystem bestand dat in de kernel geïntegreerd kan worden. Echter, ik ga er niet klakkeloos van uit dat dit bij sweex de gebruikte methode is.

Maar als je de context van je probleem wat duidelijker kunt omschrijven, zal ik morgen misschien even met een nuchter hoofd naar je probleempje kijken. Linkjes en resultaten in je zoekwerk zijn normaal trouwens 'gewenst' in de topicstart.

[ Voor 10% gewijzigd door irondog op 04-11-2005 05:13 ]

[nzyme]

kijk, ik werk nu alsvolgt:

met buildroot maak ik mn rootfs, een ext2 filesystem met daarop de standaard tools. Dit is zo'n 550kb compressed. Dit image bestand mount ik vervolgens in mn linux kernel source tree onder usr/root. Daarna maak ik mn linux kernel en stel ik in dat hij usr/root gebruikt als rootfs om te includen in de kernel. Vervolgens een 'make cross_compile=mipsel-linux' en klaar, ~1900kb vmlinuz om naar de sweex (router) te uploaden. Door een tooltje worden nog wel wat zaken aan de header veranderd maar dat is verder niet noemenswaardig.

Ik boot nu de sweex en die laadt mn kernel en komt uiteindelijk na een sec of 8 uit op de rootfs. Doe ik echter 'df -h' krijg ik niets, er is niets gemount dus en ik wil mn rootfs op een stukje ram hebben.

Zou ik mss in het linuxrc bestand wat in de root van mijn buildroot image komt moeten bewerken ?
Nu verwijder ik dat bestand en vervang ik het met een symlink naar bin/busybox met als naam init.

[irondog]

Hellraizer schreef op vrijdag 04 november 2005 @ 10:04: Door een tooltje worden nog wel wat zaken aan de header veranderd maar dat is verder niet noemenswaardig.

Hoe weet je dat zo zeker? Misschien wordt je root filesystem wel weer vervangen door iets wat het tooltje graag wil zien. Heb je dit al doorgenomen: http://www.norocketscience.com/router/upgrade.htm

Ik boot nu de sweex en die laadt mn kernel en komt uiteindelijk na een sec of 8 uit op de rootfs. Doe ik echter 'df -h' krijg ik niets, er is niets gemount dus en ik wil mn rootfs op een stukje ram hebben.

Wat krijg je dan wel? Is er enige aanleiding te geloven dat je iets te zien krijgt wat je zelf wel toegevoegd/gecompileerd hebt?

Zou ik mss in het linuxrc bestand wat in de root van mijn buildroot image komt moeten bewerken ? Nu verwijder ik dat bestand en vervang ik het met een symlink naar bin/busybox met als naam init.

Maak dan ook eens een symlink /bin/df naar /bin/busybox. Nogmaals, is het de busybox die je ook echt zelf gecompileerd hebt met buildroot?

[nzyme]

mn hele rootfs + tools komt uit de buildroot omgeving. Bijna alle tools zijn al symlinks naar busybox. De code van het tooltje in kwestie :

code:

#include <stdlib.h>
#include <stdio.h>
int main(int argc, char* argv[])
{
    FILE* fp;
    long  nImgSize;
    char* pHeader1 = "CSYS";
    long  nHeader2 = 0x80500000;

    if (argc != 3)
    {
        printf("Usage: mksyshdr <header file> <image file>\n");
        return -1;
    }

    fp = fopen(argv[2], "rb");
    if (fp != NULL)
    {
        fseek(fp, 0, SEEK_END);
        nImgSize = ftell(fp);
        fclose(fp);
        fp = fopen(argv[1], "wb+");
        if (fp != NULL)
        {
            fwrite(pHeader1,  sizeof(char), 4, fp);
            fwrite(&nHeader2, sizeof(long), 1, fp);
            fwrite(&nImgSize, sizeof(long), 1, fp);
            fclose(fp);
        }
        else
        {
            printf("Cannot create %s.\n", argv[1]);
            return -1;
        }
    }
    else
    {
        printf("Cannot open %s.\n", argv[2]);
        return -1;
    }

    return 0;
}

de tutorial die ik gebruikt heb:
http://www.student.tue.nl/Q/t.f.a.wilms/adm5120/

wanneer ik de originele firmware opstart en met de seriele verbinding "meekijk" tijdens het booten zie ik op een bepaald punt
RAMDISK: bzip2 compressed image found at block 0
Freeing initrd memory: 1046k freed
VFS: Mounted root (ext2 filesystem).

zoiets moet ik ook zien te krijgen

[irondog]

Wat is nu je probleem dan? Panict je kernel? Krijg je een shell? Waarschijnlijk niet dus...

edit:
Kep het al door. De handleiding die jij volgt, maakt dus gebruik van INITRAMFS (zoals ik al eerder genoemd heb). Bij het volgen van de handleiding compileer je de kernel aan de hand van een kernel-configuratie die de initramfs_source instelt op usr/root van de kernel source tree. M.a.w. De schrijver van de handleiding volgt gewoon een andere aanpak dan die bij originele firmware gebruikt wordt. Dit: RAMDISK: bzip2 compressed image found at block 0 hoef je dus niet te verwachten in de output.

.

Maar als je nu gewoon df niet uit kunt voeren, dan mis je dus de symlink. deze zou je net zo goed aan kunnen maken als het systeem geboot is.

code:

#busybox ln /bin/busybox /bin/df
#df

of gewoon:

code:

# busybox df

Misschien gaat er dus wat fout bij het aanmaken van de initramfs image. Laat anders eens zien hoe je rootfs eruit ziet. Dus loop mounten op je PC er naartoe met cd en even de output posten als je find . -print intypt.

[ Voor 94% gewijzigd door irondog op 04-11-2005 17:10 ]

[nzyme]

neej man, we gaan langs mekaar heen geloof ik iig maak ik dus gebruik van initramfs, is me dat ook duidelijk nu thnx
ik wil dus juist WEL die regel "RAMDISK: bzip2 compressed image found at block 0", maar hoe...

en met df problemen ben ik mss wat wazig geweest, wat ik bedoel is dat de output van het commando niet geeft wat je op je desktop bijv. krijgt. Waar je normaal je devices te zien krijgt is dat nu leeg. Duidelijk ?

[irondog]

Hellraizer schreef op zaterdag 05 november 2005 @ 07:40:
neej man, we gaan langs mekaar heen geloof ik

Ja, het probleem hier is grotendeels de formulering van he probleem.

iig maak ik dus gebruik van initramfs, is me dat ook duidelijk nu thnx

NP.

ik wil dus juist WEL die regel "RAMDISK: bzip2 compressed image found at block 0", maar hoe...

Vergeet dat even. Dat is waarschijnlijk een sweex kernel hack die we helemaal niet kunnen gebruiken. (Zoek de 2.6 kernel source maar eens door ) De vraag voor mij is: "Wat doet dit nu precies wat initramfs niet doet?". Met antwoord op deze vraag kunnen we kijken hoe we dit ook kunnen oplossen. Die gast die die howto geschreven heeft, heeft gewoon nuttig gebruik gemaakt van 2.6 technieken die wat mij betreft volledig equivalent zijn aan wat sweex in haar firmware propt.

en met df problemen ben ik mss wat wazig geweest, wat ik bedoel is dat de output van het commando niet geeft wat je op je desktop bijv. krijgt. Waar je normaal je devices te zien krijgt is dat nu leeg. Duidelijk ?

Dat is doodeenvoudig omdat df /etc/mtab uitleest. Deze zal wel niet bestaan of leeg zijn. (/etc/mtab wordt normaal vanuit scripts en /bin/mount beheerd.) cat /proc/mounts geeft overigens veel nuttigere info.

[nzyme]

code:

# df -h
Filesystem                Size      Used Available Use% Mounted on

code:

# cat /proc/mounts
rootfs / rootfs rw 0 0
/proc /proc proc rw,nodiratime 0 0
devpts /dev/pts devpts rw 0 0
tmpfs /tmp tmpfs rw 0 0

code:

# cat /etc/mtab
rootfs / rootfs rw 0 0
/proc /proc proc rw,nodiratime 0 0
devpts /dev/pts devpts rw 0 0
tmpfs /tmp tmpfs rw 0 0

# ls -l /etc/mtab
lrwxrwxrwx    1 sw33x    root           12 Dec 31 17:00 /etc/mtab -> /proc/mount
s

"RAMDISK: bzip2 compressed image found at block 0" slaat beslist niet op een kernel hack van sweex zelf, het is slaat volgens mij op een rootfs die ik juist in me kernel wil hebben . . . .

code:

/proc # ls -l /proc/kcore
-r--------    1 sw33x    root     16781312 Dec 31 17:03 /proc/kcore

^^ volgens mij is de volledige 16MB sd-ram nu als root aangesproken, right ? (erg kort door de bocht natuurlijk maar ok)

nu wil ik dus niet een initramfs maar een echte ramdisk die een 4MB /dev/ram0 mount op / en een 4MB /dev/ram1 mount op /home de overige 8MB is dan normaal ram. (initrd moet ik dus "maken":?)

offtopic:
Ben ik nou echt zo'n dwaas met mn probleem en formulering

[ Voor 9% gewijzigd door nzyme op 05-11-2005 12:19 ]

[irondog]

Hellraizer schreef op zaterdag 05 november 2005 @ 12:16:

code:

# df -h
Filesystem                Size      Used Available Use% Mounted on

Dit is een simpel probleem, maar moet je echt even zelf analyseren. Misschien is symlinken eenvoudigweg niet OK en moet het een normaal bestand zijn.

"RAMDISK: bzip2 compressed image found at block 0" slaat beslist niet op een kernel hack van sweex zelf, het is slaat volgens mij op een rootfs die ik juist in me kernel wil hebben . . . .

Misschien slaat het op iets wat niet aanwezig is in 2.6.14, maar ik vind dit gewoon nergens terug in de kernel source en Documentatie. Een compressed image (in dit geval dan initramfs) wordt toch ook gewoon gevonden? Of mis je (buiten deze melding) echt iets?

nu wil ik dus niet een initramfs maar een echte ramdisk die een 4MB /dev/ram0 mount op / en een 4MB /dev/ram1 mount op /home de overige 8MB is dan normaal ram. (initrd moet ik dus "maken":?)

Jij wil dus zelf kunnen bepalen hoeveel RAM je toekent aan de RAMDISK, een vaste grootte dus? Een kersverse lege ramdisk met vaste grootte is niet zo'n probleem hoor.

Ramdisks (tmpfs en ramfs) worden in linux automatisch vergroot en verkleind ten koste van vrij RAM. Voor een fixed size moet je een parameter meegeven bij het mounten.

code:

mount -t tmpfs tmpfs /home -o size=4M

Dit moet werken voor /home. Voor / wordt het iets in de geest van:

code:

mount / -o remount,size=4M

offtopic:
Ben ik nou echt zo'n dwaas met mn probleem en formulering

Tis wazig om je te helpen met een probleem waar ik maar half in zit. Ligt niet helmaal aan jou ofzo

[nzyme]

die 2 mount regels zal ik in de fstab verwerken dan als ik weer tijd heb om naar linux te gaan.

die rootfs wordt middels cpio in de kernel gezet, maar bz2 is toch veel effectiever als het om compressie gaat vandaar dus dat ik een initrd (als ik het goed heb) moet zien te maken

[irondog]

Nu is het ook gecomprimeerd hoor. Ge-gzipte cpio namelijk.

[nzyme]

ja duh, dat snap ik ook wel maar ik bdoel dat ik met bz2 meer dingen in mn rootfs kwijt zou moeten kunnen, toch

[irondog]

ff gezocht voor je:
bZimage staat voor Big Zimage en is dus jammer genoeg gewoon gzip.

edit:
Sweex heeft dus wel degelijk zitten rommelen aan de kernel

Er zijn experimentele patches voor bzip2 support in de kernel:
http://shepard.kicks-ass.net/~cc/

Dit geeft niet alleen bz2 mogelijkheden voor initrd, maar het lijkt erop dat deze ook het build systeem van de kernel aanpassen. Daarmee wordt je kernelimage bzip2 i.p.v. gzip. Omdat initramfs deel uitmaakt van de kernel image, zou deze patch voordeel op kunnen leveren (maar het blijft volgens mij dus gzip in een bz2 image via deze patch).

Wat je moet onderzoeken is, of het bz2 comprimeren van een gzip image nog überhaupt iets oplevert. Daarmee zou je toch nog betere compressie kunnen krijgen en meer in je rootfs kunnen proppen.

[ Voor 12% gewijzigd door irondog op 05-11-2005 16:03 ]