Hallo,
leider wurde letzte Woche das ext3-Filesystem der Root-Partition meines Debians 3.0 zerstört. Die Verzeichnisse /home und /usr habe ich auf extra Partitionen und auf dem Rechner außerdem noch eine SuSE, so dass es nicht ganz so schlimm ist (konnte die Home-Partition einfach umhängen). Es fing eigentlich damit an, dass seit dem Umstieg auf den Kernel 2.4 die Platten nicht mehr im DMA-Mode liefen und ich diesen mit hdparm beim Booten extra setzen mußte. Soweit kein Problem, bis nach dem Umstieg auf den Kernel 2.4.21 sich an dieser Stelle merkwürdige Fehlermeldungen häuften (seek_error ... ). Dann wurde die Partition nach einem eigentlich normalen Herunterfahren beim nächsten Booten öfters einmal gecheckt, bis dann der große Crash kam. Die Partition konnte nicht mehr gemountet werden, der Superblock war zerstört. Mit e2fsck konnte dieser zwar wieder aus der Sicherheitskopie hergestellt werden, jedoch fand das Programm nur noch ein kaputtes Filesystem vor (einer der vielen Fehlermeldungen: Inodes that were part of a corrupted orphan linked list found). Dann hat es mir den kompletten Partitionsinhalt in lost+found hineingeworfen. Einige Verzeichnisse liesen sich nach ihrem Inhalt wiedererkennen (die oberste Ebene hatte nur Bezeichnungen mit # und Zahlen). Diese habe ich dann wieder entsprechend umbenannt, jedoch fehlte z.B. /sbin komplett und /dev war recht leer. Das Booten hat natürlich nicht mehr funktioniert. Nun wolllte ich anfangs mich wenigstens mit chroot aus einem anderen Linux (z.B. die SuSE oder Knoppix von CD) auf die Partition setzen und dort noch lilo ausführen (weil hier eigentlich mein Bootmanager saß). Dies funktioniert aber nicht, chroot findet keine funktionstüchtige Shell. (mit der statisch gelinkten Shell, wie in der c't mit der Knoppicillin-CD beschrieben geht es). Nun frage ich mich warum? Das /bin-Verzeichnis mit der bash ist vorhanden und sieht eigentlich gut aus. Was gehört zu einer funktionstüchtigen Shell noch dazu? Was müßte man also z.B. auf eine leere Partition kopieren, damit chroot dort eine funktionstüchtige Shell vorfindet oder geht das gar nicht so einfach mit kopieren?
Thomas P.
Hi Thomas,
On Thu, Jul 17, 2003 at 22:49:51 +0200, Thomas Presberger wrote:
Es fing eigentlich damit an, dass seit dem Umstieg auf den Kernel 2.4 die Platten nicht mehr im DMA-Mode liefen und ich diesen mit hdparm beim Booten extra setzen mußte. Soweit kein Problem, bis nach dem Umstieg auf den Kernel 2.4.21 sich an dieser Stelle merkwürdige Fehlermeldungen häuften (seek_error ... ). Dann wurde die Partition nach einem eigentlich
Es geistern in de.comp.os.unix.linux.misc ein paar Postings zum Thema 2.4.21 und UDMA herum. Anscheinend ist da wirklich was broken...
Dies funktioniert aber nicht, chroot findet keine funktionstüchtige Shell. (mit der statisch gelinkten Shell, wie in der c't mit der Knoppicillin-CD beschrieben geht es). Nun frage ich mich warum? Das /bin-Verzeichnis mit der bash ist vorhanden und sieht eigentlich gut aus. Was gehört zu einer funktionstüchtigen Shell noch dazu? Was müßte man also z.B.
Eigentlich ging es Dir doch nur um den Bootloader. Fuer lilo brauchst Du minimal:
/boot/{boot.b,chain.b,os2_d.b} /dev/{hda,null} /etc/lilo.conf /lib/{ld-linux.so.2,libc.so.6} /sbin/lilo /tmp
Dann "chroot /mountpoint /sbin/lilo" aufrufen. Falls Du das von Knoppix aus machst, sollte die Partition nicht mit der Option "nodev" gemountet sein.
bye, Chris
Hallo,
Christian Perle wrote:
Eigentlich ging es Dir doch nur um den Bootloader. Fuer lilo brauchst Du minimal:
/boot/{boot.b,chain.b,os2_d.b}
das ist ja noch vorhanden ...
/dev/{hda,null}
aber hier geht es schon los - die gibt es nicht mehr.
/etc/lilo.conf
die ist da. Das /etc-Verzeichnis hatte ich auch gesichert.
/lib/{ld-linux.so.2,libc.so.6}
In einem Backup von /lib ist ld-linux.so.2 ein link auf ld-2.2.5.so und libc.so.6 ein link auf libc-2.2.5.so. Die Links gibt es gar nicht mehr und ansonsten nur eine ld-2.3.1.so und eine libc-2.3.1.so. Aber hinter der libc-2.3.1.so steckt eine völlig andere Datei - in diesem Fall die nsswitch.conf aus /etc und ld-2.3.1.so ist ein link auf ../init.d/checkfs.sh. Also hier scheint noch einiges mehr schiefgegangen zu sein, als ich dachte. So kann ich mein seit 1999 gepflegtes Debian wohl vergessen. Und das /usr-Verzeichnis auf der anderen Partition nützt mir nun wahrscheinlich auch nichts mehr, oder?
Thomas P.
Am 20. Juli 2003 schrieb Thomas Presberger:
Christian Perle wrote:
/dev/{hda,null}
aber hier geht es schon los - die gibt es nicht mehr.
Du kannst die fehlenden Devices von einer anderen Linuxinstallation, dem baseX_X.tgz von Debian oder einer Knoppix-CD kopieren.
/lib/{ld-linux.so.2,libc.so.6}
In einem Backup von /lib ist ld-linux.so.2 ein link auf ld-2.2.5.so und libc.so.6 ein link auf libc-2.2.5.so. Die Links gibt es gar nicht mehr und ansonsten nur eine ld-2.3.1.so und eine libc-2.3.1.so. Aber hinter der libc-2.3.1.so steckt eine völlig andere Datei - in diesem Fall die nsswitch.conf aus /etc und ld-2.3.1.so ist ein link auf ../init.d/checkfs.sh. Also hier scheint noch einiges mehr schiefgegangen zu sein, als ich dachte. So kann ich mein seit 1999 gepflegtes Debian wohl vergessen.
Sorry, ich hab dein Ausgansposting nicht mehr. Hattest du ext[2,3]? Wenn ja, welche Version haben deine e2fsprogs, d.h. was sagt: e2fsck -V
Wenn du noch mit dpkg --get-selections deine Installationen festgehalten hast würde ich nach Rettung aller noch benötigeter Daten eine Neuinstallation und dann dpkg --set-selections machen. Wenn du allerdings ein gemischtes System oder Programme an der Paketverwaltung vorbei installiert hast, ist es damit nicht getan.
Wenn du Zugriff auf /var/cache/apt hast, kannst du die nachinstallierten Pakete retten.
Wenn du keine aktuelle Paketliste hast, stehen unter /var/lib/dpkg wertvolle Informationen, welche Pakete installiert sind. Evtl. kann man einer Knoppix diese unterjubeln und ein get-selections erstellen? (Noch nie probiert)
Und das /usr-Verzeichnis auf der anderen Partition nützt mir nun wahrscheinlich auch nichts mehr, oder?
Höchstens eigene Programme unter /usr/local retten.
Am besten wäre eine Neuinstallation auf einer anderen Partition und die alte noch eine Weile behalten, falls man doch noch was braucht.
Viel Erfolg.
Freundlich grüßend,
Erik
On 20.07.03 Erik Schanze (schanzi_@gmx.de) wrote:
Am 20. Juli 2003 schrieb Thomas Presberger:
Christian Perle wrote:
Moin,
/dev/{hda,null}
aber hier geht es schon los - die gibt es nicht mehr.
Du kannst die fehlenden Devices von einer anderen Linuxinstallation, dem baseX_X.tgz von Debian oder einer Knoppix-CD kopieren.
Oder die Manpage von MAKEDEV lesen. Als Hilfe hier Major- und Minor-Nummern.
drachi:[~] #ll /dev/hda /dev/null brw-rw---- 1 root disk 3, 0 Jul 5 2000 /dev/hda crw-rw-rw- 1 root root 1, 3 Aug 31 2002 /dev/null
In einem Backup von /lib ist ld-linux.so.2 ein link auf ld-2.2.5.so und libc.so.6 ein link auf libc-2.2.5.so. Die Links gibt es gar nicht mehr und ansonsten nur eine ld-2.3.1.so und eine libc-2.3.1.so. Aber hinter der libc-2.3.1.so steckt eine völlig andere Datei - in diesem Fall die nsswitch.conf aus /etc und ld-2.3.1.so ist ein link auf ../init.d/checkfs.sh.
Na Moment. Debian stable enthählt gar keine glibc-2.3.x. Die ist entweder aus Testing oder aus unstable.
Also hier scheint noch einiges mehr schiefgegangen zu sein, als ich dachte. So kann ich mein seit 1999 gepflegtes Debian wohl vergessen.
Kommt drauf an, ob Du noch was zusammenfindest. Solange Du aber regelmäßig Backups gemacht hast, ist wohl ein komplette Neuinstallation einfacher..
Wenn du noch mit dpkg --get-selections deine Installationen festgehalten hast würde ich nach Rettung aller noch benötigeter Daten eine Neuinstallation und dann dpkg --set-selections machen. Wenn du allerdings ein gemischtes System oder Programme an der Paketverwaltung vorbei installiert hast, ist es damit nicht getan.
IICR hatte er /var auf / und damit dürfte die mit tot sein.
Wenn du keine aktuelle Paketliste hast, stehen unter /var/lib/dpkg wertvolle Informationen, welche Pakete installiert sind. Evtl. kann man einer Knoppix diese unterjubeln und ein get-selections erstellen? (Noch nie probiert)
von stable auf unstable? Eher fraglich. Außerdem kann er auf seiner Installation Pakete dabei gehabt haben, die eine Knoppix nicht mitliefert.
Am besten wäre eine Neuinstallation auf einer anderen Partition und die alte noch eine Weile behalten, falls man doch noch was braucht.
/etc und /usr/local könnten noch Interesse sein...
H.
Am 21. Juli 2003 schrieb Hilmar Preusse:
On 20.07.03 Erik Schanze (schanzi_@gmx.de) wrote:
Am 20. Juli 2003 schrieb Thomas Presberger:
Christian Perle wrote:
/dev/{hda,null}
aber hier geht es schon los - die gibt es nicht mehr.
Du kannst die fehlenden Devices von einer anderen Linuxinstallation, dem baseX_X.tgz von Debian oder einer Knoppix-CD kopieren.
Oder die Manpage von MAKEDEV lesen. Als Hilfe hier Major- und Minor-Nummern.
drachi:[~] #ll /dev/hda /dev/null brw-rw---- 1 root disk 3, 0 Jul 5 2000 /dev/hda crw-rw-rw- 1 root root 1, 3 Aug 31 2002 /dev/null
Was nützt dem OP MAKEDEV, wenn er nicht einmal ein chroot machen kann?
In einem Backup von /lib ist ld-linux.so.2 ein link auf ld-2.2.5.so und libc.so.6 ein link auf libc-2.2.5.so. Die Links gibt es gar nicht mehr und ansonsten nur eine ld-2.3.1.so und eine libc-2.3.1.so. Aber hinter der libc-2.3.1.so steckt eine völlig andere Datei - in diesem Fall die nsswitch.conf aus /etc und ld-2.3.1.so ist ein link auf ../init.d/checkfs.sh.
Na Moment. Debian stable enthählt gar keine glibc-2.3.x. Die ist entweder aus Testing oder aus unstable.
Von stable hatte er nichts gesagt, oder?
Wenn du noch mit dpkg --get-selections deine Installationen festgehalten hast würde ich nach Rettung aller noch benötigeter Daten eine Neuinstallation und dann dpkg --set-selections machen. Wenn du allerdings ein gemischtes System oder Programme an der Paketverwaltung vorbei installiert hast, ist es damit nicht getan.
IICR hatte er /var auf / und damit dürfte die mit tot sein.
AFAIK kann er auf Teile des / zugreifen. Vielleicht ist auch /var dabei.
Wenn du keine aktuelle Paketliste hast, stehen unter /var/lib/dpkg wertvolle Informationen, welche Pakete installiert sind. Evtl. kann man einer Knoppix diese unterjubeln und ein get-selections erstellen? (Noch nie probiert)
von stable auf unstable? Eher fraglich. Außerdem kann er auf seiner Installation Pakete dabei gehabt haben, die eine Knoppix nicht mitliefert.
Ist in dem Fall egal, man jubelt dem Knoppix die Paketinfos der alten Installation unter. Da kennt Knoppix seinen Status nicht mehr. Das ist auch nur ein "bad hack", um aus dem alten /var noch eine get-selections zu bekommen. Ich weiß auch nicht, ob das funktioniert.
Freundlich grüßend,
Erik
On 21.07.03 Erik Schanze (schanzi_@gmx.de) wrote:
Am 21. Juli 2003 schrieb Hilmar Preusse:
Moin,
Oder die Manpage von MAKEDEV lesen. Als Hilfe hier Major- und Minor-Nummern.
drachi:[~] #ll /dev/hda /dev/null brw-rw---- 1 root disk 3, 0 Jul 5 2000 /dev/hda crw-rw-rw- 1 root root 1, 3 Aug 31 2002 /dev/null
Was nützt dem OP MAKEDEV, wenn er nicht einmal ein chroot machen kann?
Mit einem Diskettenlinux/Knoppix/Install-CD booten und von da aus arbeiten.
Na Moment. Debian stable enthählt gar keine glibc-2.3.x. Die ist entweder aus Testing oder aus unstable.
Von stable hatte er nichts gesagt, oder?
<quote> leider wurde letzte Woche das ext3-Filesystem der Root-Partition meines Debians 3.0 zerstört. </quote>
AFAIK kann er auf Teile des / zugreifen. Vielleicht ist auch /var dabei.
Gut, kommt drauf an.
Ist in dem Fall egal, man jubelt dem Knoppix die Paketinfos der alten Installation unter. Da kennt Knoppix seinen Status nicht mehr. Das ist auch nur ein "bad hack", um aus dem alten /var noch eine get-selections zu bekommen. Ich weiß auch nicht, ob das funktioniert.
Dann reicht es aber auch, wenn man die /var/lib/dpkg/status kopiert und dort grep/awk/perl rüberjagt.
H.
Erik Schanze wrote:
Am 21. Juli 2003 schrieb Hilmar Preusse:
On 20.07.03 Erik Schanze (schanzi_@gmx.de) wrote:
Am 20. Juli 2003 schrieb Thomas Presberger:
Christian Perle wrote:
/dev/{hda,null}
aber hier geht es schon los - die gibt es nicht mehr.
Du kannst die fehlenden Devices von einer anderen Linuxinstallation, dem baseX_X.tgz von Debian oder einer Knoppix-CD kopieren.
Oder die Manpage von MAKEDEV lesen. Als Hilfe hier Major- und Minor-Nummern.
drachi:[~] #ll /dev/hda /dev/null brw-rw---- 1 root disk 3, 0 Jul 5 2000 /dev/hda crw-rw-rw- 1 root root 1, 3 Aug 31 2002 /dev/null
Was nützt dem OP MAKEDEV, wenn er nicht einmal ein chroot machen kann?
Das dachte ich eigentlich auch.
In einem Backup von /lib ist ld-linux.so.2 ein link auf ld-2.2.5.so und libc.so.6 ein link auf libc-2.2.5.so. Die Links gibt es gar nicht mehr und ansonsten nur eine ld-2.3.1.so und eine libc-2.3.1.so. Aber hinter der libc-2.3.1.so steckt eine völlig andere Datei - in diesem Fall die nsswitch.conf aus /etc und ld-2.3.1.so ist ein link auf ../init.d/checkfs.sh.
Na Moment. Debian stable enthählt gar keine glibc-2.3.x. Die ist entweder aus Testing oder aus unstable.
Von stable hatte er nichts gesagt, oder?
Ja, ich hatte zwar 3.0 geschrieben, aber natürlich brauchte ich inzwischen das eine oder andere aktuelle Programm aus unstable.
Wenn du noch mit dpkg --get-selections deine Installationen festgehalten hast würde ich nach Rettung aller noch benötigeter Daten eine Neuinstallation und dann dpkg --set-selections machen. Wenn du allerdings ein gemischtes System oder Programme an der Paketverwaltung vorbei installiert hast, ist es damit nicht getan.
IICR hatte er /var auf / und damit dürfte die mit tot sein.
AFAIK kann er auf Teile des / zugreifen. Vielleicht ist auch /var dabei.
Also /var ist noch da und sieht eigentlich ganz gut aus, obwohl ich dies auch von /lib dachte und dann stehen dort hinter Dateinamen völlig andere Sachen. Ich weiß nicht, ob man hier überhaupt noch auf etwas vertrauen kann.
Wenn du keine aktuelle Paketliste hast, stehen unter /var/lib/dpkg wertvolle Informationen, welche Pakete installiert sind. Evtl. kann man einer Knoppix diese unterjubeln und ein get-selections erstellen? (Noch nie probiert)
von stable auf unstable? Eher fraglich. Außerdem kann er auf seiner Installation Pakete dabei gehabt haben, die eine Knoppix nicht mitliefert.
Ist in dem Fall egal, man jubelt dem Knoppix die Paketinfos der alten Installation unter. Da kennt Knoppix seinen Status nicht mehr. Das ist auch nur ein "bad hack", um aus dem alten /var noch eine get-selections zu bekommen. Ich weiß auch nicht, ob das funktioniert.
Ich habe hier die Koppix-CD's aus der c't und aus LinuxUser. Die kann man wohl beide auch installieren. Wären die geeignet?
Thomas P.
On 21.07.03 Thomas Presberger (thomas@presberger.de) wrote:
Erik Schanze wrote:
Moin,
Ja, ich hatte zwar 3.0 geschrieben, aber natürlich brauchte ich inzwischen das eine oder andere aktuelle Programm aus unstable.
Ja, aber das Zeug kann man immer noch auch den Sourcen bauen und braucht sich nicht die neueste glibc auf die Platte bügeln.
Also /var ist noch da und sieht eigentlich ganz gut aus, obwohl ich dies auch von /lib dachte und dann stehen dort hinter Dateinamen völlig andere Sachen. Ich weiß nicht, ob man hier überhaupt noch auf etwas vertrauen kann.
Dann schau Dir mal Teil der Sachen, die zur Paketverwaltung gehören an, ob die noch brauchbar sind. Ich würde auf jeden Fall neu aufsetzen und mir bloß /var/lib/dpkg/status besorgen, damit ich weiß, was installiert war.
Ist in dem Fall egal, man jubelt dem Knoppix die Paketinfos der alten Installation unter. Da kennt Knoppix seinen Status nicht mehr. Das ist auch nur ein "bad hack", um aus dem alten /var noch eine get-selections zu bekommen. Ich weiß auch nicht, ob das funktioniert.
Ich habe hier die Koppix-CD's aus der c't und aus LinuxUser. Die kann man wohl beide auch installieren. Wären die geeignet?
Wie g'saggt: Im Ernstfall reicht auch grep oder perl....
H.
Am 21. Juli 2003 schrieb Thomas Presberger:
Erik Schanze wrote:
Also /var ist noch da und sieht eigentlich ganz gut aus, obwohl ich dies auch von /lib dachte und dann stehen dort hinter Dateinamen völlig andere Sachen. Ich weiß nicht, ob man hier überhaupt noch auf etwas vertrauen kann.
Dann wärst einen Versuch wert.
Ist in dem Fall egal, man jubelt dem Knoppix die Paketinfos der alten Installation unter. Da kennt Knoppix seinen Status nicht mehr. Das ist auch nur ein "bad hack", um aus dem alten /var noch eine get-selections zu bekommen. Ich weiß auch nicht, ob das funktioniert.
Ich habe hier die Koppix-CD's aus der c't und aus LinuxUser. Die kann man wohl beide auch installieren. Wären die geeignet?
Ich hab's gerade getestet. 1. Knoppix booten 2. Partition, die /var enthält readonly nach /mnt mounten 3. Link /var/lib/dpkg auf /mnt/var/lib/dpkg umsetzen 4. Diskette o. a. schreibbaren Datenträger mounten 5. dpkg --get-selections >/floppy/selections.txt
Viel Erfolg.
@Hilmar: Und wie sieht die Lösung mit "grep/awk/perl" aus?
Freundlich grüßend,
Erik
On 22.07.03 Erik Schanze (schanzi_@gmx.de) wrote:
@Hilmar: Und wie sieht die Lösung mit "grep/awk/perl" aus?
grep -1 "Status: install" /var/lib/dpkg/status|grep Package|cut -b 10-|sort
just my 2¢
H.
On 22.07.03 Erik Schanze (schanzi_@gmx.de) wrote:
@Hilmar: Und wie sieht die Lösung mit "grep/awk/perl" aus?
grep -1 "Status: install" /var/lib/dpkg/status|grep Package|cut -b 10-|sort
hab noch 2 vergessen:
grep -1 "Status: deinstall ok conf" /var/lib/dpkg/status| etc... und grep -1 "Status: hold" /var/lib/dpkg/status| etc...
Der Vorteil noch nicht-libdb-basierten Datenbanken....
just my 2¢
H.
Am 2003-07-21 12:44 +0200 schrieb Hilmar Preusse:
/dev/{hda,null}
aber hier geht es schon los - die gibt es nicht mehr.
Du kannst die fehlenden Devices von einer anderen Linuxinstallation, dem baseX_X.tgz von Debian oder einer Knoppix-CD kopieren.
Oder die Manpage von MAKEDEV lesen. Als Hilfe hier Major- und Minor-Nummern.
Ich persönlich bin ja Fan von devfs, damit hat man diese Sorgen überhaupt nicht. Funktioniert mittlerweile auch einwandfrei.
Ciao, Pitti
On 21.07.03 Martin Pitt (martin@piware.de) wrote:
Am 2003-07-21 12:44 +0200 schrieb Hilmar Preusse:
Oder die Manpage von MAKEDEV lesen. Als Hilfe hier Major- und Minor-Nummern.
Ich persönlich bin ja Fan von devfs, damit hat man diese Sorgen überhaupt nicht. Funktioniert mittlerweile auch einwandfrei.
Bis die Root-Partition stirbt....
H.
Hallo Hilmar!
Am 2003-07-21 18:47 +0200 schrieb Hilmar Preusse:
Ich persönlich bin ja Fan von devfs, damit hat man diese Sorgen überhaupt nicht. Funktioniert mittlerweile auch einwandfrei.
Bis die Root-Partition stirbt....
Gerade da ist doch devfs prima, da interessiert doch die Konsistenz der root-Partition überhaupt nicht?
Pitti
On 21.07.03 Martin Pitt (martin@piware.de) wrote:
Am 2003-07-21 18:47 +0200 schrieb Hilmar Preusse:
Moin,
Bis die Root-Partition stirbt....
Gerade da ist doch devfs prima, da interessiert doch die Konsistenz der root-Partition überhaupt nicht?
Setzt nicht devfs auch eine funktionierende Infrastruktur voraus (also glibc funktioniert)? Das scheint ja bei ihm der Fall zu sein und damit würde Dir auch ein devfs nicht mehr helfen.
H.
Hallo Hilmar!
Am 2003-07-22 9:58 +0200 schrieb Hilmar Preusse:
On 21.07.03 Martin Pitt (martin@piware.de) wrote:
Am 2003-07-21 18:47 +0200 schrieb Hilmar Preusse:
Moin,
Bis die Root-Partition stirbt....
Gerade da ist doch devfs prima, da interessiert doch die Konsistenz der root-Partition überhaupt nicht?
Setzt nicht devfs auch eine funktionierende Infrastruktur voraus
Die Verwaltung von devfs wird ausschließlich vom Kernel übernommen, es verhält sich also wie /proc. Compiliert man den Kernel so, dass er devfs automatisch mountet, muss noch nicht mal /bin/mount funktionieren, man ist von der Root-Partition also völlig unabhängig.
Ciao, Pitti
On 22.07.03 Martin Pitt (martin@piware.de) wrote:
Moin,
Die Verwaltung von devfs wird ausschließlich vom Kernel übernommen, es verhält sich also wie /proc. Compiliert man den Kernel so, dass er devfs automatisch mountet, muss noch nicht mal /bin/mount funktionieren, man ist von der Root-Partition also völlig unabhängig.
OK, verstehe. Der devfsd ist also scheinbar fürs grundlegende Funktionieren nicht zuständig...
Description: Daemon for the device filesystem This daemon sets up the /dev filesystem for use. It creates required symbolic links in /dev and also creates (if so configured, as is the default) symbolic links to the "old" names for devices.
H.
Hallo Hilmar!
Am 2003-07-22 17:22 +0200 schrieb Hilmar Preusse:
On 22.07.03 Martin Pitt (martin@piware.de) wrote:
Moin,
Die Verwaltung von devfs wird ausschließlich vom Kernel übernommen, es verhält sich also wie /proc. Compiliert man den Kernel so, dass er devfs automatisch mountet, muss noch nicht mal /bin/mount funktionieren, man ist von der Root-Partition also völlig unabhängig.
OK, verstehe. Der devfsd ist also scheinbar fürs grundlegende Funktionieren nicht zuständig...
Nein, der bringt dann mehr den Komfort. Auf meinem Server läuft gar kein devfsd und auch meine Workstation bootet funktionsfähig ohne den daemon. Nötig ist der daemon vor allem für das Setzen der Symlinks (z. B. braucht mplayer /dev/dsp0 anstatt des neueren /dev/sound/dsp0) und auch cdrecord kennt nur /dev/sg0 und nicht /dev/scsi/.../generic) und vor allem für das dynamische Laden von Modulen (wenn ich versuche, das Verzeichnis /dev/sound/ zu lesen, wird automatisch der Soundtreiber geladen). Da die zum Booten benötigten Treiber aber statisch im Kernel vorhanden sein sollten, sollte dies keine Probleme machen.
Schönen Abend noch!
Pitti
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Erik Schanze -
Hilmar Preusse -
Martin Pitt -
Thomas Presberger