Lowlevel
Lowlevel => OS-Design => Thema gestartet von: matheguru am 13. April 2009, 08:38
-
Ich habe drei Fragen:
1. Ich lasse mein Kernel von einer FAT32 Partition laden, dabei habe ich natürlich ein Problem die 32, ich befinde mich ja RM, also geht es nicht, oder doch ? In den PM schalten ist auch doof, wie soll ich dann einen ganzen Festplattentreiber in 512Byte bekommen. Gelöst habe ich das so, dass ab dem zweiten Cluster einfach der Kernel gespeichert ist, den Clusteroffsetberechnen und ab in den Speicher damit, denn sonst müsste ich ja vorher die ganze FAT in den speicher Laden und das würde den ganzen Arbeitspeicher sprengen. Was meint ihr dazu ??
2. Ich kann mit dem INT 13 ah=42 nicht mehr als ungefähr 10 Sektoren lesen, aber eig. kann man ja bis 127lesen, ist das von BIOS zu BIOS anders ?
3. Hat jemand schon versucht mit visual studio C++ den Ckernel zu kompilieren, denn der linkt immer die Bibliotheken rein, und in der Komandozeilenhilfe sthet nicht wie man das weg bekommt, geht das mit der IDE ? Wenn nicht dann muss ich halt gcc verwenden!
DAnke schon mal im voraus
-
Als erstes mal die Standardantwort: Wir empfehlen niemandem, selbst einen Bootloader zu schreiben. Ein guter Bootloader ist ein größeres Projekt für sich, und eigentlich bist du ja mit einem Betriebssystem vorerst ganz gut beschäftigt. Daher an dieser Stelle der obligatorische Verweis auf GRUB.
Warum allerdings FAT32 im Real Mode ein Problem sein sollte, verstehe ich nicht ganz. Dein Problem ist nur, daß du - wie du zutreffend sagst - in 512 Bytes schlicht keinen Platz hast für einen vernünftigen Bootloader. Man kann das dann so machen, daß man eine zweite Stufe des Bootloaders in eine Datei packt und im Bootsektor irgendwo ablegt, wo diese Datei genau liegt. Dann braucht der Bootsektor kein Dateisystem zu laden, sondern kann direkt seinen Rest nachziehen, der dann auch groß genug sein kann, um was vernünftiges zu implementieren.
-
3. Du kannst zwar die IDE Visual Studio C++ verwenden, aber den Compiler nur schwer. Ich kenne mich nicht so gut mit dessen Kommandozeilenparametern aus, also kann ich dir auch nicht sagen, was du da hinschreiben musst. Auf jeden Fall erzeugt der Microsoft Compiler PE Dateien (also .exe).
Ich verwende zwar Visual Studio C++ als Editor (weil er einfach immens praktisch ist), aber zum kompilieren verwende ich einen selbst gebastelten crosscompiler. Den musst du wohl auch machen, wenn du von Windows aus z.B. elf Dateien erzeugen möchtest... Aber da gibt es in der Wiki einen sehr guten Eintrag. (such einfach nach crosscompiler)
Im Internet bin ich vor langer Zeit mal auf etwas gestoßen, wo ein C Kernel mit MSVC erstellt wird, such einfach mal in google nach C Kernel MSVC oder so.
-
Zu 1.:
32-Bit-Integer im RM sollte wohl kein Problem sein.
Das ein Bootloader in 512 Bytes nicht reinpasst ist auch klar. Aber FAT bietet da abhilfe, reservierte Sektoren nach dem Bootsektor. Nutze diese um deinen Bootloader dort rein zu puzzeln.
Zu 2.:
Laut Definition des Interrupts schon, in der Praxis aber nicht. Maximal kannst du die Anzahl an Sektoren in einem Zug laden, wieviele es max. pro Spur gibt. Weiterhin reduziert es sich mit dem Sektoroffset, ab dem du in der Spur lesen tust. Bspw. auf einer Diskette mit 18 Sektoren pro Spur willst du ab Sektor 2 (beginnend bei 0) alle noch möglichen Sektoren in dieser Spur laden, so sind dies dann nur noch 16. Rechne dazu einfach MaxSektor - SektorOffsetInSpur um die max. Anzahl an ladbaren Sektoren zu erlangen. Anderweitig quitiert das BIOS es mit einer Fehlermeldung.
Ob es nun mit dem Extended-Read (ah=42h) genauso ist, kann ich zum derzeitigen Zeitpunkt nicht bestätigen.
Zu 3.:
Unmöglich ist es mit MSVC jedoch nicht, jedoch hab ich mich an der IDE auch die Zähne ausgebissen. Zum editieren kannst du gern die IDE nutzen, dazu reicht sogar die Express-Version von MSVC aus. Zum Kompilieren und Linken benutze ich das Buildtool "MSBuild.exe" aus dem .NET-Framework.
Einen entsprechenden Artikel wollte ich dazu ins Wiki noch schreiben.
Mein OS selbst entwickle ich auf diese Weise. Abgeschaut habe ich es mir von Microsoft's Singularity.
-
Danke für die Antworten, den Bootloader habe ich jetzt teilweise sozusagen ausgelagert auf die reservierten sektoren, bin auch schon fast fertig. Mein Kernel übersetzt ich jetzt mit MinGW funktioniert alles prima. Das mit den Extensions habe ich gelöst, indem ich einfach die anzahl der sektoren pro Cluster nehme, die Zahl ist nämlich max. 32. Das mit den Spuren könnte gut sein, aber irg. ist es klar das die menge an sektoren von HD-Controller zu HD-Controller anders sein kann! Na ja danke noch mal, wie findet ihr eig. meine Idee den Bootloader einfach vom NTLDR laden zu lassen, denn so mach ich das um weiterhin auch mein Windows benutzen zu können und ohne den NTLDR zu entfernen, denn den möchte ich auch behalten.
-
Wenn du grub als bootloader verwenden würdest, dann könnte dieser genauso NTLDR chainloaden oder auch deinen Kernel laden. Wäre weitaus komfortabler.
-
Ja ich weiß wohl, aber man kennt ja die Leute die sich zu einer bestimmten Sache nicht überreden lassen. Irgendwie ist alles eine Frage des Geschmacks oder wohl eher gesagt des Wollens.
-
Das ein Bootloader in 512 Bytes nicht reinpasst ist auch klar. Aber FAT bietet da abhilfe, reservierte Sektoren nach dem Bootsektor. Nutze diese um deinen Bootloader dort rein zu puzzeln.
Nicht gut. Du willst dich nicht an ein bestimmtes Dateisystem ketten.
Na ja danke noch mal, wie findet ihr eig. meine Idee den Bootloader einfach vom NTLDR laden zu lassen, denn so mach ich das um weiterhin auch mein Windows benutzen zu können und ohne den NTLDR zu entfernen, denn den möchte ich auch behalten.
Ebenfalls keine gute Idee. Du willst dich auch nicht an einen Bootloader ketten, für den du nicht das Recht zur Weiterverbreitung hast. Um es deutlich zu sagen: Ein funktionsfähiges Image deines OS weiterzugeben, ist damit illegal.
-
Das ein Bootloader in 512 Bytes nicht reinpasst ist auch klar. Aber FAT bietet da abhilfe, reservierte Sektoren nach dem Bootsektor. Nutze diese um deinen Bootloader dort rein zu puzzeln.
Nicht gut. Du willst dich nicht an ein bestimmtes Dateisystem ketten.
Sicher nicht, aber wer unbedingt einen eigenen Bootloader benutzen möchte, warum sollte er das FS nicht ausreizen?
Klar kann man es sich einfach machen und wie all zu oft schon heilig geredet zu GRUB greifen.
-
Das Problem ist, das ich mich nicht immer der Masse anpassen möchte, deswegen ist jetzt mein größeres Projekt ersteinmal, einen vernünftigen Bootloader zu schreiben der auch andere OS´s laden kann. Wird ne weile dauern, auserdem habe ich dann die vollen Rechte für den Bootloader.
-
Bewundernswert ... aber wie taljeth schon schrieb, ist ein eigener Bootloader ein Projekt für sich selbst, zumal deiner ja auch noch andere OS laden können soll.
Zugegeben, ich möchte mich auch nicht immer der Masse anpassen, so auch was den Bootloader betrifft.
Daher mein Tipp: Bastel dir erst mal einen, der nur dein OS lädt, ob nun in deinem eigenen FS oder bspw. FAT(16/32).
-
Wenn man den Bootloader als eigenes Projekt angeht, wie das matheguru ja jetzt wohl vorhat, ist das in Ordnung. Dann bestehen auch Chancen, daß der Bootloader nicht als lästiges Beiwerk abgehandelt wird, das so schnell wie möglich irgendwie was machen muß, sondern wirklich was brauchbares rauskommt.
Es wäre vielleicht eine gute Idee, den Multiboot-Standard zu unterstützen, damit kann man schonmal eine ganze Menge Systeme booten.
ScollPi, dein Vorschlag, einen Minimalbootloader zu basteln, der grad mal irgendwie das eigene OS im Moment grad von der Floppy laden kann, ist Unsinn. So ein Ding wird dich ewig behindern, weil du es nicht weiter ausbauen willst (er paßt dann ja nicht mehr in 512 Byte und wird daher etwas komplexer, also ist der Aufwand zu groß) und anfängst, deinen Kernel an den Einschränkungen deines Bootloaders auszurichten.
-
Jedenfalls bin ich ne weile bescchäftigt und habe den Vorteil das ich mich nicht mit linzensen herumschlagen muss, falls es jemals so weit kommt das es zum download bereitsteht, mein H4x0rOS. Das es eine multiboot dingens struktur gibt, wie auch immer, wusste ich gar nicht gleich mal googlen. Vieleicht auch ein paar anregungen von euch. ScollPI einen einfachen bootloader der aus dem zweiten Cluster (immer der zweite Cluser) eine fat32 partition mein Kernel provisorisch lädt hatte ich auch schon, aber jetzt bin ich ja nicht mehr weitergekommen damit!
-
[...} habe den Vorteil das ich mich nicht mit linzensen herumschlagen muss, falls es jemals so weit kommt das es zum download bereitsteht, mein H4x0rOS.
Mit grub hast du da keine Probleme. :wink:
-
Wo ist das Kernproblem bei einem eigenen Tiny Bootloader? Man lädt Code als asm-Kernel nach, schaltet um nach PM und springt in den C-kernel. Wenn der Kernel wächst, muss man allerdings die nachzuladenden Sektoren erhöhen. Wo ist die wesentliche Beschränkung?
-
Man kann nur von Floppy, nur von FAT (wenn überhaupt, bei den meisten einfachen Bootloadern darf man gar kein Dateisystem benutzen) und nur seinen eigenen Kernel booten.
Im Vergleich zu einem ordentlichen Bootloader, mit dem man mehr oder weniger alle installierten Systeme von Diskette, Platte und CD laden kann, wobei die zu ladenden Dateien (die natürlich nicht nur den Kernel, sondern vor allem bei Mikrokernelsystemen auch grundlegende Treiber, z.B. für Festplatte umfassen) nicht in bestimmten Sektoren liegen müssen, sondern beim Booten über die verschiedenen unterstützten Dateisysteme geladen werden können, sieht dieser Mini-Bootloader verdammt schlecht aus. Und sein OS an einem verdammt schlechten Stück Software auszurichten, das zufällig vorher läuft, ist keine gute Idee.
Wird der Unterschied deutlich? ;)
-
Ja, das wird klarer, da werde ich mich wohl oder übel auch mal mit GRUB beschäftigen müssen, obwohl mir das gegen den Strich geht. Unter Linux ist man ja den GRUB gewohnt, Windows-User kennen dies nicht. Das ist wohl der wesentliche Grund, warum man unter Windows lieber mit einem eigenen Tiny Bootloader beginnt. :-)
-
Es ist ja nicht so, daß unter Linux GRUB schon immer existiert hätte. Früher war Lilo der unangefochtene Standard für Linux, und Lilo hatte so manche Eigenschaft mit diesen Mini-Bootloadern gemeinsam. Heute gibt es GRUB und Lilo ist tot. Zurecht. Und obwohl GRUB ja eigentlich ursprünglich der Bootloader für Hurd war, nicht der für Linux.
-
... Unter Linux ist man ja den GRUB gewohnt, Windows-User kennen dies nicht. Das ist wohl der wesentliche Grund, warum man unter Windows lieber mit einem eigenen Tiny Bootloader beginnt. :-)
Ironie oder Schicksal ... klar bin ich Windows-User, nur sehe ich mich nicht benachteiligt.
Mein Bootloader ist quasi ein "Tiny Bootloader", Bootmanager-Funktionen benötige ich für mein OS nicht, da mein OS als Netzwerk-OS im Dauereinsatz geplant ist und nicht ständig gebootet werden muss. Zudem ist mein Bootloader eher ein Hybrid, bestehen aus dem restlichen Bootcode der in die 512 Bytes nicht reingepasst hat, den PM-Einsprung und -Rücksprung, Legacy-Calls (überwiegend auf BIOS-Funktionen). Dazu reicht das und ich hab die Kontrolle. Hab ehrlich gesagt auch keine Lust mich mit Grub eventuell rumärgern zu müssen.
Ach was reg ich mich auf ... *prost* :-D
-
Tja es scheint wohl noch mehr Leute zu geben die Grub nich verwenden wollen und eher iren eigenen bootloader programmieren möchten! Ich mach es auf jedenfall so und mein Bootmanager hat auch schon einen Namen Haboma ( bedeutet: H4x0rOS Bootmanager ), nicht sehr fantasievoll aber ich mag den Namen. Na ja muss euch ja eh nicht interresieren. ich finde es ist besser ein eig. bootloader zuschreiben, denn die erfahrung hilft beim kernel ja auch weiter und wenn jemand einen vernünftigen kernel schreiben kann, dann kann er auch einen bootloader schreiben der mit grub mithalten kann.
-
Ganz ehrlich: Bootloader und Kernel sind zwei wirklich verschiedene Baustellen. Viel mehr als eine Lowlevel-Denkweise (sofern nicht sowieso schon vorhanden) wirst du für den Kernel nicht mitnehmen können - es sei denn, dein Bootloader ist in Wirklichkeit schon ein Kernel, natürlich. Das ist kein gutes Argument dafür, selben einen Bootloader zu schreiben.
Aber das macht es natürlich nicht schlechter, einen guten Bootloader zu schreiben. Das ist auch ein spannendes Projekt. Aber dann muß man eben mehr reinstecken als die anderthalb Tage, um zwei rohe Sektoren von der Floppy zu kratzen. Dann ist der Bootloader das Projekt und nicht das OS.
-
...
Aber das macht es natürlich nicht schlechter, einen guten Bootloader zu schreiben. ... Aber dann muß man eben mehr reinstecken als die anderthalb Tage, um zwei rohe Sektoren von der Floppy zu kratzen. Dann ist der Bootloader das Projekt und nicht das OS.
Bisher kenne ich nur "Your own tiny bootloader" oder "we use GRUB". Wo ist ein Ansatz für die Personen, die beide Varianten nicht überzeugend finden? Hast Du hierzu einen Link?
-
Nein, Tutorials speziell für größere Bootloader kenne ich nicht. Ist irgendwie kein so beliebtes Thema. Das heißt, ein Stück weit bist du auf dich gestellt, aber grundsätzlich kannst du vom Aufbau her vieles mit einem monolithischen OS-Kernel teilen. Du brauchst Plattentreiber (wobei man da evtl. das BIOS hernimmt), Dateisystemtreiber, Tastaturtreiber, wahrscheinlich zumindest eine einfache Form von Speicherverwaltung... Prozeßverwaltung und Multitasking wirst du in einem Bootloader natürlich nicht haben.
-
Ich hab da noch eine Frage also im Moment mache ich es so das der erste teil in den 512Byte bei der Partitionstabelle liegt, den Rest aus den folgenden Sektoren lädt. Dieser Teil schaltet in den PM und springt dann in den C-Teil, indem dann Treiber und so reinkommt. Meine Frage solle ich lieber kurz vor dem laden des OS`s in den PM schalten, denn dann spart man sich mühevolle Arbeit an SATA-/ATA-Treiber etc. ?
-
Ich hab da noch eine Frage also im Moment mache ich es so das der erste teil in den 512Byte bei der Partitionstabelle liegt, den Rest aus den folgenden Sektoren lädt. Dieser Teil schaltet in den PM und springt dann in den C-Teil, indem dann Treiber und so reinkommt. Meine Frage solle ich lieber kurz vor dem laden des OS`s in den PM schalten, denn dann spart man sich mühevolle Arbeit an SATA-/ATA-Treiber etc. ?
Was genau meinst du mit Laden des OS? Nur den Kernel? Dann ist die Antwort natürlich nein, im Bootloader macht ein ATA-Treiber keinen Sinn/Spaß.
Falls du das Laden von Treibern oä. meinst, dann kommt es auf die Kernelart an:
* Wenn du einen Mikrokernel (oder einen modularisierten monolithischen Kernel) willst, dann sollten die Treiber bereits im RAM sein, sonst müsstest du ja deinen ATA-Treiber in den Kernel verfrachten, was du aber ja eben bei einem Microkernel nicht willst.
* Wenn du einen monolithischen Kernel würde ich zuerst in den Protected-Mode wechseln und dann zum Kernel springen, schon allein weil es quasi-unmöglich ist 16bit Code mit 32bit Code zu mischen.
Falls du das Laden von Shell, etc... meint, dann ist die Antwort wiederum nein, da du sowieso einen ATA-Treiber brauchst, sonst kannst du ja keine Anwendungen "nachladen" und ausführen.
-
Dann stelle ich die Frage noch einmal in korrektem klaren Deutsch aus, damit es nicht zu verwechslungen kommt. Also der erste Teil meines Bootmanagers HABOMA soll im MBR meiner Festplatte liegen, dieser überprüft eben ob überhaupt eine gültige Partitionstabelle vorhanden ist, falls ja werden die Sektoren direkt hinter dem MBR, indenen der Rest des Bootmanagers liegt, in den RAM geladen, an Adresse 0x10000 selbstverständlich! Von hier aus wollte ich eig. ersteinmal in den PM wechseln um den Betriebssystem hinterher Arbeit zu ersparen und weil GRUB das ja auch macht. Nun mein Problem oder Frage, wie man`s sieht! Wenn ich jetzt schon in den PM wechsle, bräuchte ich jetzt natürlich auch einen HD-Treiber oder ich müsste über den virtuellen x86 Mode auf die Interrupts zugreifen, wenn ich allerdings kurz vor dem laden des Kernels erst in den PM wechsle kann ich mir das mit dem HD-Treiber ja sparen! Wie macht das denn GRUB und liegen die Dateien von GRUB auch direkt hinter dem MBR, denn die alten Betriebssysteme lassen zwischen MBR und erster Partition doch etwas Platz? Und sagt mir bitte nicht: " Dann nimm doch gleich GRUB, wenn du wissen willst wie GRUB das macht". Ich nehme das ja nur als Vorlage um mir das besser vorzustellen. Gib mir am besten mal eine Liste mit Komponenten, die unbedingt drin sein müssen und was man brauch! Ich möchte euch Danken für die ganzen Antworten ich habe jetzt einiges in diesen 2 Wochen gelernt. Danke
-
Grub lädt den Kernel (und alle Module) bevor es in den Protected-Mode wechselt. Ich nehme an Grub2 wird das genauso machen, aber sicher bin ich mir nicht. Eine kurze Erklärung was die stages bei Grub tun gibts hier (http://www.gnu.org/software/grub/manual/grub.html#Bootstrap-tricks).
Gib mir am besten mal eine Liste mit Komponenten, die unbedingt drin sein müssen und was man brauch.
Der Bootloader sollte zusätzliche Module laden können für einen Mikrokernel. Er sollte ELF32/64 unterstützen und jeweils in den 32bit Protected-Mode bzw. den LongMode wechseln. Am besten sollte er Multiboot oder/und den Multiboot2 Vorschlag unterstützen. Unterstützung für mehrere Dateisysteme (FAT, ext2, ISO9660 mit El Torito, ...).
Gescheite Tools um das Ding auf Floppy/CD-ROM Images zu installieren.
-
Danke, dann können die Module aber doch nicht über die 1MB grenze geladen werden, oder nicht?
-
Doch, das auf jeden Fall, Grub lädt grundsätzlich nur über 1MB, sowohl Kernel als auch Module. Es könnte sein, dass Grub immer ein Stück liest, dann in Protected-Mode wechselt, das Stück kopiert und wieder zurück wechselt.
-
Ja, aber dann hätte man ja wiederrum das Problem mit den BIOS-Interrupts, die man höchstens noch im virtuellen x86 Mode nutzen könnte wie das Vesa-Interface im PM. Wie erklärst du dir das? Das ist kompliziert, entweder Treiber oder Vx86Mode oder nur 1MB speicher.
-
Es könnte sein, dass Grub immer ein Stück liest, dann in Protected-Mode wechselt, das Stück kopiert und wieder zurück wechselt.
Gemeint ist im Realmode mit BIOS-Interrupts lesen, im Protected-Mode kopieren, ohne Virtual-8086-Mode.
-
OK, das ist eine Lösung, also ein Platz im RAM freihalten, dort reinkopieren und dann wechseln, verschieben und zurückschalten!
-
Ja, soweit ich weiß, wechselt GRUB fröhlich hin und her. Für den Zugriff auf Platte/Diskette nimmt er auf jeden Fall das BIOS.
-
Ich habe mir gerade die Neuerungen in GRUB2 durchgelesen, stage1.5 wird rausgenommen und auch komprimierungsverfahren werden angewedet.
-
stage1.5 hat doch schon bisher niemand genutzt.
Meine persönliche Einschätzung zu GRUB 2: Das wird der emacs unter den Bootloadern. Wird vermutlich ein ganz passables Betriebssystem, aber booten kann man damit halt leider nicht vernünftig. Ob sie wenigstens das mit dem Editor besser hinbekommen, wird man noch sehen. ;)
-
Sry das ich den Thrad noch mal hochhole, aber ich muss jetzt echt zugeben, nachdem ich recherchiert habe und angefangen habe einen eigenen bootmanager zu schreiben, dass GRUB geil ist, der hat so viele funktionen und bietet alles was man brauch und eignet sich wirklich optimal für ein eigenes OS! An alle die genauso gedacht haben wie ich am anfang, nämlich das GRUB doof ist :-D, seht ja selbst ich war auch hartnäckig in diese Meinung versetzt, aber GRUB ist dann doch sehr brauchbar :-)
-
Was sind die drei wichtigsten Vorteile, die dich zu deiner Meinungsaenderung bewogen haben? Das interessiert mich, weil ich im dritten Teil meines OS-Tut ebenfalls GRUB (unter Windows) einsetzen will.
-
Also als erstes wollte ich ja nur einen tinybootloader, der mein kernel lädt, das konnte ich aber schnell knicken, da ich mein kernel immer von eineer fat32 partition lade und der Treiber müsste erst mal nachgeladen werden! Dann dachte ich mir es ist doch bestimmt nicht schwer, so ein treiber einzuarbeiten, dann kam mir die überlegen, dass es ja hinterher mehr fs unterstützen muss! Ich kan zu dem schluss das ich nen eigenen bootmanager schreiben wollte, was allerdings auch nen reinfall war, weil als ich mich näher mit dem thema beschäftigt habe, ist mir aufgefallen das grub alles bietet was man sich nur wünschen kann! Man kann mehrere Module mitladen, man kann eine INITRAMDISK laden, er schaltet direkt in den protected mode, er ist leicht zu konfigurieren und er unterstützt multiboot strukturen! GRÜSE Paul
-
GRUB ist bei Linux ja schon dabei. Wie sieht das bei Windows aus? Kann es da Stoerungen geben zwischen dem ExperimentalOS und Windows? Man moechte sich ja nicht seinen Lieblingsrechner zerschiessen?
-
Wenn du grub in den MBR installierst eigentlich nicht. Du musst dann nur einen Eintrag für Windows machen, der den Bootsektor der WIndowspartition lädt (chainloading).
-
richtig, da Windows kein Multiboot unterstützt xD, deswegen chainloding! Und bisher hatte ich nie probleme mit Windows! Ich habe ein system mit XP, MS-DOS 6.22 und Ubuntu 9.4 funtz prima! Und Grub wurde von Ubunutu standartmäsig in den MBR installiert!
-
Ich wuerde meinen Haupt-Rechner mit Win XP nur ungern in einen Multi-Boot-PC verwandeln, aber ich habe genuegend Neben-Rechner auch bereits mit GRUB, Windows und einer Linux-Version (die hat Grub installiert). Da zieht man dann einfach noch ein MeinLustigesOS drauf. :-)
-
Ich wünschte ich hätte eine Rechnerwahl! Naja warum willste dein Hauptrechner nicht umrüsten? Also wenn du abstürtze erwartest oder denkst du könntest hinterher doch nicht mehr booten, muss ich dir sagen, dass das eig. nich passiert! Hauptsache bei mir läufts supi :-D
-
Ich wünschte ich hätte eine Rechnerwahl! Naja warum willste dein Hauptrechner nicht umrüsten? Also wenn du abstürtze erwartest oder denkst du könntest hinterher doch nicht mehr booten, muss ich dir sagen, dass das eig. nich passiert! Hauptsache bei mir läufts supi :-D
Von seiten GRUB gibt es da sicherlich keine Probleme. Aber ob du DeinOS auf den Hauptrechner lädst, hängt natürlich daran wie viel vertauen du in dein eigenes OS steckst.
-
Ja wo de recht hast du nun mal recht! Aber ich muss das Risiko wohl eingehen! Ich kann mir zwar vorstellen wie man den rechner mit nem ownOS schrotten kann, aber welche genauen Fälle können da auftreten?
-
Bug im Dateisystemtreiber, Zugriff auf deine Linux/Windows-Partition - rumms. ;)
-
Naja, eigentlich nicht viel. Ich denke jeder hier testet sein OS zumindest von Floppy aus auf dem eigenen PC. Wenn du einen Festplattentreiber hast, kann es natürlich passieren, dass du das falsche überschreibst (bei floppy ist das wohl weniger tragisch).
Ansonsten kann man im Prinzip nicht viel (mehr) kaputtmachen. Ich hab nur mal gehört, dass man wenn man versucht bei alten Röhrenmonitoren den Modus zu wechseln und das falsch macht, dass man den Monitor wirklich schrotten kann.
-
Ich glaub ich habe mal was von gelesen in der intel specification von meiner intel graka, man kann wohl wenn man an die falschen I-/O-Ports falsche sachen sendet, die grafikkarte so, im prinzip, umprogrammieren, dass sie nicht mehr optimal läuft, gleiches gillt auch für andere grakas! Kennt ja jeder die progs, wo man eine Nvidiakarte noch etwas übertakten kann! Ja, ihr glücklichen ich besitze so etwas wie ein Floppylaufwerk nicht! :-D
-
Ja, ihr glücklichen ich besitze so etwas wie ein Floppylaufwerk nicht!
Festplatte auf meinem Hauptrechner ist tabu. :wink:
Floppy oder USB, alles andere ist nicht sicher. Aber natuerlich eine Frage der Datensicherung. :-D