Sehr kleines Linux mit aktuellem Kernel

[i_hasser]

So, hab ein kleines Pakete-System implementiert. Aber irgendwas ist bei der libc schief gelaufen, die ist 18mb geworden


Durch das Pakete-System hab ich die größe aber ziemlich gut unter Kontrolle . Mit Bash und Coreutils dürften es jetzt so ca. 3 bis 4mb sein, dabei sind aber die großen Libs schon drinnen (und das rootfs wird ja noch gziped).

 

[i_hasser]

So, also jetzt sieht erstmal alles super aus

Brauch aber trotzdem eure Hilfe


Das Pakete-System hat sich gelohnt, geht jetzt alles wunderbar sauber vonstatten. Der einziger Nachteil - ich muss jede Datei einzeln kopieren (dafür kann ich eben direkt kontrollieren was rein kommt und was nicht, das spart extrem an Größe). Abhängigkeiten von Paketen zueinander hab ich ansatzweise auch schon implementiert. Später schreib ich vielleicht mal einen richtig netten Paket-Konfigurator, so wie zb. das pkgtool bei Slackware (von der GUI her wie menuconfig für den Kernel, aber ein einziges Shell Skript).

Momentan hab ich die nötige libs (ncurses und einige der glibc), die bash und die nötigsten coreutils (cp, ls, mv, rm) drinnen. Das gzipte initrd ist 1.2mb (dazu kommen noch 800kb Kernel)

Also ich brauch von euch noch Vorschläge zu binaries. Manche Pakete enthalten ja teilweise viel "müll", den man nie braucht.

 

[Lopi]

Eine klitzeklitzekleine frage : benutzt Du ein anderes Filesystem

 

[i_hasser]

Ein anderes FS als was? Theoretisch kann man das OS auf alles legen was der Kernel macht - und darüber entscheide ich (oder ihr, wenn ihr den Kernel neu compiliert )

Momentan ist die initrd mit ext2 formatiert, die Containerpartition muss sich jeder selbst anlegen und dabei entscheiden was er nimmt (lilo kann aber eh alles booten).


Das Pakete-System hat mir noch nicht so ganz gefallen. Momentan überarbeite ich das nochmal, so dass das auch leistungsfähiger wird und man im Betrieb Pakete nachinstallieren kann (die sind dann beim nächsten boot aber erstmal wieder draußen).


Ach ja, eine Frage zur bash hab ich noch: Ich brauch ein Konstrukt, das alle Verzeichnisse und Unterverzeichnisse durchsucht, mir die jeweiligen Dateilisten gibt und mich damit was anstellen lässt.

Also eine Art Schleife, bei dem Verzeichnissbaum hier müsste die folgendes ausgeben:

Verzeichnissbaum:

[DIR]  /usr
[FILE] /usr/abc
[DIR]  /usr/local 
[FILE] /usr/local/abc
[FILE] /usr/local/def
[DIR]  /usr/local/share

In einer Schleife müsste ein Variable dann alle die Werte nacheinander annehmen:

/usr
/usr/abc
/usr/local
/usr/local/abc
/usr/local/def
/usr/local/share

 

[Lopi]

z.B. squash (RO) gute komprimierung, jffs (RW) aber buggy

edit: gibt's ein sneak.tar

 

[i_hasser]

Hmm... hab schon gegoogelt, wie übergibt man eigentlich arrays in Skripten?

Also sowas:

Skript 1:
./skript2
echo $a

Skript 2:
a=abc


Ausgabe:
abc

Das bräuchte ich für Variablen und für Arrays.


Ein Preview gibts vielleicht morgen abend. Ich muss jetzt erstmal die Pakete-Sache fertigmachen. Aber weitaus länger dauert es die einzelnen Pakete zu kompilieren und die nötigen Sachen herauszufischen.

 

[Wildy]

Original geschrieben von intel_hasser
(lilo kann aber eh alles booten).

Bist du dir wirklich sicher, dass es da auf lilo ankommt? Imho springt lilo nur an eine Speicheradresse und ab da übernimmt der Kernel (mal mit meinen unprofessionellen Worten ausgedrückt).

Mit Skript meinst du bash?

 

[i_hasser]

Ja, die bash meine ich.

Das mit den Verzeichnissbäumen ist nicht mehr so wichtig, die Parametersache ist wichtig (vielleicht könnte ich da notfalls über env gehen).


Lilo speichert sich die Sektorpositionen von allem was geladen werden soll (kernel und initrd). Dadurch ist lilo eben fs unabhängig - dafür muss man aber sowie man den Kernel oder die initrd ändert lilo neu installieren.

 

[i_hasser]

Klasse, hab irgendwo gelesen, dass es nicht geht. Man kann in einer subshell deklarierte Variablen/Werte nicht an die parent-shell übergeben.

Die ganzen Skriptsprachen sehen auf den ersten Blick ziemlich gut aus, aber irgendwie fehlt immer das wichtigste. Das ist jetzt schon das 2. mal, dass mir sowas passiert.

Da werd ich jetzt mal schauen ob ich das mit Perl machen kann... wollte schon immer mal mit Perl anfangen

 

[i_hasser]

Puh, doch nochmal glück gehabt... kann mich auch weiterhin um Perl drücken

mit source geht ein relativ einfacher hack.

 

[LOCHFRASS]

Wie viel RAM frisst so ein Linux eigentlich? Ich hab hier nen Amiga CD32 rumstehen (16 MHz 68EC020, 2 MiB RAM), könnte man den als MP3-Player unter Linux missbrauchen?

 

[i_hasser]

Na das nun vielleicht nicht, aber ein 486er ~100MHz mit 32mb Ram könnte ausreichen (die init ramdisk ist eben etwas größer, sonst würden 16mb auch reichen).

Ich schreib hier gerade am Pakete-Installer. Es wird (vorraussichtlich) möglich sein Pakete im Betrieb dazuzuinstallieren und dann auch wieder zu entfernen.

Die Pakete enthalten Abhängigkeiten und einen Dateienverzeichnis, das dürfte dann also ziemlich komfortabel vonstatten gehen. Es wird 2 Installationsmodi geben - hard und soft.
Bei einer hard installtion wird das Paket wie gewohnt installiert (alle Dateien nach root kopiert usw.) - bei einer soft installation wird dagegen alles symbolisch reingelinkt (ergo wird auf dem rootfs praktisch kein Speicher verbraucht).

So kann man zb. den C Compiler wenn man ihn denn mal braucht schnell von einer CD per soft installation einbinden, das wasauchimmer compilieren und den compiler dann wieder bequem entfernen. So passt die eigentliche Installtion auf den USB Stick und man kann trotzdem noch andere Progs neu compilieren etc.

Dazu kennen die Pakete auch noch Interfaces. Das kapselt die Pakete etwas mehr voneinander ab und erleichtert die Abhängigkeiten enorm. Und es wird von vielen Paketen mehrere Versionen geben (sowas wie coreutils1 und coreutils2), die je verschieden viele der Befehle implementieren (man könnte das auch so gestallten, dass 1 nur die wichtigsten Dateien enthält und 2 dann noch einige optionale oder wie eben auch immer).


Dann soll es auch noch die Möglichkeit geben Pakete beim booten automatisch installieren zu lassen. So enthält die initrd nur noch die allerwichtigsten Pakete und der Rest wird dann bei jedem Start neu in eine Ramdisk kopiert (der USB Stick ist ja eher langsam, aber gegen eine soft installation spricht auch nix).

Das Pakete-Installations-Skript ist so auf halbem Wege, eigentlich fehlt nur noch ein bisschen Copy&Paste (und die Abhängigkeiten). Vielleicht mach ich auch noch eine kleine Datenbank ins rootfs, die enthält welche Pakete installiert sind (kann man ja direkt ins FS implementieren, also touch $paketname in irgend einem speziellen Verzeichnis).



€: Der 1. brauchbare Pakete-Installer ist fertig geworden. Ich sag besser nicht wie lange ich heute an Ihnux rumgefrickelt hab

 

[_fire]

Original geschrieben von intel_hasser
Hmm... hab schon gegoogelt, wie übergibt man eigentlich arrays in Skripten?

Also sowas:

Skript 1:
./skript2
echo $a

Skript 2:
a=abc


Ausgabe:
abc

Das bräuchte ich für Variablen und für Arrays.

nur der vollstaendigkeit halber kannst du auch sowas machen:

--- script2 ---
echo -e "a\nb\nc"

--- script1 ---
x=$(./script2)
echo -e "$x"

--- output script1 ---
a
b
c

viel glueck noch mit deinem projekt. ist echt goil

 

[i_hasser]

Momentan hab ich es so gelößt:

Skript1:
a="skript2.sh"
b=1

echo $b
source $a
echo $b

Skript2:
$b=2

Ausgabe:

1
2


Ich weis eben nicht ob das source auch für inline gedacht war (hab extra kein . genommen damits nicht portabel auf andere Shells ist wo das vielleicht definitiv nicht so ist).

Das mit der Ausgabe ist natürlich auch eine Möglichkeit. Hatte schon überlegt für jedes Paket eine propritäre Config-Datei anzulegen und die dann mit xyz=`cat configdatei` einzulesen (im Nachhinein ist man ja immer schlauer ).

An die Bash muss man sich erstmal gewöhnen. Das Einlesen der Ausgabe dürfte mir dann einiges an Aufwand bei einem graphischen Utility abnehmen.

 

[Wildy]

#!/bin/bash

wegen der anderen Shells (in die erste Zeile des Skrikpts)

 

[i_hasser]

Steht mit drinnen, habs nur nicht mit hingeschrieben

So, ich mach mich jetzt wieder an die Arbeit - Pakete schnüren.

 

[_fire]

Original geschrieben von intel_hasser
Ich weis eben nicht ob das source auch für inline gedacht war (hab extra kein . genommen damits nicht portabel auf andere Shells ist wo das vielleicht definitiv nicht so ist).

zum einlesen von config files nehmen ich eigentlich immer . oder source. das nimmt viel arbyte ab... 8)

Original geschrieben von intel_hasser
An die Bash muss man sich erstmal gewöhnen. Das Einlesen der Ausgabe dürfte mir dann einiges an Aufwand bei einem graphischen Utility abnehmen.

wie willst du das gfx utility schreiben? bash kann ja kein ncurses. eine moeglichkeit waere perl, python oder wie z.b. im kernel (menuconfig) das paket "dialog". (ok, der kern verwendet eine modifizierte version davon)

dialog waere wahrscheinlich das einfachste, aber ich weis nicht genau, was man damit so alles machen kann. (hier ist ne kleine anleitung dazu)

_fire

 

[i_hasser]

Dann werd ich mal die Anleitung durcharbeiten.

Was man mit der Bash so alles machen kann weis ich - hab ja nicht umsonst Slackware

Das gesamte Installationssetup ist ein bash Skript (mit schöner GUI und allem), der Slackware Pakete Manager ist bash, und solche Sachen wie zb. netconfig (Netzwerkkonfiguration mit schöner GUI) sind auch bash.

Slackware eben




Ich mal mal eine kleine Liste der Pakete die ich inzwischen fertig hab:

• bash_1-2.05b
• glibc_1-2.3.2
• ncurses_1-5.4
• sysvinit_1-2.8.5
• coreutils_1-5.2.1
• util-linux_1-2.12a
• util-linux_2-2.12a
• module-init-tools_1-0.9.15-pre4

 

[i_hasser]

Hier ist mal der Config-Teil vom glibc Paket.

#!/bin/bash

## Package description
pkg_frmtver=2			# packet desc version			
pkg_contver="2.3.2"		# content version
pkg_contmarch="i686"		# target of content
pkg_iname="glibc_1"		# interface name 
pkg_subname="glibc"		# textual packet name 
pkg_desc=""			# possible description

## Files in packet
pkg_files[0]=3					# how many files
pkg_files[1]="/lib/ld-2.3.2.so"			# dynamic linker
pkg_files[2]="/lib/libc-2.3.2.so"		# clib
pkg_files[3]="/lib/libpthread-0.10.so"		# possix threads

## Links in packet (NOTE: Version 2 specific)
pkg_links=3	# we have 3 links

pkg_links_name[1]=   /lib/ld-linux.so.2		# link name and position
pkg_links_type[1]=   1				# link type (1 -> take out of pkg_files, 2 -> pkg_dirs)
pkg_links_target[1]= 1				# link target 		

pkg_links_name[2]=   /lib/libc.so.6
pkg_links_type[2]=   1
pkg_links_target[2]= 2

pkg_links_name[3]=   /lib/libpthread.so.0
pkg_links_type[3]=   1
pkg_links_target[3]= 3

## Dirs in packet
pkg_dirs[0]=1
pkg_dirs[1]="/lib"	

## iname dependencies
pkg_idep[0]=0

Was meint ihr, sollten da noch Zugriffsberechtigungen rein? Eigentlich kann man die ja schon im Pakete-Baum setzen.

 

[i_hasser]

So, glibc Paket ist fertig und der Installer unterstützt jetzt auch die Paketversion 2.

Hab mal ne Frage - wie kann ich am dümmsten ermitteln ob eine Datei existiert? find xyz gibt eine Fehlermeldung aus wenn xyz nicht exisitert, und die Meldung kann ich nicht von der Konsole wegleiten.

 

[_fire]

ein mal "man test".
z.b.

if [ ! -f "blub" ]; then
  echo "datei existiert nicht"
  exit 1
fi

 

[i_hasser]

besten dank

€

Der Pakete Installer funktioniert schonmal - hab das jetzt alles in ein Skript gepackt. Gibts eigentlich einen Befehl der überflüssige "/" entfernt?

 

[_fire]

ja

echo "/blub/dingens/" | sed 's|/$||g'

 

[i_hasser]

Ist ja ein echter Expressservice hier

Aber funktioniert leider noch net vollständig -

echo "///blub///dingens///" | sed 's|/$||g'

lässt noch ein paar / stehen. Aber das ist nicht so schlimm, wenns da keine Methode gibt muss ich eben jeden Pfad einzeln seiner letzten / berauben

 

[i_hasser]

Alternativ würde es auch erstmal reichen nur die vorderen / wegzuschneiden. Aber so wichtig ist das alles sowieso nicht, dann zeigen die symbolischen links im lib verzeichnis eben nach //lib/...