Hallo, evtl hat hier ja jemand tiefergehende Linuxkenntnisse. Ich habe ein 486 Embedded PC, auf dem ein abgespecktes Debian installiert ist. Ich möchte mir nun die Console auf die serielle Schnittstelle ausgeben lassen. Das funktioniert bisher auch soweit und ins BIOS komme ich schon über die serielle und auch die Bootmeldungen werden übertragen. Das Problem ist nun aber, das ich auf der seriellen Schnittstelle keine Konsole zu sehen bekomme, und ich nicht weiterkomme wo man das konfigurieren kann. Standardmäßig wird die Bash nicht gestartet(also auch wenn ich mir die Ausgabe des Boards per VGA anzeigen lasse, bleibt es nach dem Booten stehen) Die Console ist nur per Telnet zugänglich. Nun muss man doch aber irgendwo den Start der Bash konfigurieren können. Die Option boot=/bin/bash in der GRUB menu.lst hat nicht funktioniert. Wo ändert man sonst noch das Bootverhalten? Es wird automatisch noch eine BusyBxo gestartet, aber ich habe noch nicht herausgefunden, wo. Irgendwo an der Stelle hoffe ich, auch den Start meiner Bash eintragen zu können. Weiß jemand wo man da ansetzen muss?
Ich kenne jetzt dein System nicht, aber ich würde bei der /etc/inittab anfangen zu suchen (wenn hier nicht jemand anderes den schnelleren Weg kennt). Gibt es die bei dir? Wie sieht die aus? Bei dem PC an dem ich gerade sitze steht da:
1 | # /etc/inittab: init(8) configuration. |
2 | # $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $ |
3 | |
4 | # The default runlevel. |
5 | id:2:initdefault: |
6 | |
7 | # Boot-time system configuration/initialization script. |
8 | # This is run first except when booting in emergency (-b) mode. |
9 | si::sysinit:/etc/init.d/rcS |
10 | |
11 | # What to do in single-user mode. |
12 | ~~:S:wait:/sbin/sulogin |
13 | |
14 | # /etc/init.d executes the S and K scripts upon change |
15 | # of runlevel. |
16 | # |
17 | # Runlevel 0 is halt. |
18 | # Runlevel 1 is single-user. |
19 | # Runlevels 2-5 are multi-user. |
20 | # Runlevel 6 is reboot. |
21 | |
22 | l0:0:wait:/etc/init.d/rc 0 |
23 | l1:1:wait:/etc/init.d/rc 1 |
24 | l2:2:wait:/etc/init.d/rc 2 |
25 | l3:3:wait:/etc/init.d/rc 3 |
26 | l4:4:wait:/etc/init.d/rc 4 |
27 | l5:5:wait:/etc/init.d/rc 5 |
28 | l6:6:wait:/etc/init.d/rc 6 |
29 | # Normally not reached, but fallthrough in case of emergency. |
30 | z6:6:respawn:/sbin/sulogin |
31 | |
32 | # What to do when CTRL-ALT-DEL is pressed. |
33 | ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -h now |
34 | |
35 | # Action on special keypress (ALT-UpArrow). |
36 | #kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work." |
37 | |
38 | # What to do when the power fails/returns. |
39 | pf::powerwait:/etc/init.d/powerfail start |
40 | pn::powerfailnow:/etc/init.d/powerfail now |
41 | po::powerokwait:/etc/init.d/powerfail stop |
42 | |
43 | # /sbin/getty invocations for the runlevels. |
44 | # |
45 | # The "id" field MUST be the same as the last |
46 | # characters of the device (after "tty"). |
47 | # |
48 | # Format: |
49 | # <id>:<runlevels>:<action>:<process> |
50 | # |
51 | # Note that on most Debian systems tty7 is used by the X Window System, |
52 | # so if you want to add more getty's go ahead but skip tty7 if you run X. |
53 | # |
54 | 1:2345:respawn:/sbin/getty 38400 tty1 |
55 | 2:23:respawn:/sbin/getty 38400 tty2 |
56 | 3:23:respawn:/sbin/getty 38400 tty3 |
57 | 4:23:respawn:/sbin/getty 38400 tty4 |
58 | 5:23:respawn:/sbin/getty 38400 tty5 |
59 | 6:23:respawn:/sbin/getty 38400 tty6 |
60 | |
61 | # Example how to put a getty on a serial line (for a terminal) |
62 | # |
63 | #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100 |
64 | #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100 |
65 | |
66 | # Example how to put a getty on a modem line. |
67 | # |
68 | #T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3 |
Durch Auskommentieren einer der getty-Zeilen kann man sich an der entsprechenden seriellen Schnittstelle anmelden, danach wird dann eine bash angeworfen (oder je nachdem welche Shell derjenige in der /etc/passwd eingetragen hat).
Genau. Getty ist dafür verantwortlich, auf Terminals zu warten. Aber es muss ein echtes getty sein, mingetty etwa ist m.W.n. für virtuelle Konsolen gemacht.
hmmm, ja ich habe mgetty auf dem system drauf und habe das in der inittab eingetragen. damit sehe ich wiegesagt auch den bootbildschirm etc, aber eine Konsole wird nicht gestartet. Das ist aber auch der Fall wenn man direkt an dem Rechner sitzt...die Konsole bekommt man nur, wenn man sich per Telnet einloggt. Was mir aufgefallen ist: wenn ich boote sehe ich die gesamten Bootmeldungen an der seriellen Konsole. Sitze ich direkt an dem Rechner sehe ich per VGA aber noch einen zusätzliche Zeile, das die Busybox gestartet wurde. Irgendwo dort scheint etwas umgeschaltet zu werden und das Ausgabeverhalten ändert sich. Evtl. kann ich einfach /bin/bash dort eintragen? Meine Linuxkenntnisse sind nicht sehr ausgeprägt...aber ich frage mich, welcher Mechanismus dafür sorgt, das der User beim Login per Telnet den Loginprompt und danach die Bash zu sehen bekommt. Und wenn ich Linux normal auf nem Desktop installiere, wird irgendwo ja auch die Shell gestartet. Geschieht das alles in der inittab? Kann meine Inittab erst morgen posten, da der embedded PC im Büro ist.
Darf ich mal ganz dumm fragen was einen auf die Idee bringt mgetty ("Modem-Getty") für die lokalen Konsolen zu verwenden? Hat das irgendwelche Vorteile? gruß Frank
A. B. schrieb: > hmmm, ja ich habe mgetty auf dem system drauf und habe das in der > inittab eingetragen. damit sehe ich wiegesagt auch den bootbildschirm > etc, aber eine Konsole wird nicht gestartet. wie bereits gesagt ist mgetty für Modemzugang da; für serielle Schnittstellen ohne Modem ist getty zuständig. > > Das ist aber auch der Fall wenn man direkt an dem Rechner sitzt...die > Konsole bekommt man nur, wenn man sich per Telnet einloggt. > > Was mir aufgefallen ist: wenn ich boote sehe ich die gesamten > Bootmeldungen an der seriellen Konsole. Sitze ich direkt an dem Rechner > sehe ich per VGA aber noch einen zusätzliche Zeile, das die Busybox > gestartet wurde. Irgendwo dort scheint etwas umgeschaltet zu werden und > das Ausgabeverhalten ändert sich. > Evtl. kann ich einfach /bin/bash dort eintragen? das wird nicht reichen. > > Meine Linuxkenntnisse sind nicht sehr ausgeprägt...aber ich frage mich, > welcher Mechanismus dafür sorgt, das der User beim Login per Telnet den > Loginprompt und danach die Bash zu sehen bekommt. Und wenn ich Linux > normal auf nem Desktop installiere, wird irgendwo ja auch die Shell > gestartet. Geschieht das alles in der inittab? Der telnet kommt daher, daß in der obigen Beispieldatei für die einzelnen run level jeweils ein Eintrag mit /etc/init.d/rc ... steht. rc wiederum sieht in einem Verzeichnis rc....d (bei mir in /etc) nach, welche Programme/Skripte dort stehen und mit S (Start) beginnen und führt die aus. Dabei wird auch eines für den telnet-Dämon stehen, deshalb wird der gestartet. Letztlich also indirekt auch über die inittab. Alternativ kann man zu startende Programme auch direkt in die inittab eintragen; davon hat man aber irgendwann Abstand genommen, als es zuviele wurden. > > Kann meine Inittab erst morgen posten, da der embedded PC im Büro ist.
also danke erstmal für die Antworten. mgetty benutze ich, weil das bei der Distribution vorinstalliert war. Wir bekommen zu den Embedded Modulen ein abgespecktes Linux Image dazu, welches dann von einer FlashDisk gestartet wird. Und bei dem abgespeckten Ding ist nicht viel dabei. auch kein apt-get, weswegen ich es erstmal mit dem agetty versucht habe, was eigentlich ja auch zu funktionieren scheint?! Denn ich sehe ja etwas auf meiner seriellen Konsole Soweit ich das verstanden habe sind die Gettys, Agettys, Mgettys usw relativ äquivalent und bieten mehr oder weniger die selben Funktionen. Ich kann da auch einstellen, das ich direkt nicht per Modem zugreife. Ich bezweifle, das ich einen Login-Promt zu sehen bekomme, sobald ich mich per getty einloge. Irgendwie muss ich dem Ding ja noch verklickern das es die Bash starten/bzw. einen LoginPrompt anzeigen soll. Oder liege ich da falsch?
Das getty würde nach Benutzername und PW fragen, dann in der /etc/passwd nachsehen, welche Shell zu dem Benutzer gehört, diese Shell starten und dabei deren Ein- und Ausgabe mit dem Terminal verdrahten. Die Shell wiederum zeigt dann jeweils ihren Eingabeprompt ($PS1) an. (Genau genommen ist dabei noch ein Programm login beteiligt; ich glaube der Name wird nch vom getty abgefragt, dann login gestartet, welches wiederum das PW abfragt und in die /etc/passwd schaut wg. UID, GID, zu startende Shell usw.; aber das sollte hier egal sein.) Ob mgetty das ebenfalls so beherrscht, weiß ich nicht. Es gibt seit langem beide Programme; das wird schon einen Grund haben. Zu getty und agetty hätte ich die man-Page greifbar, zu mgetty leider nicht. Demzufolge sollte getty auch mit Modems klar kommen, und agetty sieht dem getty in der Tat recht ähnlich. Mehr weiß ich dazu aus dem Stegreif leider nicht. Falls dir die man-Pages zu agetty und getty helfen könnten, bitte Bescheid sagen.
hmpf...also ich habe mir nun das getty von einem anderen Debian rüberkopiert, und auch damit kein Erfolg. Zumindest weiß ich aber nun, warum ich am VGA die Zeile mit der Busybox sehe. Die ganzen Bootmeldungen werden nämlich von GRUB ausgegeben, und noch nicht von dem getty. Und da ich die Busybox Meldung an der seriellen Schnittstelle nicht sehe, scheint mein getty nicht zu funktionieren. Auch bekomme ich es einfach nicht hin, einen Login-prompt per VGA zu erhalten... müßte nicht die Zeile: l:123456:wait:/sbin/login oder 1:2345:respawn:/sbin/getty tty0 einen login-prompt am VGA Ausgang anzeigen?? Aber schon das passiert nicht. Ich bekomme den Login-prompt nur per Telnet zu sehen. Und wo die Busybox in den init.d Files gestartet werden soll, ist mir noch ein Rätsel...finde da nix dergleichen, aber gestartet wird sie irgendwie. Naja, bin kurz davor das Ding mit einem großen Holzhammer zu bearbeiten ;P
A. B. schrieb: > ... > oder 1:2345:respawn:/sbin/getty tty0 einen login-prompt am VGA Ausgang > anzeigen?? Aber schon das passiert nicht. Ich bekomme den Login-prompt > nur per Telnet zu sehen. wenn schon an der seriellen (tty0 führt zu /dev/tty0, falls das existiert). Mit welcher Baudrate auch immer. Ein Binärprogramm von einem anderen Rechner zu kopieren, heisst aber nicht, daß es auch funktioniert... > ...
naja, also starten kann ich das getty schon, und er fragt nach all möglichen Parametern. aber auf der seriellen Console kommt da nix an. Ich habe jetzt gesehen das es ja noch x Dateien wie securetty, login.conf , pam.d/ gibt, die alle das Loginverhalten von dem Ding beeinflussen. Ich muss mich da wohl erstmal durchwursteln, und schauen was da überhaupt konfiguriert ist.
> aber auf der seriellen Console kommt da nix an
Hast du denn über die serielle Schnittstelle überhaupt schon mal was zu
sehen bekommen? Als erstes sollte mal dieser Teil funktionieren, du
solltest also z.B. erst mal abchecken, welches denn nun das korrekte
Device-File für die serielle Schnittstelle ist. Sorge erst mal dafür,
dass ein
1 | echo Hallo > /dev/xxxxx |
auch tatsächlich ein "Hallo" auf dein Terminalprogramm zaubert. Edit: Sorry, habe das hier übersehen: > es erstmal mit dem agetty versucht habe, was eigentlich ja auch zu > funktionieren scheint?! Denn ich sehe ja etwas auf meiner seriellen > Konsole WAS siehst du denn dann auf der seriellen Konsole?
jo, also die serielle Schnittstelle funktioniert. Was ich ja bemerkt hatte, das die Sachen die bisher über die serielle kommen nichts mit dem getty zu tun haben. Sondern da werden nur die GRUB Bootmeldungen übertragen... Die Meldung das die Busybox gestartet wurde sehe ich auf der seriellen Schnittstelle nicht mehr, aber per VGA. Also getty funktioniert demzufolge nicht. s0:23:respawn:/sbin/mgetty -r -s ttyS0 19200 vt100 oder c0:2345:respawn:/sbin/getty -L ttyS0 19200 vt100 führten nicht zum Erfolg.
Ok, dann würde ich mich doch erst mal um das "echo Hallo" kümmern. Bevor du nicht mal in der Lage bist "von Hand" was zu senden, hat alles weitere Probieren kaum einen Sinn. Und im nächsten Schritt testest du die nötigen getty-Parameter, indem du es von Hand startest. Erst im letzten Schritt kannst du es dann in den Boot-Prozess integrieren. Bis dahin würde ich auch alle gettys aus der inittab raus nehmen.
hö? nene, also die serielle Schnittstelle funzt. echo Hallo ... und ich sehe was im Hyperterminal. Daran sollte es nicht liegen. Ich versuche mal den händischen Getty-Weg
hey, das mit dem per Kommandozeile ausprobieren war ein guter Tip. getty -L ttyS0 9600 gibt mir den Login-Prompt auf der seriellen Schnittstelle aus, wenn ich es über Telnet eingebe. Packe ich die Zeile s1:2345:respawn:/sbin/getty -L ttyS0 9600 in meine inittab, dann passiert aber leider noch nichts :(
(das erfährt man aus der /etc/inttab in der Zeile mit ...initdefault...)
hmm..habe gerade bei meinem Desktop Debian nachgeschaut was du meinst. auf dem embedded Ding ist kein Standard-Runlevel eingetragen. Habe jetzt mal defaultlevel 2 eingetragen, aber keine Verbesserung. Wenn ich meinen Getty Befehl in eines der Init.d Skripte reinpacke, dann sehe ich auch den Loginprompt. Ist aber natürlich nur suboptimal, da beim beenden der getty nicht neugestartet wird, was inittab ja per respawn erledigen sollte.
ha...habs hinbekommen. Manchmal ist weniger eben mehr ;D ttyS0::respawn:/sbin/getty -L ttyS0 9600 vt100 tty0::respawn:/sbin/getty -L tty0 9600 vt100 spawnt die Console auf COM1 und auf VGA. Also ohne runlevel starten. Komischerweise meckert mein System auch bei id:3:initdefault: gibt mir die Meldung Bad initab command auf VGA aus. Warum auch immer.
Es gibt unterschiedliche init-Programme. Deines ist wohl eine schlanke Variante, die dann halt das eine oder andere Feature nicht hat. Der Runlevel kann auch beim Booten dem Kernel als Parameter mitgegeben werden.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.