Software > Alternative Betriebssysteme

Reboot bei MiNT

<< < (11/24) > >>

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: ---  exec u:\cmd\break.prg
  exec u:\cmd\vt_cls.prg
  exec u:\cmd\vt_norm.tos


--- Ende Code ---
?

-Helmut

Lukas Frank:

--- Zitat von: HelmutK am Fr 16.09.2016, 23:33:28 ---Und was soll das?

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


--- Ende Zitat ---

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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete