Sehr kleines Linux mit aktuellem Kernel
- Ersteller i_hasser
- Erstellt am
Ja, na momentan funktioniert das Skript so halbwegs (muss eben so einiges per search and replace ändern), aber wenn ich mal irgendwann ein autmatisiertes Paketerstellungsskript schreibe kommt das dann damit rein.
full ack.
genau dafuer sind bash scripte da. um mal schnell einen "kruden hack" zu machen
. wieso soll ich mich mit perl abmuehen oder ein awk programm schreiben, wenns auch mit standard utils wie find wunderbar geht? und da das ganze nix spezielles macht, und wahrscheinlich auch nie was anderes machen wird, finde ich den aufwand fuer absolut nicht gerechtfertigt.
zudem wirst du in perl auch nix anderes machen, als find aufzurufen. alles andere waere viel zu aufwendig, stichwort "das rad neu erfinden".
aber du darfst gerne das ganze nachcoden. ich werde dich davon bestimmt nicht abhalten. 8)
PuckPoltergeist
Grand Admiral Special
Nun, wenn ich das richtig verstanden habe, soll das eine zumindest rudimentäre Paketverwaltung werden, und die macht man nicht mehr mittels bash oder einer anderen shell.
willst du etwa auf meinem Slackware rumhacken? 
Wie gesagt, hier funktioniert alles über die bash - auch die Paketeverwaltung. Und das tut sie auch recht gut.
Die Paketeverwaltung soll nicht nur rudimentär sein, sondern voll ausgereift. In der aktuellen Paketestruktur ist schon fast alles mit drinen was rein muss (inzwischen gibts auch 4 link typen), das install Skript unterstützt Installationsverzeichnisse (so kann ich mich im Nachhinein entscheiden wo ein Paket hin soll) und Abhängigkeiten sind grundsätzlich auch schon drinnen.
Aber keine Angst, hab schon Ideen für die Formatversion 3 und 4
Vielleicht wird da ja später eine richtig große Distri drauß, und es kostet ja nix die Paketeverwaltung schon jetzt ausreichend zu dimensionieren. In den nächsten Paketeversionen will ich auf jeden Fall das Spliting von Paketen noch weiter implementieren (momentan geht das über die _1 die bei fast jedem Paket dranhängt - bei util-linux gibts schon _1 und _2, das eine sind die root utils und das andere die user utils - später soll es dann ein großes Paket geben das alles enthält und alternativ vielleicht viele kleine die je nur Teile wie zb. die bins, die libs und die mans implementieren).
Das kann man alles schön in einer Klassenstruktur darstellen
Das wichtigste ist ja nicht der Installer, sondern das getopt Skript - so wie ich das mitbekommen hab bringen die Pakete bei zb. Slackware auch eigene Installationsskripts mit, die Ihnux Pakete enthalten nur eine Config Datei die sagt welche Dateien, Verzeichnisse usw. drinnen sind, welche Abhängigkeiten etc - alles läuft dann über ein zentrales Installationsskript (das man beliebig austauschen kann).
Die zlib ist eben fertig geworden und ich hab kbd etwas verkürzt (von ~500 auf ~130 Files). Das rootfs ist jetzt 4.2MiB groß.
Wie gesagt, hier funktioniert alles über die bash - auch die Paketeverwaltung. Und das tut sie auch recht gut.
Die Paketeverwaltung soll nicht nur rudimentär sein, sondern voll ausgereift. In der aktuellen Paketestruktur ist schon fast alles mit drinen was rein muss (inzwischen gibts auch 4 link typen), das install Skript unterstützt Installationsverzeichnisse (so kann ich mich im Nachhinein entscheiden wo ein Paket hin soll) und Abhängigkeiten sind grundsätzlich auch schon drinnen.
Aber keine Angst, hab schon Ideen für die Formatversion 3 und 4
Vielleicht wird da ja später eine richtig große Distri drauß, und es kostet ja nix die Paketeverwaltung schon jetzt ausreichend zu dimensionieren. In den nächsten Paketeversionen will ich auf jeden Fall das Spliting von Paketen noch weiter implementieren (momentan geht das über die _1 die bei fast jedem Paket dranhängt - bei util-linux gibts schon _1 und _2, das eine sind die root utils und das andere die user utils - später soll es dann ein großes Paket geben das alles enthält und alternativ vielleicht viele kleine die je nur Teile wie zb. die bins, die libs und die mans implementieren).
Das kann man alles schön in einer Klassenstruktur darstellen
Das wichtigste ist ja nicht der Installer, sondern das getopt Skript - so wie ich das mitbekommen hab bringen die Pakete bei zb. Slackware auch eigene Installationsskripts mit, die Ihnux Pakete enthalten nur eine Config Datei die sagt welche Dateien, Verzeichnisse usw. drinnen sind, welche Abhängigkeiten etc - alles läuft dann über ein zentrales Installationsskript (das man beliebig austauschen kann).
Die zlib ist eben fertig geworden und ich hab kbd etwas verkürzt (von ~500 auf ~130 Files). Das rootfs ist jetzt 4.2MiB groß.
@PuckPoltergeist:
klar, nur zu dem zeitpunkt brauchte intel_hasser nunmal eine schnelle loesung.
nur die frage ist, wie aufwendig das ganze wird. und ob es sich dahingehend lohnt, es "aufwendiger" zu gestalten. das sollte man sich vorher ueberlegen. und evt. gibts sowas ja schon. keine ahnung, aber das internet ist gross, und irgendjemand wird doch wohl schonmal so ein aehnliches problem gehabt haben. warum nicht sowas anpassen?
und, auch bash scripte koennen grosse und aufwendige aufgaben loesen. wenn man denn bash coden kann ...
oh, und awk wuerde sich fuer eine paketverwaltung auch nicht wirklich eignen. awk ist fuer text-processing da, und das kann es super, alles andere, naja ...
perl ist eine moeglichkeit, aber du kannst es auch in python oder einer anderen interpretierenden sprache machen. was man halt gerade kann.
ah, nochwas. kannst du mir den bitte mal naeher erklaeren,warum sich bashing nicht fuer so eine aufgabe eignet. irgendwelche gruende musst du mir schon mal nennen.![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
klar ist das auch irgendwo glaubens- und ansichtssache. jeder wird wohl seinen favoriten auswaehlen. ich wuerde intel_hasser empfehlen, das zu nehmen, was er kann, oder alternativ was er lernen will.
@intel_hasser:
hier eine neue version des scriptes. diesmal etwas sauberer, und mit einer loesung fuer das / problem:
klar, nur zu dem zeitpunkt brauchte intel_hasser nunmal eine schnelle loesung.
nur die frage ist, wie aufwendig das ganze wird. und ob es sich dahingehend lohnt, es "aufwendiger" zu gestalten. das sollte man sich vorher ueberlegen. und evt. gibts sowas ja schon. keine ahnung, aber das internet ist gross, und irgendjemand wird doch wohl schonmal so ein aehnliches problem gehabt haben. warum nicht sowas anpassen?
und, auch bash scripte koennen grosse und aufwendige aufgaben loesen. wenn man denn bash coden kann ...
oh, und awk wuerde sich fuer eine paketverwaltung auch nicht wirklich eignen. awk ist fuer text-processing da, und das kann es super, alles andere, naja ...
perl ist eine moeglichkeit, aber du kannst es auch in python oder einer anderen interpretierenden sprache machen. was man halt gerade kann.
ah, nochwas. kannst du mir den bitte mal naeher erklaeren,warum sich bashing nicht fuer so eine aufgabe eignet. irgendwelche gruende musst du mir schon mal nennen.
klar ist das auch irgendwo glaubens- und ansichtssache. jeder wird wohl seinen favoriten auswaehlen. ich wuerde intel_hasser empfehlen, das zu nehmen, was er kann, oder alternativ was er lernen will.
@intel_hasser:
hier eine neue version des scriptes. diesmal etwas sauberer, und mit einer loesung fuer das / problem:
Code:
#!/bin/bash
if [ $# -ne 1 ]; then
echo "syntax: $0 <dir>"
exit 1
fi
FROM=$(echo "$1" | sed 's|/$||')
PK_DIR="pkg_dirs"
PK_FILES="pkg_files"
PK_LINKS="pkg_links"
# find (list, prefix, root)
function output() {
local list="$1"
local prefix="$2"
local root="$3"
local num=0
local count=1
if [ -n "$list" ]; then
num=$(echo "$list" | wc -l)
fi
echo "$prefix""[0]=""$num"
for item in $list; do
name=$(echo "$item" | sed "s|$root||")
echo "$prefix""[$count]=$name";
let count+=1;
done
}
DIRS=$(find "$FROM" -type d | grep -v "^$FROM$")
FILES=$(find "$FROM" -type f)
LINKS=$(find "$FROM" -type l)
output "$DIRS" "$PK_DIR" "$FROM"
echo
output "$FILES" "$PK_FILES" "$FROM"
echo
output "$LINKS" "$PK_LINKS" "$FROM"Danke, das nächste Paket kommt bestimmt
Nur mal so als kleine Zusammenfassung - die Pakete gibts bereits:
bash_1-2.05b
coreutils_1-5.2.1
glibc_1-2.3.2
gzip_1-1.3.5
joe_1-3.0
kbd_1-1.12
module-init-tools_1-0.9.15-pre4
ncurses_1-5.4
shadow_1-4.0.4.1
sysvinit_1-2.8.5
util-linux_1-2.12a
util-linux_2-2.12a
zlib_1-1.2.1
Im Moment rattert ein neuer Kernel (wahrscheinlich ~100kb größer als der alte
) durch, der kann dann auch Netzwerk (und vorsorglich zu Testzwecken schonmal den AMD PCNet Adapter den VMWare emuliert - natürlich als Modul ).
ATA HDD Support kommt auch gleich mit als Modul dazu.
Nur mal so als kleine Zusammenfassung - die Pakete gibts bereits:
bash_1-2.05b
coreutils_1-5.2.1
glibc_1-2.3.2
gzip_1-1.3.5
joe_1-3.0
kbd_1-1.12
module-init-tools_1-0.9.15-pre4
ncurses_1-5.4
shadow_1-4.0.4.1
sysvinit_1-2.8.5
util-linux_1-2.12a
util-linux_2-2.12a
zlib_1-1.2.1
Im Moment rattert ein neuer Kernel (wahrscheinlich ~100kb größer als der alte
) durch, der kann dann auch Netzwerk (und vorsorglich zu Testzwecken schonmal den AMD PCNet Adapter den VMWare emuliert - natürlich als Modul ).ATA HDD Support kommt auch gleich mit als Modul dazu.
So, ich glaub für heute wars das erstmal (ok, irgendwo glaub ich das ja selbst nicht, aber ich will wenigstens sagen können, dass ich versucht habe mich davon loßzureißen ).
Ein paar Dinge muss ich mit dem Autoloader noch abklären (-> wird aus dem Kernel geschmissen). Hab aber eben erfolgreich die IDE Module geladen und die Boot-HDD gemountet. Der Kernel selbst ist nur um ~50kb größer geworden (hab einen der IO Sheduler rausgeworfen), das rootfs um ~100kb.
Ich denk ich werd das in mehrere Ramdisks splitten, ich werd auch mal sehen was der Kernel zu bzip2 meint - damit ist das rootfs nämlich nur 3.8mb groß.
). Ein paar Dinge muss ich mit dem Autoloader noch abklären (-> wird aus dem Kernel geschmissen
). Hab aber eben erfolgreich die IDE Module geladen und die Boot-HDD gemountet. Der Kernel selbst ist nur um ~50kb größer geworden (hab einen der IO Sheduler rausgeworfen), das rootfs um ~100kb. Ich denk ich werd das in mehrere Ramdisks splitten, ich werd auch mal sehen was der Kernel zu bzip2 meint - damit ist das rootfs nämlich nur 3.8mb groß.
D
derkostka
Guest
Danke für das mini-Howto ich werde mir das ganze mal anschauen.
Muss ich denn auf dem Stick eine Partition mit ext2 Dateisystem erstellen oder geht auch einfach das vorhandene Fat ?
Ich möchte ja auch nebenbei den Stick auf Windows Rechnern nutzen, zum Dateiaustausch.
Muss ich denn auf dem Stick eine Partition mit ext2 Dateisystem erstellen oder geht auch einfach das vorhandene Fat ?
Ich möchte ja auch nebenbei den Stick auf Windows Rechnern nutzen, zum Dateiaustausch.
Ja, was du willst - wie gesagt, lilo frisst alles
Fat ist hier unkrittisch, weil auf der Partition eh nur das rootfs liegt (und das ist sowieso in ext2).
Du kannst die Verzeichnisse auch nach belieben ändern.
Fat ist hier unkrittisch, weil auf der Partition eh nur das rootfs liegt (und das ist sowieso in ext2).
Du kannst die Verzeichnisse auch nach belieben ändern.
PuckPoltergeist
Grand Admiral Special
Original geschrieben von intel_hasser
willst du etwa auf meinem Slackware rumhacken?
Wie gesagt, hier funktioniert alles über die bash - auch die Paketeverwaltung. Und das tut sie auch recht gut.
Die Paketeverwaltung soll nicht nur rudimentär sein, sondern voll ausgereift.
Dann zeugt es nicht gerade von Weitsicht da mit der bash herum zu hacken. Für solche Sachen sind shell-scripte absolut nicht geeignet, da sollte man schon auf Sprachen ausweichen, die sich insebsondere in string- und Zeichenbehandlung auszeichnen. Nur mal zum Vergleich, dpkg ist schon kein script mehr, das ist ein elf-binary. Selbiges gilt für apt.
Wenn du also eine richtige Paketverwaltung realisieren willst, dann plane das gleich richtig. Debian wurde immer wieder zurück geworfen, weil essentielle Änderungen an dpkg notwendig wurden, die anfangs nicht bedacht waren. Du tust dir keinen Gefallen jetzt etwas schnell per shell hinzuhacken, und das dann alle paar Wochen wieder umzustoßen. Wie schon geschrieben, bieten sich hierfür sowohl perl als auch awk, welches explizit fürs Prototyping entworfen wurde, an.
PuckPoltergeist
Grand Admiral Special
Original geschrieben von _fire
nur die frage ist, wie aufwendig das ganze wird. und ob es sich dahingehend lohnt, es "aufwendiger" zu gestalten. das sollte man sich vorher ueberlegen. und evt. gibts sowas ja schon. keine ahnung, aber das internet ist gross, und irgendjemand wird doch wohl schonmal so ein aehnliches problem gehabt haben. warum nicht sowas anpassen?
Sicherlich, aber das ganze "Projekt" scheint mir wie immer einfach drauf los gehackt.
und, auch bash scripte koennen grosse und aufwendige aufgaben loesen. wenn man denn bash coden kann ...
Sicherlich lassen sich mit shell-scripten auch große Sachen realisieren. Es ist nur die Frage, ob das den Aufwand rechtfertigt. Für eine Paketverwaltung ist es nicht geeignet.
Falsch, wie oben schonmal geschrieben ist awk eine Sprache für Prototyping. Darin wurden schon Compiler realisiert. Auf Grund seiner Nähe zu C ist das auch gar nicht so abwegig. Awk eignet sich hervorragend, um eine Idee zu testen. Später kann die dann in einer anderen Sprache realisiert werden, welche für das entsprechende Problem vielleicht besser geeignet ist.
Ein Kriterium beim Entwurf von awk war, dass es sehr gut mit Zeichenketten umgehen und sie manipulieren kann. Deshalb habe ich es auch für dieses Problem vorgeschlagen.
Perl wäre auch eine Überlegung, weil es bei der Zeichen(-ketten)behandlung awk nochmal überlegen ist. Larry Wall hat perl ja entworfen, weil awk bei der Lösung von seinen Problemen die Puste ausgegangen ist (welche Probleme das waren, weiß ich jetzt aber auch nicht).
ah, nochwas. kannst du mir den bitte mal naeher erklaeren,warum sich bashing nicht fuer so eine aufgabe eignet. irgendwelche gruende musst du mir schon mal nennen.
Shell-sripte sind nicht dafür gedacht in großem Stil zur string-Verarbeitung herzuhalten. Das wird sehr schnell sehr aufwändig.
klar ist das auch irgendwo glaubens- und ansichtssache. jeder wird wohl seinen favoriten auswaehlen. ich wuerde intel_hasser empfehlen, das zu nehmen, was er kann, oder alternativ was er lernen will.
Ich würde ihm empfehlen sich schlau zu machen, welche tools für das anstehende Problem am besten geeignet sind, und dann davon eins auszuwählen. Bedeutet natürlich, sich erst einmal mit dem anstehenden Problem auseinander zu setzen.
Also ich will jetzt hier keinen Streit provozieren, aber ich denke doch, dass die Slackware Leute wissen warum sie fast alles als Skript realisiert haben (wie gesagt - das Installationssetup auf der Slackware CD ist auch nur ein Skript, ebenso netconfig und noch einige andere Progs).
Aber ich hab die Paketverwaltung doch eh 2-geteilt. Es gibt einmal in jedem Paket die Datei "getopt" - die sieht zb. so hier aus:
Die Datei ist nur zu Dokuzwecken, da implementier ich alles was die Paketversion kann und dokumentiere es etwas (so, dass ich mich da später wieder durchfinde).
"pkg_frmtver=2" - das ist am wichtigsten. Das gibt an, welche Version die getopt ist, und demnach was da drinnen steht und was eben nicht.
Neben den zu installierenden Dateien und der getopt ist erstmal nix weiter im Paket. Der 2. Teil ist der Installer, den man schreiben kann wie und worin man will. Der Pakete Installer muss nur die getopt realisieren bzw. umsetzen, mehr nicht.
Die Version 2 enthält wie du siehst schon eine ganze Menge an Möglichkeiten (Erzeugung von Links in allen Spielarten, Abhängigkeiten, ein paar Paketbeschreibungen und ein Interface, nämlich pkg_iname).
Die Version 2 schreibt vor was in der getopt zu kommen hat und wie das interpretiert wird. Ein Pakete Installer prüft also vor der Installation welche Version das Paket hat und installiert das dementsprechend.
Ich kann jetzt problemlos alle neuen Pakete in der imaginären Version 3 verfassen, der Installer muss trotzdem mit der Version 2 zurrecht kommen. Die Angabe von Files/Links ist fest vorgegeben (pkg_{file,link,dir}s=xyz), also man bräuchte das Skript nichtmal durch die bash jagen, sondern könnte gleich den kompletten Code manuell auswerten.
Das durch die bash jagen bietet sich hier aber an, da wir die Werte danach einfach über die Umgebungsvariablen auslesen können
Für die nächsten Formatversionen hab ich ungefähr sowas hier geplant:
- deutlich erweiterte Interfaces (dient zum Aufsplitten von Software in mehrere optionale Teilpakete)
- Interface Versionen (gibts momentan noch garnet)
- stark aufgebohrte Dependencies
- Build Informationen (Compilerflags und sowas)
Dadurch werden die Version 2 Pakete ja aber nicht überflüssig - die können dann trotzdem noch vom (idealerweise selben) Paketeinstaller installiert werden.
Wie dann der Paketeinstaller realisiert ist wird ja überhauptnicht vorgegeben, das kann bash sein, perl, awk, ein C Programm, ein Fortran Programm
, Java, weis der Geier eben was - alles ist möglich. Die Progs müssen nur (sofern sie getopt nicht durch die bash jagen und die env Variablen auslesen) die Variablenzuweisungen genauso wie die bash 2.x interpretieren.
Übrigens bieten die Pakete auch die Möglichkeit den Installationspfad relativ zu / zu verändern (daher auch so ein Hickhack mit den Links). Also ich kann zb. die fertigen Coreutils hininstallieren wo ich will (nach /, nach /usr oder was weis ich).
Kein einziges Paket hat /usr oder sowas fest verdrahtet - bei den util-linux (wo es vom Install-Skript fest verdrahtet ist) hab ich das Paket zb. in 2 Teile gesplittet, das eine Paket installiert mein mkinitrd (das Skript baut das komplette ihnux neu) nach / und das andere nach /usr.
Versuch das mal mit einem rpm
€: Die größte Änderung die noch ansteht (wirkt sich aber auch nicht auf alte Pakete aus) ist die Trennung von Interface und Paket. Dadurch lassen sich sachen wie zb. die busybox besser integrieren, und es gibt nicht tausende Pakete die doch nur ein Programm implementieren (und Abhängigkeiten können besser erkannt werden wodurch sich mehr unnützes Zeug ausmißten lässt).
Also die glibc stellt dann zb. mehrere Interfaces zur Verfügung, wovon eines das Vorhandensein von /lib/libc-* und /lib/ld-* beschreibt. Die Core-utils wären dann zb. nur von diesem Interface abhängig, die glibc enthält ja aber auch noch tausende andere libs. Das Interfaces könnte man sogar noch für den Pakete-Installer verständlich beschreiben (das hat nun rein garnix mit den Paketen selbst zu tun), so könnte der Pakete-Installer auch nachprüfen ob die Pakete auch tatsächlich die angegebenen Interfaces implementieren.
Später will ich noch implementieren, dass der Pakete-Installer die getopts der einzelnen Pakete entsprechend dem Paketnamen(+Version+alleswasdasPaketeinzigartigmacht) in ein bestimmtes Verzeichniss in der Distri installiert, damit man das später auch wieder rauswerfen kann (das hat jetzt nix mit den Paketen zu tun sondern mit der Datenbank wo gespeichert wird welche Pakete drinnen sind).
Aber ich hab die Paketverwaltung doch eh 2-geteilt. Es gibt einmal in jedem Paket die Datei "getopt" - die sieht zb. so hier aus:
Code:
#!/bin/bash
## Package description
pkg_frmtver=2 # packet desc version
pkg_contver="5.2.1" # content version
pkg_contmarch="i686" # target of content
pkg_iname="corutils_1" # interface name
pkg_subname="coreutils" # textual packet name
pkg_desc="contains all coreutils binaries"
## iname dependencies
pkg_idep[0]=1
pkg_idep[1]="glibc_1"
## Files in packet
pkg_files[0]=3 # how many files
pkg_files[1]="/bin/["
pkg_files[2]="/bin/basename"
pkg_files[3]="/bin/cat"
## Links in packet (NOTE: Version 2 specific)
# type 1 -> link to file
# type 2 -> link to dir
# type 3 -> link to link
# type 4 -> link to plain text
pkg_links=4
pkg_links_name[1]="/lnk1"
pkg_links_type[1]=1
pkg_links_target[1]=2 # -> to /bin/basename
pkg_links_name[2]="/lnk2"
pkg_links_type[2]=2
pkg_links_target[2]=1 # -> to /bin
pkg_links_name[3]="/lnk3"
pkg_links_type[3]=3
pkg_links_target[3]=1 # -> to /lnk1
pkg_links_name[4]="/lnk4"
pkg_links_type[4]=4
pkg_links_target[4]="abc" # -> to abc
## Dirs in packet
pkg_dirs[0]=1
pkg_dirs[1]="/bin"Die Datei ist nur zu Dokuzwecken, da implementier ich alles was die Paketversion kann und dokumentiere es etwas (so, dass ich mich da später wieder durchfinde).
"pkg_frmtver=2" - das ist am wichtigsten. Das gibt an, welche Version die getopt ist, und demnach was da drinnen steht und was eben nicht.
Neben den zu installierenden Dateien und der getopt ist erstmal nix weiter im Paket. Der 2. Teil ist der Installer, den man schreiben kann wie und worin man will. Der Pakete Installer muss nur die getopt realisieren bzw. umsetzen, mehr nicht.
Die Version 2 enthält wie du siehst schon eine ganze Menge an Möglichkeiten (Erzeugung von Links in allen Spielarten, Abhängigkeiten, ein paar Paketbeschreibungen und ein Interface, nämlich pkg_iname).
Die Version 2 schreibt vor was in der getopt zu kommen hat und wie das interpretiert wird. Ein Pakete Installer prüft also vor der Installation welche Version das Paket hat und installiert das dementsprechend.
Ich kann jetzt problemlos alle neuen Pakete in der imaginären Version 3 verfassen, der Installer muss trotzdem mit der Version 2 zurrecht kommen. Die Angabe von Files/Links ist fest vorgegeben (pkg_{file,link,dir}s=xyz), also man bräuchte das Skript nichtmal durch die bash jagen, sondern könnte gleich den kompletten Code manuell auswerten.
Das durch die bash jagen bietet sich hier aber an, da wir die Werte danach einfach über die Umgebungsvariablen auslesen können
Für die nächsten Formatversionen hab ich ungefähr sowas hier geplant:
- deutlich erweiterte Interfaces (dient zum Aufsplitten von Software in mehrere optionale Teilpakete)
- Interface Versionen (gibts momentan noch garnet)
- stark aufgebohrte Dependencies
- Build Informationen (Compilerflags und sowas)
Dadurch werden die Version 2 Pakete ja aber nicht überflüssig
- die können dann trotzdem noch vom (idealerweise selben) Paketeinstaller installiert werden. Wie dann der Paketeinstaller realisiert ist wird ja überhauptnicht vorgegeben, das kann bash sein, perl, awk, ein C Programm, ein Fortran Programm
, Java, weis der Geier eben was - alles ist möglich. Die Progs müssen nur (sofern sie getopt nicht durch die bash jagen und die env Variablen auslesen) die Variablenzuweisungen genauso wie die bash 2.x interpretieren. Übrigens bieten die Pakete auch die Möglichkeit den Installationspfad relativ zu / zu verändern (daher auch so ein Hickhack mit den Links). Also ich kann zb. die fertigen Coreutils hininstallieren wo ich will (nach /, nach /usr oder was weis ich).
Kein einziges Paket hat /usr oder sowas fest verdrahtet - bei den util-linux (wo es vom Install-Skript fest verdrahtet ist) hab ich das Paket zb. in 2 Teile gesplittet, das eine Paket installiert mein mkinitrd (das Skript baut das komplette ihnux neu) nach / und das andere nach /usr.
Versuch das mal mit einem rpm
€: Die größte Änderung die noch ansteht (wirkt sich aber auch nicht auf alte Pakete aus) ist die Trennung von Interface und Paket. Dadurch lassen sich sachen wie zb. die busybox besser integrieren, und es gibt nicht tausende Pakete die doch nur ein Programm implementieren (und Abhängigkeiten können besser erkannt werden wodurch sich mehr unnützes Zeug ausmißten lässt).
Also die glibc stellt dann zb. mehrere Interfaces zur Verfügung, wovon eines das Vorhandensein von /lib/libc-* und /lib/ld-* beschreibt. Die Core-utils wären dann zb. nur von diesem Interface abhängig, die glibc enthält ja aber auch noch tausende andere libs. Das Interfaces könnte man sogar noch für den Pakete-Installer verständlich beschreiben (das hat nun rein garnix mit den Paketen selbst zu tun), so könnte der Pakete-Installer auch nachprüfen ob die Pakete auch tatsächlich die angegebenen Interfaces implementieren.
Später will ich noch implementieren, dass der Pakete-Installer die getopts der einzelnen Pakete entsprechend dem Paketnamen(+Version+alleswasdasPaketeinzigartigmacht) in ein bestimmtes Verzeichniss in der Distri installiert, damit man das später auch wieder rauswerfen kann (das hat jetzt nix mit den Paketen zu tun sondern mit der Datenbank wo gespeichert wird welche Pakete drinnen sind).
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Nun, du mußt das Zeugs pflegen.
D
derkostka
Guest
Code:
[root@sebastian stick]# lilo -C /mnt/stick/
Warning: RAID1 install implied by omitted 'boot='
Fatal: Can't put the boot sector on logical partition 0x0308Diesen Fehler bekomme ich, wenn ich lilo auf dem Stick mit FAT System einrichten möchte.
Auch wenn ich als Pfad /mnt/stick/etc angeben (dort liegt die lilo.conf), bekomme ich diese Meldung.
Wo liegt der Fehler ?
D
derkostka
Guest
boot=/dev/sda
map=/mnt/stick/boot/map
prompt
timeout=150
image=/mnt/stick/boot/vmlinuz
append="root=/dev/ram0"
initrd=/mnt/stick/boot/rootfs.gz
root=/dev/ram0
label=ihnux_rc1
So steht`s drin, meiner Meinung nach richtig. Hier die Verzeichnissstruktur:
/etc/lilo.conf
/boot/vmlinuz
/boot/rootfs.gz
das wars...
map=/mnt/stick/boot/map
prompt
timeout=150
image=/mnt/stick/boot/vmlinuz
append="root=/dev/ram0"
initrd=/mnt/stick/boot/rootfs.gz
root=/dev/ram0
label=ihnux_rc1
So steht`s drin, meiner Meinung nach richtig. Hier die Verzeichnissstruktur:
/etc/lilo.conf
/boot/vmlinuz
/boot/rootfs.gz
das wars...
hmmm, das ist ja komisch. Vor allem ergibt die Fehlermeldung wenig Sinn.
Pack mal das large-memory rein und gib mal noch "compact" an.
Wie hast du den USB Stick denn eingebunden (schätze mal mit usb-storage) und welchen Kernel nimmst du?
Ach ja, ich glaub ich weis was los ist. Mach mal cfdisk /dev/sda, der wird dir sagen, dass da keine gülige Partitionstabelle liegt. Das ist aber nicht weiter schlimm.
Kopier alle Daten vom Stick irgendwo auf die HDD. Dann gibst du cfdisk /dev/sda ein und erstellst eine neue Partitionstabelle, da drinnen machst du eine große FAT Partition (typ ändern nicht vergessen).
Das jetzt ist wichtig, du musst den Stick abmachen und wieder dranstecken (sonst würde er die neue Partitionstabelle nicht erkennen).
Dann machst du mit mkfs.vfat (oder mkfs.msdos) /dev/sda1 dort eine FAT Partition, mountest die und kopierst wieder alle Daten drauf. Dann installierst du lilo mit deiner Config.
Hintergrund: Es gibt 2 möglichkeiten einen USB Stick zu formatieren. Einmal als übergroße Diskette, das heist, dass nur eine einzige Partition drauf liegt ohne Partitiontabelle oder sonstwas. Und als HDD - es liegt eine Partitionstabelle auf dem Stick und es gibt Partitionen (normalerweise auch nur eine).
Die letzte Methode ist für den Fall besser, weil sich lilo dann nicht in die Partition installieren muss sondern direkt nach der Partitionstabelle. Windows liest auch beide Varianten.
Pack mal das large-memory rein und gib mal noch "compact" an.
Wie hast du den USB Stick denn eingebunden (schätze mal mit usb-storage
) und welchen Kernel nimmst du? Ach ja, ich glaub ich weis was los ist. Mach mal cfdisk /dev/sda, der wird dir sagen, dass da keine gülige Partitionstabelle liegt. Das ist aber nicht weiter schlimm.
Kopier alle Daten vom Stick irgendwo auf die HDD. Dann gibst du cfdisk /dev/sda ein und erstellst eine neue Partitionstabelle, da drinnen machst du eine große FAT Partition (typ ändern nicht vergessen).
Das jetzt ist wichtig, du musst den Stick abmachen und wieder dranstecken (sonst würde er die neue Partitionstabelle nicht erkennen).
Dann machst du mit mkfs.vfat (oder mkfs.msdos) /dev/sda1 dort eine FAT Partition, mountest die und kopierst wieder alle Daten drauf. Dann installierst du lilo mit deiner Config.
Hintergrund: Es gibt 2 möglichkeiten einen USB Stick zu formatieren. Einmal als übergroße Diskette, das heist, dass nur eine einzige Partition drauf liegt ohne Partitiontabelle oder sonstwas. Und als HDD - es liegt eine Partitionstabelle auf dem Stick und es gibt Partitionen (normalerweise auch nur eine).
Die letzte Methode ist für den Fall besser, weil sich lilo dann nicht in die Partition installieren muss sondern direkt nach der Partitionstabelle. Windows liest auch beide Varianten.
D
derkostka
Guest
Ajo, daran liegt es wohl.
Ist das FAT16 Typ 06 oder Windows FAT ?
Komisch nun habe ich nur noch 123,5mb nicht mehr 128 !
Aber wenn es dann geht wäre mir das egal.
Ist das FAT16 Typ 06 oder Windows FAT ?
Komisch nun habe ich nur noch 123,5mb nicht mehr 128 !
Aber wenn es dann geht wäre mir das egal.
Nimm 06, notfalls kannst du das später auch noch ändern.
Die 123.5mb kommen durch andere Umrechnungen - du hast 128MB, aber nur 122MiB (128*1000^2/1024^2=122MiB), ich denke mal da wird eines der Progs von zb. Byte in kB mit 1024 rechnen und dann weiter mit 1000. Die Partitionstabelle schluckt auch nochmal ein bisschen was an Speicher, je nach physikalischem Format vom USB Stick bis zu 504kb.
Die 123.5mb kommen durch andere Umrechnungen - du hast 128MB, aber nur 122MiB (128*1000^2/1024^2=122MiB), ich denke mal da wird eines der Progs von zb. Byte in kB mit 1024 rechnen und dann weiter mit 1000. Die Partitionstabelle schluckt auch nochmal ein bisschen was an Speicher, je nach physikalischem Format vom USB Stick bis zu 504kb.
Hab gestern mal die Pakete-Spezifikation überarbeitet. Die alten Pakete sind zwar nach wie vor kompatibel, aber die neuen sehen viel größere und leistungsfähigere Strukturen vor.
Das ganze ist so gestalltet, dass es einerseits dem Anspruch nach geringst möglicher Größe gerecht werden soll, und andererseits auch genug Leistung bietet um daraus später vielleicht eine größere Distri zu basteln.
Ich denk ich werd heut hauptsächlich Pakete umstellen.
Das ganze ist so gestalltet, dass es einerseits dem Anspruch nach geringst möglicher Größe gerecht werden soll, und andererseits auch genug Leistung bietet um daraus später vielleicht eine größere Distri zu basteln.
Ich denk ich werd heut hauptsächlich Pakete umstellen.
So, die Module-Geschichte hab ich jetzt verbessert (standart Verzeichnis, modules.dep usw. - jetzt kommen erstmal keine Fehlermeldungen mehr ) und das VESA Framebuffer Device ist drinnen.
rootfs.gz ist jetzt 4.5MiB
) und das VESA Framebuffer Device ist drinnen. rootfs.gz ist jetzt 4.5MiB
Das_Wishnu
Admiral Special
Und, wie schauts bei Deinem Zögling denn mittlerweile aus?
Ähnliche Themen
