Also bei Windows auf jeden Fall zuerst XP installieren, dann Windows 7Andersrum ist nerviger, aber geht auch.
Das habe ich schon vermutet, wird also so gemacht werden. Für die Win7-Installation kann ich die HDD mit dem WinXP sicherheitshalber abstöpseln.
Bei deinem genannten Anwendungsfall würdest du aber mit einer aktuellen Mehrkern CPU (Haswell, Ivy..) besser fahren....
Da max. WinXP 32-Bit eingesetzt werden soll, könnte es mit aktueller Hardware problematisch werden, da dafür nicht mehr notwendigerweise vernünftige Treiber, die die Hardware optimal ausnutzen, programmiert werden:
Hardwarekomponente_läuft_irgendwie_auch_mit_WinXP != vernünftig
Ein Pentium 4 mit ≥ 3,4 GHz auf Sockel-478 hingegen dürfte in Verbindung mit WinXP kein Problem sein. HT sollte sich im BIOS deaktivieren lassen.
Auf einem x86_64-System sollen zwei Linuxe (Slackware64-13.0, bereits installiert, und Slackware64-14.0 bzw. aktuell) sowie Windows 7 professional SP1 64-Bit und Windows XP professional SP3 32-Bit (u.a. für alte 16-Bit-Software) installiert werden.
Ein Windows (9x/XP/7 64-Bit) & ein oder mehrere Linuxe auf einem PC sind für mich ein alter Hut, aber was ist bei der Installation von mehr als einem Windows & mehreren Linuxen zu beachten?
Angestartet werden alle Betriebssysteme von LILO, da ein Linux mein hauptsächlich genutztes Betriebssystem ist.
Der ganze Kram wird sich über mehrere Festplatten verteilen. Auf die SSD, die an einem SATA-Port im AHCI-Moduls läuft, kommen Slackware64-14.0 und Win 7 64-Bit, auf eine ältere HDD, die an einem SATA-Port im IDE-Moduls läuft, das WinXP, und auf eine weitere Festplatte, die an einem SATA-Port im AHCI-Moduls läuft, das stabile Notafall-Linux.
Die beiden Windows sollen nichts voneinander wissen. Reicht es, die jeweiligen Laufwerksbuchstaben auszublenden?
Ist die Installationsreihenfolge bei Windows egal oder sollte eines der beiden Windows sinnvollerweise zuerst installiert werden?
Unschöne Hinterlassenschaften im MBR werden beseitigt, indem nach jeder Windows-Installation ein Linux von der Distri-DVD angestartet wird und dann LILO ausgeführt wird.
installiert: Slackware auf ia32¹, Slackware64 auf x86_64
Live-System: Knoppix²
¹ Selbst auf Kisten aus dem Neolithikum (386er, 486er) läuft eine Slackware 9.0 (386er) bzw. 9.1 (486er) flüssiger als das extra für Fossilien gestrickte Deli-Linux.
² v3 auf 486ern (mit btmgr-Diskette anstarten); v5 auf Sockel-4/5/7/Super-7/370/Slot 1/Slot A (Sockel-4/5/7 ggf. mit btmgr-Diskette anstarten); v6 auf Sockel-A/423; v7 auf Sockel-478/775/A (Athlon XP ≥ 2 GHz & ≥ 2 GiB RAM) und allen x86_64-Kisten (mit "knoppix64" gestartet).
Wieso fehlt in der Abstimmungsliste eigentlich die älteste aktive Distri, also die Slackware? Das ist schließlich keine Supersommersonderexoten-Distri
Memory Test kommt noch
Mindestens 3 Durchläufe memtest86+ fehlerfrei sind Pflicht. Kaputtes RAM oder zu aggressive RAM-timings können solche Symptome auslösen.
Ich hatte sowas mal unter Linux. Da traten die Probleme immer erst auf, wenn KDE3 lief und einige Anwendungen gestartet waren und insgesamt mehr als 256 MiB RAM belegt wurden. In der Kiste steckten 256+256+512 MiB RAM, der mittlere 256 MiB-Riegel war kaputt.
FSP 350 Watt Netzteil (reicht dicke System zieht gemessen max. 200 Watt)
Reichen die einzelnen Leistungen auf allen Strängen? Bei 350 W total ist da u.U. nicht viel "Luft" bei so einem modernen Desktopsystem.
Ausreichend Kühlung ist gegeben !
Trifft das auch für die Grafikkarte zu? Die liegt nämlich meist nicht im Hauptluftstrom.
Teste mal mit einem Live-Linux. Wenn da unter X ähnliche Phänomene auftreten, liegt ein Hardwareproblem vor. Wenn nicht, kann es auch an der Windows-Installation (Treiber) liegen.
auf dem Prozessor so eine klebrige Kühlmatte.
Hab den Kühler abbekommen
Es ist ein I486 DX2 CPU drauf mit 66MHz.
Weg mit der "Kühlmatte" (Wärmeleitpad)! Die taugt nix und ist eh überaltert und jetzt auch mehr oder weniger kaputt. Entferne deren Reste sorgfältig von Kühlkörper und Prozessor. Bei der Wärmeleitpaste hast Du die freie Wahl, das weiße Zeug auf Zinkoxidbasis reicht aus.
Der i486DX2-66 kommt nominell gerade noch ohne Lüfter aus. Quäl das Ding einfach mal mit memtest86. Wenn Dir der Kühlkörper zu warm wird, pack einen 40×40-Lüfter drauf.
Ein Sockel 3 Mainboard mit S3 928PCI GrafikkarteIch frage mich ob das Mainboard noch Funktionstüchtig ist, hab leider nur noch ATX Netzteile.
Frage nicht Dich, sondern die Hauptplatine.
Schau erst mal nach, was da für ein Prozessor unter dem Kühlkörper sitzt. Evtl. braucht der einen Lüfter und die Wärmeleitpaste kann dann auch gleich durch Neue ersetzt werden.
Nimm die Speicherriegel raus, schau Dir an, wie gammelig die Kontakte sind, ergreife entsprechende Maßnahmen und steck sie dann wieder rein.
Stell Dich schon mal mental darauf ein, dass die Batterie im Dallas-Modul tot ist oder bald ableben wird, was entsprechende Maßnahmen erfordert, wenn die Hauptplatine weiter genutzt werden soll.
Wenn beim Test kein Bilder (POST-Screens bis zum vergeblichen Startversuch eines Betriebssystems) kommen, teste alle Komponenten (Hauptplatine, Prozessor, Grafikkarte, Speicherriegel) mal getrennt, also jeweils nur eine Komponente auf einem funktionierenden System.
Hallo,
da leider sich meine SSD verabschiedet hat, musste ich mein Gentoo auf dem Notebook neuinstallieren..
Ich hab das Problem, dass Xorg nicht will.. gemäß Log heißt es, dass der die Grafikkarte einfach nicht finden kann..
Starte mal mit einem Live-Linux von einem Wechseldatenträger, um Hardwareprobleme auszuschließen. Wenn da dann X & GUI gestartet sind, schau in das Logfile von X, häufig /var/log/Xorg.0.log und teile den Inhalt mit.
Was sagt "lspci -v" zu dem Grafikchip?
Ein Pentium-S 200 (200 MHz @ 66 MHz FSB) läuft auf einer Hauptplatine MSI MS-5117A mit 64 MiB RAM (optional 96 MiB RAM). Das Ding lief einige Jahre als fli4l-router, stand dann einige Jahre in der Ecke rum und sollte nun mit Windows 95c (optional 98SE) und Slackware-9.1 (optional 10.2) einer anderen Nutzung (Messwerte über RS232 einsammeln, zeitunkritisch) zugeführt werden. Beim Einschalten fiel dann auf, dass die auf der Hauptplatine verbauten 256 KiB L2-Cache (pipeline burst SRAM) im BIOS-Statusfenster nicht angezeigt werden. cachechk erkennt ebenfalls keinen L2-Cache.
Ist nun der L2-Cache hinüber oder kann es auch "nur" das (gesockelte) Tag-RAM dahin gerafft haben?
Lässt sich die Hauptplatine ganz ohne L2-Cache noch sinnvoll (s.o.) einsetzen oder wird das so unerträglich lahm, dass die besser gleich in den Elektroschrott wandert?
USB-Tastaturen und USB-Mäuse funzen wohl meistens - alles andere wohl meistens nicht.
USB-Sticks sollen damit ab Windows 95 OSR 2.1 funktionieren. Hat das hier mal jemand probiert?
Jetzt wird es skurril.
Das MSI PM8PM-L läuft stabil mit einem Intel Pentium D 820 SL8CP (Smithfield; 2,8 GHz ×2; TDP 95W). Damit scheitert der stabile Betrieb des Pentium D 950 nicht an seiner TDP von 95W und auch nicht an der Tatsache, dass der ein "Zweikernprozessor" (genau genommen zwei Einkernprozessoren in einem Gehäuse) ist. Vcore ist auch nicht das Problem.
Anscheinend mag die Hauptplatine einfach den Pentium D 9xy (Presler) nicht. Wenn MSI allerdings nur mal schnell den Pentium D 960 drauf gesteckt hat und dann gesehen hat, dass das BIOS den korrekt erkennt, dann sind alle Pentium D 9xy mit max. 95W TDP mal eben auf der "CPU compatibility list" gelandet.
Somit bleibt der Pentium D 950 bis auf Weiteres heimatlos.
Mit dem Pentium D 820 (Hauptplatine unterstützt Pentium D mit max. 95 W TDP, daher kein Pentium D 830 oder 840) auf dem MSI PM8PM-L mit 2 GiB RAM (mehr geht leider nicht) dürfte ein System bestehen, dass seine maximale Ausbaustufe erreicht hat. Nur 2 GiB RAM wird für Linux x86_64 natürlich recht eng.
Unterstützt das Medion Bios die CPU?
Keine Ahnung, habe ich nicht ausprobiert.
Nach einem fehlerfreien Druchlauf memtest86+ wurde erst mal das besch☠☠☠ene Medion-BIOS durch das aktuelle MSI-BIOS ersetzt.
Es kann auch sein das msi die boards für Medion ultraknapp kalkuliert hat, und die spannungsversorgung schlicht nicht ausreichend ist. Oem boards sind häufig mal heikel. Hab nen Fujitsu oem bei eBay Händler gekauft, wo es auch nur hieß c2d bis 65 watt Leistung. Drüber würden auf dem Papier her laufen, aber halt nicht stabil 20 Cent am board gespart, und schnell einige Rendite mitgenommen.
Die Hauptplatine enthält keinen sichtbaren Hinweis auf Medion oder generell OEM. Nach dem Ersatz des Medion-BIOS durch das MSI-BIOS ist auch beim Startvorgang nichts mehr von Medion oder OEM zu erkennen. Das heißt natürlich nicht, dass da nicht doch irgendwo gespart wurde und dadurch ein Prozessor mit 84 W TDP stabil läuft, aber einer mit 95 W TDP nicht mehr. Das Fiese ist hier ja, dass der instabile Betrieb erst in Verbindung mit einem Betriebssystem auftritt. Das BIOS hat kein Problem mit dem Prozessor und selbst memtest86+ läuft ja fehlerfrei. Letzteres lässt den Schluss zu, dass die Instabilität erst auftritt, wenn beide Kerne des Prozessors belastet werden. Letztlich bleibt natürlich auch die Möglichkeit, das die Angaben von MSI zu den kompatiblen Prozessoren schlicht falsch sind.
Abit AW8D kann keine C2D
Und nicht grad ein Billigboard damals gewesen..
Und auch heute nicht günstig zu bekommen.
Fast hätte der heimatlos gewordene Intel Pentium D 950 SL9K8 (Presler; 3,4 GHz ×2) ein neues Zuhause gefunden, aber eben nur fast.
Im Zuge einer PC-Aufrüstung fielen mir folgende funktionsfähige Komponenten in die Hände, ein Intel Pentium 4 620 SL8AB (Prescott 2M; 2,8 GHz HT) auf einem MSI PM8PM-L mit 2 GiB DDR2-RAM PC-800 (Vollbestückung) und eine nvidia GeForce 6200 (256 MiB RAM; AGP 8×). Nach einem fehlerfreien Druchlauf memtest86+ wurde erst mal das besch☠☠☠ene Medion-BIOS durch das aktuelle MSI-BIOS ersetzt. Nach diversen erfolgreich verlaufenen Tests (memtest86+, Kernel kompilieren unter Linux, glxgears auf KDE4) und einer Internetrecherche wurde dann der Pentium D 950 eingebaut. Laut MSI kann die Hauptplatine mit dem Prozessor umgehen. Der Prozessor wird vom BIOS korrekt erkannt. memtest86+ läuft fehlerfrei durch. Wenn aber ein Linux (mehrere getestet, alle laufen stabil, wenn der Pentium 4 620 auf dem PM8PM-L werkelt) ins Spiel kommt, wird es seltsam. Der Kernel startet normal. Danach kann aber nahezu jeder beliebige Befehl auf der Konsole oder unter X, sofern dies überhaupt startet, das System mit einer "Kernel panic" ins Nirvanan schießen. In einem Fall wurde gleich ohne Vorwarnung ein reboot ausgelöst.
Was ist da los?
Da nur Hardware eingesetzt wurde, die bekanntermaßen funktioniert, scheidet ein Hardwarefehler aus.
Nach der Liste sind die meisten Grafikkarten schon in den passenden Systemen gelandet. Lediglich die "nvidia GeForce FX5200GT 256 MiB AGP 8×" wird etwas "nach unten" wandern.
wobei es da wohl auf den Unterschied DX8 vs. DX9 ankommt.
Seit wann läuft DirectX unter Linux?
Für die nvidia-Grafikkarten wird z.Z. der proprietäre nvidia-Treiber genutzt, für die ATI-Grafikkarten der xorg-Treiber + Kernel-DRI-Modul. Letzteres geht nicht mit der Radeon HD, weshalb die erst nach einem Update auf Slackware64-14.0 (oder höher) und einen halbwegs aktuellen Kernel 3.x zum Einsatz kommen kann.
Generell sieht die agp Liste ganz gut aus.
Sind im Vergleich zu den aufgelisteten nvidia GeForce die aufgelisteten ATI Radeon 9600XT & 9550 also so schwach, dass sie am unteren Ende der Liste richtig stehen?
Gibt Vramdir, kostet aber, soweit ich weis.
Laut dieser Beschreibung ist vramdir etwas anderes. Danach arbeitet es vergleichbar wie das tmpfs unter Linux.
Linux-Kernel: tmpfs != slram
Das Problem der sinnvollen Aufteilung des RAM in cached RAM als Arbeitsspeicher und uncached RAM als RAM-Disk bieten weder tmpfs noch vramdir lt. oben erwähnter Beschreibung.
Die nachfolgend aufgelisteten Grafikkarten möchte ich den verschiedenen verfügbaren Systemen so zuordnen, dass die leistungsstärkste Grafikkarte in das leistungsstärkste System kommt usw..
AGP (ia32-Systeme, Linux 32-Bit, Kernel 2.6.x):
Die meisten in Frage kommenden Systeme bieten einen AGP 8× oder AGP 4× Steckplatz. Die Grafikkarten funktionieren in AGP 8× und AGP 4× Steckplätzen, die FX5200 und die Radeon 9000 auch in AGP 2× Steckplätzen.
PCIe (x86_64-Systeme, Linux 64-Bit, Kernel 2.6.x):
Wie wichtig ist eigentlich die Speichergröße (hier AGP ab 128 MiB, bis auf die eine mit nur 64 MiB; PCIe ab 512 MiB)?
Für die nvidia-Grafikkarten wird z.Z. der proprietäre nvidia-Treiber genutzt, für die ATI-Grafikkarten der xorg-Treiber + Kernel-DRI-Modul. Letzteres geht nicht mit der Radeon HD, weshalb die erst nach einem Update auf Slackware64-14.0 (oder höher) und einen halbwegs aktuellen Kernel 3.x zum Einsatz kommen kann.
Wie müssen also nach Leistung der Grafikkarten die obigen Listen umsortiert werden?
Ich habe schon einige vServer administriert und habe selbst Ubuntu/Fedora fast über ein Jahr lang auf meinem System für den Produktiveinsatz konfiguriert und benutzt.
BTW: Ich bin gewillt, mich durch Dokumentationen zu hangeln und MAL was zu frickeln
Unter diesen Voraussetzungen, die du vielleicht zwecks Vermeidung von Missverständnissen in deinem Startbeitrag hättest erwähnen sollen, wäre auch die Slackware bzw. Slackware64 etwas für dich. Slackware ist z.Z. die älteste aktive Distri, und im Gegensatz zu den bunte-Bilder-Distris wie etwa Ubuntu oder SuSE finde ich die sehr übersichtlich. Installiert wird komplett im Textmodus. Die Konfiguration erfolgt über Textdateien (Ausnahme: GUI mit den jeweiligen Bordmitteln). Erst wenn das System "steht" (Kernel passend zur Hardware kompiliert - auf Standardhardware meist kein "Muss", Netzwerk eingerichtet, usw.) werden X und die GUI konfiguriert. GNOME muss man allerdings zu Fuß nachschieben, aber da gibt es u.U. "inoffizielle" Slackware-Pakete.
Anm.: Warum GNOME aus der Slackware rausgeflogen ist, kann ich, obwohl ich es nicht nutze, nicht nachvollziehen.
Wollte hier eh platt machen.
Ich will als Distro Antergos nehmen und mal GNOME3 richtig testen. Gute Idee, oder nicht? Was soll ich beachten?
Würde dann auch gleich mal vim etc. ausprobieren.
Die Auswahl der Distro hängt von mehreren Faktoren ab:
Wenn die Festplatte genug Platz bietet, würde ich nicht "entweder oder", sondern "sowohl als auch" durch eine entsprechende Partitionierung ermöglichen, z.B. so für ein Linux und ein WinNT-Derivat:
/dev/sda1 7 HPFS/NTFS (Windows Programmpartition)
/dev/sda2 83 Linux (ext3 bei Kernel 2.6 oder ext4 bei Kernel 3.x, Linux /boot)
/dev/sda3 83 Linux (ext3 bei Kernel 2.6 oder ext4 bei Kernel 3.x, Linux /)
/dev/sda4 f W95 Ext'd (LBA) (erweiterte Partition)
/dev/sda5 c W95 FAT32 (LBA) (gemeinsame Datenpartition für Linux & Windows)
/dev/sda6 7 HPFS/NTFS (Windows Auslagerungspartition)
/dev/sda7 82 Linux swap (Linux Auslagerungspartition)
Diese Partitionierung ist natürlich nur eine Möglichkeit, funktioniert aber auch mit älteren Linux- & Windows-Versionen. Mit aktueller Software gibt es mehr Möglichkeiten.
vim ist -äh- seeeehr speziell.
Ausgangssituation: Sockel-7-AT-Hauptplatine bestückt mit Pentium-S 200 und 128 MiB RAM; cacheable RAM area = 64 MiB, nicht erweiterbar
Auf der Kiste soll ein Win9x, zur Auswahl stehen Win95c oder Win98SE, installiert werden. Eine Abrüstung auf 64 MiB RAM kommt nicht in Frage, da auf der Kiste auch noch ein Linux installiert ist, das mit nur 64 MiB RAM keinen Spaß macht.
Bei Linux gibt es zwei Möglichkeiten, mit obiger Kiste umzugehen. Entweder man lässt es einfach laufen und baut darauf, dass der Linux-Kernel das RAM von unten nach oben füllt, also die wirklich wichtigen Sachen alle im cached RAM laufen. Oder man kompiliert einen entsprechenden Kernel, dem man dann per Bootparameter "mem=64M slram=ramswap,64M,+64M" mittteilen kann, dass er nur die ersten 64 MiB RAM als Arbeitsspeicher nutzen soll und im Rest, dem uncached RAM, eine RAM-Disk anlegen soll.
Gibt es eine ähnliche Möglichkeit (nur cached RAM als Arbeitsspeicher, Rest als RAM-Disk) für Win9x?
