Reboot bei MiNT

[Lukas Frank]

Keine Ahnung, ich habe keinen Rechner mit 030 CPU ...

Bei mir geht die erste Diskette auf dem Mega STE, die zweite bombt bei mir.

[ari.tao]

Ich habe noch eine ganze Reihe von Versuchen unternommen, das Ding in Gang zu bringen, auch mit 1-18-0, aber alles vergebens, er bleibt immer wieder nach der selben og. Meldung hängen... Wenn ich zurück gehe auf 1-15-9, geht alles, MTOS, NAES, GENEVA, STOS...
Was sind denn nun die ´external modules´?
(nfs & keytable werden vorher geladen, also handelt es sich offenbar nicht um Treiber).

[Nervengift]

Warning: since version 1.16.0 FreeMiNT ignores "multitos" folder in the root of your boot-drive (done for backward compatibility with MultiTOS).

http://wiki.sparemint.org/index.php/User_manual

Hattest Du mal die mint.ini entsprechend angepasst, so dass keine Treiber geladen werden?

http://wiki.sparemint.org/index.php/Mint.ini

Und die Treiber müssten die externen Module sein. Normalerweise kannst Du ab MiNT 1.16.x das auch übers Bootmenü steuern. Siehe den Link ganz oben. Im Grunde alles ganz einfach.

[tuxie]

im Ordner \mint\1-1x-CUR\xxx befinden sich die Kernel Module

xif, xdd Dateien.

Das Verzeichnis muß dem der Kernelversion entsprechen und darf auch nicht umbenannt werden. also 1-19-CUR z.b.

[ari.tao]

Hab´ ich doch alles so: c:\mint\1-19-cur\ etc., gefüllt mit den Dateien aus dem .ZIP .
xif gibt´s da nicht. Die beiden xdd sind drin.
MiNT.ini sagt mir, daß es automatisch erzeugt wird und nicht editiert werden darf.

[Nervengift]

MiNT.ini sagt mir, daß es automatisch erzeugt wird und nicht editiert werden darf.

Ignorieren und editieren!

Hab´ ich doch alles so: c:\mint\1-19-cur\ etc., gefüllt mit den Dateien aus dem .ZIP .
xif gibt´s da nicht. Die beiden xdd sind drin.

Welche Dateien befinden sich in "c:\mint\1-19-cur\"? Poste am besten mal einen Screenshot. Und am besten auch den Inhalt der mint.ini und der mint.cnf.

[Lukas Frank]

Die mint.ini muss man auch nicht von Hand Editieren, einfach wenn die Meldung kommt die linke Shift Taste drücken und schon kommt man in die Einstellungen ...

[ari.tao]

_^^_ Weiß ich doch, hab´ ich auch so gemacht...im Anhang:
1) MiNT.CNF
2) ScreenShot aller relevanten Dirs. plus MiNT.ini
3) Zwei Fotos der Bootsequenz ab MiNT-Start bis Hänger

[tuxie]

Prüf mal bitte die Pfade die müssen

u:\c\xxxx 

lauten. Zumindest die Pfade in der mint.cnf

[Lukas Frank]

Daran liegt es nicht. Die erste Diskette läuft ja mit dem mint000.prg bei mir ohne Probleme. Zudem ist es mint egal ob / oder \ , manchmal geht / sogar besser ...

[Lukas Frank]

Rufe doch mal das ini auf und schalte mal zum Probieren XDD und XIF laden beide auf aus ...

[ari.tao]

Habe xdd und xfs beide auf ´no´ gesetzt (xif gibt es nicht); Ergebnis:
Jetzt macht er zwei Zeilen mehr, nämlich:
     Starting up the update daemon ... done!
     Starting up the idle process (pid 0) ... done!
Danach hängt er wieder!
Reset-Knopf einmal: alles dunkel, nix rührt sich,
noch einmal: Kaltstart statt Warm-Reset, genauer: Start von e: anstatt von der Default-Partition, aber mit neuer TrueDisk (dh. die bestehende, normalerweise reset-feste Truedisk wurde ausgehängt!)
Dieses Reset-Verhalten deutet imho darauf hin, daß MiNT resvalid & resvector nicht richtig behandelt! (Wenn man sich (wie MiNT es ausgiebig tut) in System-Vektoren einhängt, muß man _sofort_ auch die Wieder-Aushängung in resvector installieren!)
Könnten die Hänger ihre Ursache im Speicher-Management von MiNT haben?!

Edit.: Ein Prg., daß sich aufhängt, ohne einen Seufzer zu lassen, ist imho sowieso ziemlich unanständig. Da fehlen auf jeden Fall ein paar Sicherheits-Abfragen!

[HelmutK]

Für mich sieht das so aus als ob das "multitos" abstürzt, MiNT kommt bis zum Schluss. Was ist denn mit einem der gängigeren GEM=/INIT=-Varianten? Geht denn z.B. INIT=/bin/bash (falls vorhanden)?

Und was soll das?

Code: [Auswählen]

  exec u:\cmd\break.prg
  exec u:\cmd\vt_cls.prg
  exec u:\cmd\vt_norm.tos

?

-Helmut

[Lukas Frank]

Und was soll das?

  exec u:\cmd\break.prg
  exec u:\cmd\vt_cls.prg
  exec u:\cmd\vt_norm.tos

Wo soll das denn sein ?


gem.cnf

---------------
# gem.cnf
# Last Modified on 0/0/1980 00:00
#======================================================
setenv PATH=.,A:\MULTITOS,A:\MINT
setenv ACCPATH=A:\
setenv ACCEXT=ACC,ACX
setenv GEMEXT=PRG,APP,GTP
setenv TOSEXT=TOS,TTP
setenv SHSHOW=A:\MULTITOS\VIEWER.APP
setenv SHPRINT=A:\MULTITOS\LPR.APP
setenv TOSRUN=A:\MULTITOS\MINIWIN.APP

---------------

mint.cnf

---------------
setenv PATH /sbin;/bin;/usr/sbin;/usr/bin
setenv SLBPATH /c/mint/slb
setenv HOSTNAME saturn
setenv TMPDIR u:/tmp

#
# MultiTOS

GEM=A:\MULTITOS\GEM.SYS

echo Setup complete, now booting the system...
echo

---------------

In der mint.cnf die "setenv" Sachen kann man wegmachen denke ich, die Treffen je nicht zu.

[ari.tao]

_^^_ Das sind schlicht drei kleine (seit langem bewährte) Zusätze, 1. eine Gelegenheit zur Pause (damit man die letzten MiNT-Meldungen noch sehen kann, die sonst sehr schnell vom Schirm verschwinden), 2. ein Screen-Blanking (zum sauberwischen), 3. um den Alfa-Cursor wieder auf Home & die Schriftfarbe auf schwarz zu setzen etc.
Damit Du beruhigt bist, habe ich die drei kurzerhand wieder ausgehängt und den Test wiederholt. Selbstverständlich ist das Ergebnis unverändert!
-------
Das MTOS, das ich benutze, ist die Version 4.1ß; ist ebenfalls altbewährt (startet problemlos mit MiNT_1.15.9 und anderen). Um auch hier alle Eventualitäten auszuschließen, habe ich es mal eben durch die Version aus Eurem ZIP ersetzt und den Test noch einmal wiederholt. Selbstverständlich ist das Ergebnis unverändert!
-------
GEM=... ganz ausgehängt (um SoloMiNT/SingleGEM zu starten, wie Eric Smith es tat) führte auch zu keiner Änderung!
-------
\bin\bash ist bei mir nicht vorhanden (bin nicht so der Unox-Freak). Könnte es mal mit INIT=c:\u\bin\sh oder INIT=u:\bin\sh versuchen?
Geht aber nicht vor frühestens heute Abend!
-------
Mein GEM.CNF ist ebenfalls altbewährt. Von Diskette booten will ich nun wirklich nicht! Das kann mal jmd. anders machen.

[ari.tao]

Habe soeben, wie vorgeschlagen, die vier setenv ´rausgenommen: Ergebnis dito.
Habe zusätzlich GEM= durch INIT= ersetzt: Ergebnis unverändert.
Habe statt GEM=... dann noch INIT=u:\bin\sh gesetzt: Immer der gleiche Hänger!
Jetzt weiß ich nix mehr, was ich noch verändern könnte.
-------
Noch eine Idee, da anscheinend die spezifizierten Pfade/Dateien nicht gefunden werden: Stimmt etwas nicht in der jetzigen MiNT-Version mit der Umwandlung von Groß- in Klein-Schrift (oder umgekehrt)?

[HelmutK]

Wo liegt denn /bin - ext2? Vielleicht stimmt ja mit dem ext2fs was nicht. Kopier mal /bin/sh nach c:/bin/sh und gib das in mint.cnf an.

[ari.tao]

Ich habe kein ext2, nur FAT16 (und eine FAT32).
u:\bin\  == c:\u\bin\
-------
Soeben ausprobiert: INIT=c:\u\bin\sh
Ergebnis: Der übliche Hänger!

[ari.tao]

Endlich etwas Licht am Ende des Tunnels!
Zunächst die guten Nachrichten:
1) INIT=c:\u\bin\sh lief endlich. Hintergrund su.
2) Dann startete auch GEM=c:\multitos\gem_41.sys und lief teilweise. Weiteres su.
Nun die schlechten Nachrichten:
3) Das gem.sys aus dem .ZIP (= MTOS_4.0) hängt sofort nach dem Start!
4) Ein ScreenShot war nicht möglich.
5) Es gab während des MiNT-Boots und auch unter MTOS_4.1 diverse Fehler-Meldungen.
Und nun die ganz schlechten Nachrichten, Hintergrund & weiteres:
6) Obwohl mit der sh die Tastatur-Benutzung lief, ging diese nicht unter MTOS_4.1.
    Maus-Benutzung war unter MTOS_4.1 nur teilweise möglich (zB. kein DoppelKlick zum Start von
    Prgen., aber das Menue ´öffnen´ funzte!)
7) Der Teil-Erfolg war erst möglich, nachdem ich BlowUp ausgehängt hatte.
    Das aber ist auf meinem Falken unverzichtbar !!!

Im Anhang BlowUP & MTOS_41
Hinweise: Das MiNTnp ist das 1.15.9 (mit dem MTOS bis auf gewisse Bugs einigermaßen läuft); die Neon-Icons sind von mir (habe sie benutzt, weil sie grade installiert waren auf e: und ich das NEWDESK.CNF nicht auch noch anpassen müssen wollte); auch das ALERT.ACC ist eine neuere Version, war aber gar nicht installiert (ist afaik ohnehin nur für SoloMiNT/SingleTOS gut).

PS: Ich muß jetzt leider drei Wochen Pause machen (muß nach Hannover reisen).
Ich hoffe, Ihr habt bis dahin alle angesprochenen Probleme gelöst  !

[HelmutK]

Geht doch! Ich war schon drauf und dran, ein spezielles Test-Setup zu erstellen, das erübrigt sich ja jetzt glücklicherweise.

Zu MTOS-Tastatur: MTOS läuft wahrscheinlich im Supervisor-Modus, so dass das nicht geht. Probier mal mit meinem kernel GEM=ROM (hier müsste die Tastatur jetzt gehen), und versuch das MTOS dann vom TOS-Desktop zu starten. Oder halt Ausschau nach nohog.acc. Vielleicht geht ja auch GEM=MTOS mit meinem kernel.
Was ist denn eigentlich so toll am Multitos? Ich hab das vor 80 Jahren mal kurz probiert, und bin dann sofort auf XaAES (0.6 oder so) umgestiegen.

Zu BlowUp: Hab ich nie benutzt, kenn ich nicht. Ich würde es mal nach MiNT starten, oder aus mint.cnf heraus.

-Helmut