es ist mal wieder ein Mini-System gefragt. Meine Grenze liegt bei 250MB, weniger (~100MB) waere besser. Normalerweise baue ich sowas selbst, aber diesmal haette ich gern ein Paket Management. Ich habe an ein Debian testing mit Kernel 2.6.x auf ext2 gedacht. Natuerlich das minimalste ueberhaupt, was geht, hauptsache es bootet (und kann Scripte ausfuehren).
Dummerweise will es mir gerade nicht gelingen, dem Installer bzw. APT abzugewoehnen, alle moegliche Dokumentation, manpages, Kernelmodule fuer meinen Toaster und lauter so Zeug (nein, ich brauche keine locale fuer Finnisch) zu installieren. Das blaeht tierisch auf.
Irgendwelche Ideen? Ich habe mal was von „bootstrap“ gehoert, kann das das? Wenn ja, wie? Wenn ich danach google finde ich irgendwelche Anleitungen fuer PowerPC, ist aber ein gewoehnlicher i586.
Normalerweise baue
ich sowas selbst, aber diesmal haette ich gern ein Paket
Management.
Aua.
Dummerweise will es mir gerade nicht gelingen, dem Installer
bzw. APT abzugewoehnen, alle moegliche Dokumentation,
manpages, Kernelmodule fuer meinen Toaster und lauter so Zeug
(nein, ich brauche keine locale fuer Finnisch) zu
installieren.
Der Installer wird das immer tun. Installier erstmal auf eine normale Platte und streich danach alles raus was nicht sein muss (ich würd schonmal mit 2.6 anfangen, 2.4/2.2 sind kleiner).
Um z.B. die man-Pages loszuwerden: man-db deinstallieren.
Dann installier localpruge um überflüssige locals loszuwerden.
Beim Kernel kommst du an eine Neucompilieren nicht vorbei. Die Module unterliegen eben nicht apt…
Ich habe mal was von „bootstrap“ gehoert,
kann das das?
Das ist ein Installer/bootmanger… das ist nicht das richtige.
ist zwar schon ein bisschen her, aber Potato (Joel Espy K.-Release) hatte ich mal für nen Gateway auf ca. 70 MB gedrückt (swap nicht mitgerechnet), sollte eigentlich auch bei sarge so sein. Hab einfach mit dselect alles Unnötige rausgeworfen (und dselect ist doch sehr komfortabel, oder etwa nicht? - zum Entfernen einfach immer „_“ und nicht „-“ nehmen).
Grüssle,
Markus
ist zwar schon ein bisschen her, aber Potato (Joel Espy
K.-Release) hatte ich mal für nen Gateway auf ca. 70 MB
gedrückt
Ich könnte mir nur vorstellen, daß Potato mit 2.6.x-Kernel
etwas nervig wird …
hm, also bei der Release war schon ein 2.6er nativ bei… ähm wieso sollte es dann probleme geben? muß ja nur die… weiß grad nicht den genauen paketnamen, aber die fileutils halt zum kernel passen, oder sonst noch was.
außerdem: der 2.6 _ist_ doch per se nervig
Da hab ich großen Bullshit erzählt. (Und ich kann mir grad auch nicht erklären, wie es dazu kam. Hmm…
sorry
Hier nix 2.6.
o.k. mit „nativ“ meinte ich: als
paket, nicht generisch.
ich meinte: nicht als installkernel (2.4. und 2.2 gibts als installkernel)
Bleibt wohl nur Sarge (ich verwende seit nem Jahr nur noch Sarge); das hat definitiv 2.6.
2.6.x ist ein Muss. Der 2.4.x unterstuetzt kaum Sensoren.
Ist wichtig.
Was für wichtige Sensoren denn, die 2.4 nicht kennt?
Uh, glaub mir, das moechtes Du nicht wissen. So wie es aussieht materialisieren sich hier demnaechst in einem stino PC etwa 100 I2C-Buse mit Sensoren dran[1], ueber die ich noch gar nicht nachdenken will. Nein, ich will das wirklich nicht mit 2.4.x bauen.
Gruss vom Frank.
===footnotes===
[1] BTW: weiss jemand, ob es eine harte Grenze fuer die Anzahl der I2C-Buse bzw. den Sensoren gibt, die der Kernel verwalten kann?
Was für wichtige Sensoren denn, die 2.4 nicht kennt?
So wie es
aussieht materialisieren sich hier demnaechst in einem stino
PC etwa 100 I2C-Buse mit Sensoren dran[1], ueber
die ich noch gar nicht nachdenken will. Nein, ich will das
wirklich nicht mit 2.4.x bauen.
Ähm und wieso Treiber für I^2 auf einem Minimalsystem bauen??
Was für Sensoren bitte?
Gruß,
Markus
ich weiss nicht, was ihr gegen den 2.6.x-er Kernel habt, wenn es um die Größe geht. Der 2.6er lässt sich erheblich schlanker gestalten, als ein 2.4er. Natürlich nur, wenn man weiss, was man tut und was man braucht. Meine Erfahrung bezüglich embedded systemen auf ARM9 Basis ist jedenfalls, das es mit dem 2.6er kompakter ging, als mit 2.4. Auch die „fast“ echtzeit Erweiterungen sind – gerade wenn es um Sensoren geht – wünschenswert.