Hallo, Am 01.05.2015 um 15:34 schrieb Bernhard Schmidt:

Am 01.05.2015 14:44, schrieb Juergen Langowski:

...

Am Fri, 01 May 2015 14:24:55 +0200 schrieb Bernhard Schmidt:

...

Hallo Leute, nach einem totalcras auf meinem Rechner muß ich neu installiern. Alt war win 7 und suse 13.1 drauf. Die DVD für suse 13.2 liegt schon länger bei mir rum und ist schon auf einem älteren Dell mit P4/64bit installiert worden. jetzt ist der Hauptrechner dran und will nicht so richtig. Die Installation hat funktioniert, bietet aber nur 14 GB für den Basisordner an, home ist 250 GB groß. Mir ist dieser Basisordner jedenfalls zu klein, nachdem etwas Software installiert war blieben nur 3 GB übrig.

Wenn man so richtig viel SW installieren will, sind 14 GB zu wenig.

...

...

Was kann man tun bzw. ist falsch gelaufen

Hast Du Win nach oS installiert. In dem Fall könnte Dein Bootloader von Win überschrieben worden sein. Dann Win besser zuerst installieren, weil oS auf Win Rücksicht nimmt, was umgekehrt für Win leider nicht gilt.

...

...

Gruß Bernd

Hallo Bernd,

das kommt u.a. darauf an, wie die Partitionen physikalisch angeordnet sind.

Im Prinzip und ganz theoretisch geht es so: / löschen, von /home entsprechend viel Platz abzwacken und / etwas größer wieder anlegen.

Abzwacken? Meinst Du "verkleinern"? Dann würde ich doch lieber auch /home neu anlegen, falls keine Daten drauf sind. Falls doch, dann vorher ein Backup machen und danach wieder zurücksichern.

...

Falls eine win-Partition im Weg ist oder die 14GB-Partition aus anderen Gründen nicht gelöscht werden kann, könntest du z.B. ebenfalls /home verkleinern, / im freien Bereich neu anlegen und die alte 14GB-Partition z.B. als /srv oder /var in die neue / einbinden.

Da sieht man, wie unflexibel die Sache mit den Dateisystemen direkt auf den Partitionen ist. Bei Platznot kann man zwar Verzeichnisse auf neue Datenträger auslagern und mit einem Symlink auf den Mountpoint wieder anbinden, aber das gibt mit der Zeit und bei mehreren Erweiterungen bzw. zusätzlichen SW-Installationen eine ziemlich unübersichtliche Gesamtsituation. Da wäre eine Überlegung in Richtung LVM vielleicht sinnvoll. Mit LVM kann man durch nachträgliches Vergrößern der Logical Volumes (das sind dann statt der bisherigen Partitionen die logischen Geräte, die unter /, /var, ... gemountet werden) und der darauf befindlichen Dateisysteme mehr Platz schaffen, ohne dem Pfad nach zusammengehörige Daten über mehrere Dateisysteme zu verteilen. Dann braucht es auch keine zusätzlichen Mountpoints und keine darauf zeigenden Symlinks. Damit wächst auch kein Mount- und Link-Baum mehr (Anzeige von df bleibt übersichtlich). Weiterer Vorteil: es wird nicht unnötig Platz verschwendet, weil man weitere Physical Volumes nach Bedarf in die Volume Groups aufnehmen kann. Dateisystem-Images, z.B. vor kritischen System-Updates kann man auch einfacher machen. LVM bietet auch Snapshots an, die man nach einem fehlgeschlagenen System-Update wieder einspielen kann.

Hallo Jürgen,

habe inzwichen folgendes gemacht: alle nicht benötigten Patitionen gelöscht, die 14 GB auch. SDA besteht jetzt aus MBR, 14 GB, 460 GB Win7, 480 GB / SDB 2 * Daten zu 490 GB SDC1 350 GB /home

Wofür brauchst du denn jetzt die 14-GB-Partition noch? Mit 480 GB für / verschwendest Du aber richtig Platz. Wenn man so richtig viel von der Distri installieren will, braucht man meiner Erfahrung nach ca. 30 - 50 GB, je nachdem, ob du auch die Quellen haben willst oder nicht. Von einer Aufnahme von Nutzdaten in das Root-Dateisystem, falls du das zusätzlich zu Deinen anderen Platten (/dev/sdb und /dev/sdc) vorhast, würde ich abraten, weil es m.E. sicherer ist, wenn auf das Root-Dateisystem möglichst nur geschrieben wird, wenn Software installiert werden soll. Deswegen mounte ich unter /root (Heimatverzeichnis des SUs), /var und /tmp eigene Dateisysteme, weil darauf öfter geschrieben wird als auf / und /usr (trennt man diese auch noch, dass wird oft nur auf /usr geschrieben; bei eigenem FS für /boot muss man dies nur mounten, wenn ein neuer Kernel installiert werden soll). Die selten beschriebenen Dateisysteme können dann auch seltener überprüft werden als die häufig beschriebenen. Systemstarts mit Überprüfung von nicht allen und kleineren Dateisystemen laufen dann auch schneller ab, als wenn alle gleichzeitig oder ein riesiges Root-FS geprüft wird.

so hat die Installation funktioniert nur GRUB2 hat gemeckert, wußte nicht wohin.

Habe mich für MBR entschieden, war leider falsch. nach dem

Was war denn daran falsch? Nach welcher Methode startet Dein Rechner: Bootloader im EFI oder im MBR? Wenn EFI, dann wäre GRUB im MBR sinnlos. Dann bräuchtest Du eine EFI-Partition von ca. 100 - 200 MB mit einem vfat-Dateisystem. Dort müsstest Du dann den GRUB installieren. oS bemerkt bei der Installation die Existenz dieser Partition bzw. legt sie an und macht dann das Richtige, wenn es im EFI-Modus gestartet wurde. GRUB bräuchte dann prinzipiell keine Auswahl von Windows o.a. Systemen mehr anbieten (macht aber auch nichts; dann hat man halt zweimal nacheinander die Möglichkeit, Win zu wählen), weil es das EFI schon anbietet. Vorteil von EFI: eine spätere Windows-Installation überschreibt Dir Deinen Bootloader im MBR nicht mehr, weil jeder Bootloader in der EFI-Partition ein eigenes Verzeichnis hat. Falls MBR, kommt es noch darauf an, welche Art der Partitionierung gewählt wurde: GPT oder die klassische mit MBR: primäre Partitionen und logische Partitionen in einer erweiterten Partition. Bei GPT _sollte_ eine ca. 1 MB große Partition mit dem Label "bios_grub" angelegt werden (Empfehlung GRUB-Handbuch), wo der GRUB-Hauptteil installiert wird, weil im MBR bekanntlich der Platz nicht reicht. Allerdings würde bei Dir die klassische Partitionierung ausreichen, da Deine Disks/SSDs < 2 TB zu fassen scheinen. Bei mehr als 2 TB müsstest Du eine GPT verwenden.

Rechnerneustart kam nur die Textzeile GRUB und sonst nichts mehr.

Wenn Dein Rechner nach der klassischen BIOS-MBR-Methode startet, dann könnte das die GRUB-Shell (grub> ) gewesen sein, weil der GRUB-Teil im MBR vielleicht die Partition mit dem Verzeichnis /boot mit den höheren GRUB-Stages nicht gefunden hat. Dann hättest Du grub> set root=(hd0,3) (Part., wo Kernel und Initrd liegen) grub> linux /vmlinuz root=/dev/sda3 grub> initrd /initrd grub> boot (jeweils Eingabevervollständigung für Kommandos und Pfade nutzen!) eingeben können ("hd0" für /dev/sda und "3" für die dritte Partition, wenn ich richtig gezählt habe; und ja, die Partitionen werden ab "1" gezählt, die Platten dagegen ab "0"! Bei GRUB 0.97 war es noch konsistent, beide ab der "0".) GRUB findet mit diesen Angaben den Kernel und die Initrd, wenn sie sich entweder in /boot auf einer eigenen Partition oder direkt in / befinden, die vor dem Start des Kernel noch nicht gemountet sind. Sollten sie woanders liegen, was ungewöhnlich wäre, muss der Pfad exakt angegeben werden. Nach dem erfolgreichem Start hättest Du z.B. mit YaST den Bootloader reparieren bzw. korrekt installieren können.

Inzwichen mache ich den dritten Installationsversuch für die 13.2 und der vorschlag von Suse gefällt mir wesentlich besser. alles auf SDC.

Bei mehreren Disks/SSDs würde ich Win bzw. oS auch lieber auf einer eigenen haben wollen. Dann ist ein späterer Umzug in einen anderen Rechner einfacher, sowohl von Win als auch von oS. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org