Hallo,
das Problem im groben ist die Installation eines SuSE Linux OpenExchange auf einem Root-Server bei Puretec.
Das Puretecpaket hatte ein SuSE 8.1 drauf.
Da Puretec vorort nicht helfen kann oder will und SLOE keine Ferninstallation unterstützt, gab es auf Anraten vom SuSE-Support nur einen Weg: System lokal installieren und die Festplatteninhalte kopieren. Die lokalen Partitionen wurden in der selben Reihenfolge/Anzahl angelegt. Lediglich die Größe (da andere Festplatte) ist anders.
Soweit ist auch alles klar, die Daten sind angekommen.
Dabei wurde aber der dort vorhandene grub überschrieben und jetzt bootet er nicht mehr. Im rescue-System (via Netz gebootetes Debian) komm ich aber immer noch ran.
Jetzt hab ich schon versucht den Bootloader neu zu installieren, was scheinbar auch erfolg hatte, aber es geht danach trotzdem nicht.
-------------------------------------- rescue:~# mount -t ext3 /dev/hda3 /mnt rescue:~# mount -t ext3 /dev/hda1 /mnt/boot rescue:~# chroot /mnt rescue:~# grub GRUB version 0.92 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ]
grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 17 sectors are embedded . succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/sta ge2 /boot/grub/menu.lst"... succeeded Done.
grub> quit --------------------------------------
umount & reboot - aber es klappt nicht.
Da in der /var/log/boot.msg nichts reingeschrieben wird, gehe ich davon aus, daß er am Bootmanager nicht vorbeikommt.
Was kann ich jetzt noch tun?
Rico
On Fri, 11 Apr 2003 17:44:31 +0200 Rico Koerner rico.koerner@heico.net wrote:
Jetzt hab ich schon versucht den Bootloader neu zu installieren, was scheinbar auch erfolg hatte, aber es geht danach trotzdem nicht.
rescue:~# mount -t ext3 /dev/hda3 /mnt rescue:~# mount -t ext3 /dev/hda1 /mnt/boot rescue:~# chroot /mnt rescue:~# grub GRUB version 0.92 (640K lower / 3072K upper memory)
[...]
grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83
Kann es sein, dass Grub mit ext3 ein Problem hat? Wie kommt Grub nach dem chroot an das Devicefile /dev/hda ran? Braucht Grub vielleicht noch das /proc (obwohl er sich da eigentlich melden sollte)? Alternativ würde ich den Lilo installieren, da dir die zusätzlichen Grub-Features remote sowieso nichts nützen.
mfg, Fabian
Fabian Hänsel wrote:
On Fri, 11 Apr 2003 17:44:31 +0200 Rico Koerner rico.koerner@heico.net wrote:
Jetzt hab ich schon versucht den Bootloader neu zu installieren, was scheinbar auch erfolg hatte, aber es geht danach trotzdem nicht.
rescue:~# mount -t ext3 /dev/hda3 /mnt rescue:~# mount -t ext3 /dev/hda1 /mnt/boot rescue:~# chroot /mnt rescue:~# grub GRUB version 0.92 (640K lower / 3072K upper memory)
[...]
grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83
Kann es sein, dass Grub mit ext3 ein Problem hat? Wie kommt Grub nach dem chroot an das Devicefile /dev/hda ran? Braucht Grub vielleicht noch das /proc (obwohl er sich da eigentlich melden sollte)?
Da die Installation von Suse in beiden Fällen (lokal und 1&1) mit ext3 funktionieren, glaub ich weniger an ein Problem mir ext3. Kann ich grub explizid mitteilen, daß es ext3 ist? Da ext3 ja fast ext2 ist, könnte ich es auch als ext2 mounten. Da nur gelesen wird, sollte es in beiden Varianten ohne Probleme funktionieren. Lokal hatte ich vorher schon mal eine Installation mit reiserfs, das funktionierte auch.
/proc, das ist eine Idee. Aber das Problem hab ich doch dann bestimmt auch bei lilo. Kann ich proc einfach nochmal mounten? Oder remount?
/dev/hda* ist ja auch nach dem chroot vorhanden. Wozu brauch er /dev/hda?
Ein find nach stage1 zeigt (hd0,0). (hd0,0) bzw. (hd0) sind ja die weiteren Ziele für grub und das hat ja wenig mit /dev/hda zu tun.
Inzwischen hab ich den lokalen Rechner mal mit Knoppix gebootet und wollte in derselben chroot-Umgebung die grub-shell aufrufen, ohne am lauffähigen System etwas zu ändern. Bin dort allerdings schon früher gescheitert. Hier wird die Partition garnicht gefunden. :-( Die Fehlermeldung kann ich aber erst morgen posten.
Alternativ würde ich den Lilo installieren, da dir die zusätzlichen Grub-Features remote sowieso nichts nützen.
Daran hab ich als letzten Ausweg auch schon gedacht.
Mir ist allerdings noch etwas eingefallen. Wenn die Installationsroutine einen Athlon-Kernel ausgewählt hat, ist das ein mögliches Problem. Auf dem Zielsystem ist ein Celeron. Würde es in dem Falle schon Einträge in der boot.msg geben?
Schonmal Danke für die ersten Hinweise.
Rico
Rico Koerner rico.koerner@heico.net wrote:
Kann es sein, dass Grub mit ext3 ein Problem hat? Wie kommt Grub
Da ext3 ja fast ext2 ist, könnte ich es auch als ext2 mounten. Da nur gelesen wird, sollte es in beiden Varianten ohne Probleme funktionieren.
War nur ein Verdacht, ich selber verwende nen grafischen Lilo. Wenn ich mich recht entsinne, gab es für den Lilo mal Patches, um richtig mit ext3 arbeiten zu können.
/proc, das ist eine Idee. Aber das Problem hab ich doch dann bestimmt auch bei lilo. Kann ich proc einfach nochmal mounten? Oder remount?
Weiß ich nicht, aber der Loader für PPC (yaboot) braucht es zum Beispiel. Einfach nochmal mounten oder mount -o bind /proc /mnt/proc .
/dev/hda* ist ja auch nach dem chroot vorhanden. Wozu brauch er /dev/hda?
/dev/hda* ist weiter vorhanden, ein chrooteter (tolles Wort) grub kann ja dann nicht mehr drauf zugreifen, dazu müsste es ja /mnt/dev/hda* geben. mount -o bind /dev /mnt/dev sollte helfen.
Ein find nach stage1 zeigt (hd0,0). (hd0,0) bzw. (hd0) sind ja die weiteren Ziele für grub und das hat ja wenig mit /dev/hda zu tun.
Unter Unix wird alles als Datei abstrahiert, auch Festplatten. Und nur über eine solche kann der Grub mMn an den MBR der Platte rankommen. Evtl. irre ich mich hier. Vielleicht hat der auch eigene Zugriffsmethoden (würde auch erklären, warum er nicht mit meinem HPT-Pseudo-Raid zusammenarbeiten will, das als /dev/hde vollwertig vorhanden ist).
Mir ist allerdings noch etwas eingefallen. Wenn die Installationsroutine einen Athlon-Kernel ausgewählt hat, ist das ein mögliches Problem. Auf dem Zielsystem ist ein Celeron. Würde es in dem Falle schon Einträge in der boot.msg geben?
Ich tippe mal darauf, dass ein Athlon-Kernel auf nem Celeron gar nicht bootfähig ist (weshalb die Distributoren auch höchstens Pentium(eins)-optimierte Kernel verwenden, dessen Features Athlons oder K6 auch haben).
mfg, Fabian
Fabian 翽 wrote:
Rico Koerner rico.koerner@heico.net wrote:
War nur ein Verdacht, ich selber verwende nen grafischen Lilo. Wenn ich mich recht entsinne, gab es f?r den Lilo mal Patches, um richtig mit ext3 arbeiten zu k?nnen.
Patches? Das ist aber sicherlich schon etwas länger her. Na hoffentlich geht es dann mit dem vorhandenen lilo.
Wei? ich nicht, aber der Loader f?r PPC (yaboot) braucht es zum Beispiel. Einfach nochmal mounten oder mount -o bind /proc /mnt/proc .
Mal probieren.
/dev/hda* ist weiter vorhanden, ein chrooteter (tolles Wort) grub kann ja dann nicht mehr drauf zugreifen, dazu m?sste es ja /mnt/dev/hda* geben. mount -o bind /dev /mnt/dev sollte helfen.
Gibt es doch auch. Unter /mnt/dev sind doch alle Nodes vorhanden.
Ein find nach stage1 zeigt (hd0,0). (hd0,0) bzw. (hd0) sind ja die weiteren Ziele f?r grub und das hat ja wenig mit /dev/hda zu tun.
Unter Unix wird alles als Datei abstrahiert, auch Festplatten. Und nur ?ber eine solche kann der Grub mMn an den MBR der Platte rankommen.
Sicher? grub ist am Ende nicht *soviel* Unix.
Evtl. irre ich mich hier. Vielleicht hat der auch eigene Zugriffsmethoden (w?rde auch erkl?ren, warum er nicht mit meinem HPT-Pseudo-Raid zusammenarbeiten will, das als /dev/hde vollwertig vorhanden ist).
soweit ich das verstanden habe, greift Grub auf BIOS-Informationen zurück bzw. verwendet die device.map. Letztere enthält allerdings (zumindest hier) Verweise zu /dev/*. *ratlos*
Ich tippe mal darauf, dass ein Athlon-Kernel auf nem Celeron gar nicht bootf?hig ist (weshalb die Distributoren auch h?chstens
Mit sehr hoher Wahrscheinlichkeit.
Pentium(eins)-optimierte Kernel verwenden, dessen Features Athlons oder K6 auch haben).
Bin ich mir bei SuSE nicht mehr so sicher.
Bei einer normalen (?) ;-) Installation kann man einen Kernel auswählen und dort stehen auch optimierte Kernel zur Auswahl. Die Auswahl hatte ich ich nicht. Die SLOE-Installation läßt nicht mehr viele Möglichkeiten zum Eingreifen übrig. Es soll eben anwenderfreundlich (Anwender=DAU) sein und möglichst viele Dinge selbst erledigen.
Was hindert Yast jetzt noch daran, die CPU selbst zu erkennen und den besten Kernel dafür auszuwählen? Das ist ja eigentlich auch nicht schlecht.
Meine Kopieraktion ist ja auch nicht gerade der übliche Weg, aber aufgrund einer unflexiblen Installationsroutine leider der einzige. :-(
Gruß, Rico
Rico Koerner rico.koerner@heico.net wrote:
Fabian 翽 wrote:
Rico Koerner rico.koerner@heico.net wrote:
War nur ein Verdacht, ich selber verwende nen grafischen Lilo. Wenn ich mich recht entsinne, gab es f?r den Lilo mal Patches, um richtig mit ext3 arbeiten zu k?nnen.
Patches? Das ist aber sicherlich schon etwas länger her. Na hoffentlich geht es dann mit dem vorhandenen lilo.
Ja.
/dev/hda* ist weiter vorhanden, ein chrooteter (tolles Wort) grub kann ja dann nicht mehr drauf zugreifen, dazu m?sste es ja /mnt/dev/hda* geben. mount -o bind /dev /mnt/dev sollte helfen.
Gibt es doch auch. Unter /mnt/dev sind doch alle Nodes vorhanden.
Jetzt wo du es sagst :-) bei SuSE ist ja kein devfs dabei. Passen die Device-Files vom zu installierenden Kernel mit denen vom Rettungssystem zusammen(sollte grub eigentlich beanstanden, wenn nicht)? Ich würde mal ausprobieren, was passiert, wenn ich /mnt/dev mal kurz umbenenne, /dev/ nach /mnt/dev"binde" und dann den grub drauf loslasse.
mfg, Fabian
Hallo.
Wie sieht denn die grub.conf, bzw. menu.lst aus?
Gruß, Frank.
Frank Benkstein wrote:
Hallo.
Wie sieht denn die grub.conf, bzw. menu.lst aus?
Gruß, Frank.
Ich sag mal lapidar: ganz normal. Posten kann ich sie erst am Montag.
Verglichen hatte ich es mit mehreren Doku's.
Hier die Beispiele von der Suse-Webseite: menu.lst: ################### gfxmenu (hd0,4)/message color white/green black/light-gray default 0 timeout 8
title linux kernel (hd0,4)/vmlinuz root=/dev/hda7 vga=791 initrd (hd0,4)/initrd title failsafe kernel (hd0,4)/vmlinuz.shipped root=/dev/hda7 ide=nodma apm=off acpi=off vga=normal nosmp maxcpus=0 3 initrd (hd0,4)/initrd.shipped #############################
Die boot-Partition war entsprechend hd0,0. gfxmenu ..., color ... und vga=791 hab ich auch schon entfernt, es half nichts. initrd gab's glaub ich auch nicht.
grub.conf äquivalent: ######################### root (hd0,4) install /grub/stage1 d (hd0) /grub/stage2 0x8000 (hd0,4)/grub/menu.lst quit #########################
grub-install /dev/hda oder grub --batch --device-map=/boot/grub/device.map </etc/grub.conf
funktionierte allerdings nicht so richtig, mit wurden an der Stelle die grub-shell-befehle angezeigt. Deshalb der Weg zu Fuß.
Rico
Frank Benkstein wrote:
Hallo.
Wie sieht denn die grub.conf, bzw. menu.lst aus?
grub.conf: SLOE: -------------------------- root (hd0,0) install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0) /grub/stage2 0x8000 (hd0,0)/grub/menu.lst quit --------------------------
1&1 orig.: -------------------------- root (hd0,0) install --stage2=/boot/grub/stage2 /boot/grub/stage1 d (hd0) /boot/grub/stage2 0x8000 (hd0,0)/boot/grub/menu.lst quit --------------------------
Und damit unterscheiden sich beide Versionen auch von der auf der SuSE-Webseite gezeigten Beispielkonfig. Hab inzwischen die 1&1-Version von grub.conf ins System kopiert. Die Ergebnisse stehen unten.
menu.lst: SLOE: -------------------------- default 0 timeout 8
title linux kernel (hd0,0)/vmlinuz root=/dev/hda3 initrd (hd0,0)/initrd title floppy root (fd0) chainloader +1 title failsafe kernel (hd0,0)/vmlinuz.shipped root=/dev/hda3 ide=nodma apm=off acpi=off vga=normal nosmp disableapic maxcpus=0 3 initrd (hd0,0)/initrd.shipped --------------------------
1&1 orig.: -------------------------- default 0 timeout 5
title linux kernel (hd0,0)/vmlinuz root=/dev/hda3
title linux_suse kernel (hd0,0)/vmlinuz.shipped root=/dev/hda3 initrd (hd0,0)/initrd.shipped --------------------------
Abgesehen von der initrd gibt es hier ja keine relevanten Unterschiede.
Der Kernel der 1&1-Installation ist allerdings schon ein 2.4.20 im Gegensatz zu einem 2.4.19 vom SLOE.
Die Grub-Aufrufe: mit chroot: -------------------------- rescue:/ # grub-install /dev/hda Could not find device for /boot: Not found or not a block device. -------------------------- rescue:/ # /usr/sbin/grub --batch --device-map=/boot/grub/device.map </etc/grub.conf
GRUB version 0.92 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ]
grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83
grub> install --stage2=/boot/grub/stage2 /boot/grub/stage1 d (hd0) /boot/grub
40(grub> install --stage2=/boot/grub/stage2 /boot/grub/stage1 d (hd0) /boot/grub/)
grub> quit --------------------------
jetzt ohne chroot: -------------------------- rescue:/# /mnt/usr/sbin/grub-install /dev/hda /usr/sbin/grub: Not found.
rescue:/# /mnt/usr/sbin/grub-install --grub-shell=/mnt/usr/sbin/grub \ /dev/hda /usr/lib/grub/stage1: Not found. rescue:/# /mnt/usr/sbin/grub-install --grub-shell=/mnt/usr/sbin/grub \ --root-directory=/mnt/boot/grub /dev/hda /usr/lib/grub/stage1: Not found. rescue:/# /mnt/usr/sbin/grub-install --grub-shell=/mnt/usr/sbin/grub \ --root-directory=/mnt/boot/grub/ /dev/hda /usr/lib/grub/stage1: Not found. rescue:/# cd /mnt/boot/grub/ rescue:/mnt/boot/grub# /mnt/usr/sbin/grub-install \ --grub-shell=/mnt/usr/sbin/grub /dev/hda /usr/lib/grub/stage1: Not found. --------------------------
grub-install ist nicht zur Zusammenarbeit zu bewegen.
-------------------------- rescue:/# /mnt/usr/sbin/grub --device-map=/mnt/boot/grub/device.map
GRUB version 0.92 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ]
grub> find /mnt/boot/grub/stage1
Error 15: File not found
grub> find /boot/grub/stage1 (hd0,0)
grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 17 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded Done.
grub> quit --------------------------
Das erste 'find' hat mich etwas verwundert. Im rescue-system selbst gibt es aber kein grub.
Die dev's sind auch korrekt: rescue:/mnt/boot/grub# ls -al /dev/hda brw-rw---- 1 root disk 3, 0 Feb 12 2000 /dev/hda rescue:/mnt/boot/grub# ls -al /mnt/dev/hda brw-rw---- 1 root disk 3, 0 Oct 21 17:57 /mnt/dev/hda
proc hatte ich inzwischen auch im chroot gemountet, alles erfolglos.
Inzwischen war auch der Versuch mit lilo fehlgeschlagen. Morgen versuch ichs mal mit einem anderen Kernel, vielleicht ist hier des Rätsels Lösung.
Gruß, Rico
Rico Koerner wrote:
Frank Benkstein wrote:
Hallo.
Wie sieht denn die grub.conf, bzw. menu.lst aus?
Funktionsfähig war letztendlich die Fassung von 1&1/SuSE 8.1, wenn auch die Ursache am Kernel lag.
Die Grub-Aufrufe: mit chroot:
rescue:/ # grub-install /dev/hda Could not find device for /boot: Not found or not a block device.
Das Problem hier lag an der Art hda1 zu mounten:
falsch: mount ... /dev/hda3 /mnt; mount ... /dev/hda1 /mnt/boot; chroot /mnt Der Inhalt von /boot ist korrekt, aber hda1 nicht mit mount sichtbar.
besser: mount ... /dev/hda3 /mnt; chroot /mnt; mount /boot; Jetzt funktioniert auch grub-install
rescue:/ # /usr/sbin/grub --batch --device-map=/boot/grub/device.map </etc/grub.conf
GRUB version 0.92 (640K lower / 3072K upper memory)
Die Version war auf allen Systemen gleich.
... 40(grub> install --stage2=/boot/grub/stage2 /boot/grub/stage1 d (hd0) /boot/grub/)
Das Problem war auch beim funktionierenden System existend. Ursache unbekannt.
Die grub-shell selbst zeigte kein anderes Verhalten, war ja auch vorher ohne Fehler.
Inzwischen war auch der Versuch mit lilo fehlgeschlagen. Morgen versuch ichs mal mit einem anderen Kernel,
Genau das war's, ich hab das komplette /boot von 1&1 sowie /lib/modules/2.4.20 in die SLOE-Umgebung kopiert. grub-install /dev/hda im chroot umount & reboot
Jetzt geht's. :-))
Ciao, Rico
Hallo Leute,
ich möchte mir auf Basis einer Debian Distibution (woody) einen Linux Router mit T-DSL Zugang zusammen bauen. Die Installation der erforderlichen Pakete und konfiguration des dsl Zugangs lief soweit problemlos. Wenn ich nun versuche mich zu verbinden (pppd call dsl-provider) bekomme ich folgende Ausschrift (auch im syslog):
Using interface ppp0 Couldn't set pass-filter in kernel: Invalid argument Cannot determine ethernet address for proxy ARP local IP address 10.64.64.64 remote IP address 10.112.112.112 Starting link Serial connection established. Connect: ppp0 <--> /dev/pts/1 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x608ab2a0>] rcvd [LCP ConfReq id=0xf0 <mru 1492> <auth pap> <magic 0x5fb88fda>] sent [LCP ConfRej id=0xf0 <auth pap>] rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x608ab2a0>] rcvd [LCP ConfReq id=0xf1 <mru 1492> <magic 0x5fb88fda>] sent [LCP ConfAck id=0xf1 <mru 1492> <magic 0x5fb88fda>] sent [LCP EchoReq id=0x0 magic=0x608ab2a0] sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>] rcvd [LCP TermReq id=0xf2] LCP terminated by peer sent [LCP TermAck id=0xf2] Script /usr/sbin/pppoe -I eth1 finished (pid 247), status = 0x0 Modem hangup Connection terminated. Terminating on signal 2.
Wo kann ich jetzt anfangen nach einem Fehler zu suchen warum die Verbindung nicht aufgebaut wird? Fehlen mir eventuell einige Kernelmodule (Couldn't set pass-filter in kernel: Invalid argument) oder ist das auf fehlerhafte Konfigurationsdateien zurückzuführen? Die Konfiguration habe ich mit Hilfe einer Beschreibung von www.adsl4linux.de durchgeführt.
Grüsse Clemens
On Tue, Apr 15, 2003 at 06:07:22PM +0200, Clemens Altenburger wrote:
Hallo Leute,
Hi Clemens,
Kannst du bitte das naechste Mal einen neuen Thread anfangen? Sieht so nicht schoen aus ;)
ich möchte mir auf Basis einer Debian Distibution (woody) einen Linux Router mit T-DSL Zugang zusammen bauen. Die Installation der erforderlichen Pakete und konfiguration des dsl Zugangs lief soweit problemlos. Wenn ich nun versuche mich zu verbinden (pppd call dsl-provider) bekomme ich folgende Ausschrift (auch im syslog):
Using interface ppp0 Couldn't set pass-filter in kernel: Invalid argument Cannot determine ethernet address for proxy ARP local IP address 10.64.64.64 remote IP address 10.112.112.112 Starting link Serial connection established. Connect: ppp0 <--> /dev/pts/1 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x608ab2a0>] rcvd [LCP ConfReq id=0xf0 <mru 1492> <auth pap> <magic 0x5fb88fda>] sent [LCP ConfRej id=0xf0 <auth pap>] rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x608ab2a0>] rcvd [LCP ConfReq id=0xf1 <mru 1492> <magic 0x5fb88fda>] sent [LCP ConfAck id=0xf1 <mru 1492> <magic 0x5fb88fda>] sent [LCP EchoReq id=0x0 magic=0x608ab2a0] sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
Sieht soweit ok aus, das mit dem 'pass-filter kann IMHO ignoriert werden.
rcvd [LCP TermReq id=0xf2] LCP terminated by peer
Also hat die Gegenstelle die Verbindung unterbrochen...
Wo kann ich jetzt anfangen nach einem Fehler zu suchen warum die Verbindung nicht aufgebaut wird? Fehlen mir eventuell einige Kernelmodule (Couldn't set pass-filter in kernel: Invalid argument) oder ist das auf fehlerhafte Konfigurationsdateien zurückzuführen?
Koenntest du sie mal an die Liste posten (Passwort vorher auskommentieren)?
Es gibt fuer Debian uebrigens ein sehr komfortables Programm 'pppoeconf' mit dem man die DSL-Verbindung konfigurieren kann.
Ciao, Tobias
Hallo Tobias,
Es gibt fuer Debian uebrigens ein sehr komfortables Programm 'pppoeconf' mit dem man die DSL-Verbindung konfigurieren kann.
Vielen Dank, dieser Tip hat mir weitergeholfen und die Verbindung funktioniert jetzt endlich. Ich weis zwar dadurch noch nicht wo der Fehler lag aber ich werde die Sicherungen der Konfigurationsdateien mal mit den jetzigen vergleichen.
Grüsse Clemens
Clemens Altenburger wrote:
Vielen Dank, dieser Tip hat mir weitergeholfen und die Verbindung funktioniert jetzt endlich. Ich weis zwar dadurch noch nicht wo der Fehler lag aber ich werde die Sicherungen der Konfigurationsdateien mal mit den jetzigen vergleichen.
Hallo. Hatte ein ähnliches Problem, daß die Verbindung unterbrochen wurde, wenn bei der Verbindung vom Server nicht die DNS-Server abgefragt wurden (use peer dns, oder sowas).
Vielleicht hilft das bei der Suche.
Grüße, Frank Benkstein.
lug-dd@mailman.schlittermann.de
-
Clemens Altenburger -
Fabian Hänsel -
Frank Benkstein -
Rico Koerner -
Tobias Koenig