Oelle82
(Themenstarter)
Anmeldungsdatum: 19. August 2012
Beiträge: 202
|
MannMitHut schrieb: Oelle82 schrieb: MannMitHut schrieb: Seitab: Reparatur bisheriges 12.04
Damit es vernünftig und mit vertretbarem Aufwand weiter geht: Du hast momentan auf einer Deiner HDDs – bei abgesteckter SSD – ein lauffähiges Ubuntu 16.04, ja? Von dort aus kommst Du an Deine Daten, welche intakt sind, sagst Du? Könntest Du als Interimslösung damit arbeiten, sodass wir uns ein Gebastel am alten 12.04 sparen können? (Bitte weiter nicht die bisherige /home in ein anderes System einhängen!)
Das hast du alles richtig verstanden!
Ich könnte jetzt damit arbeiten und mache ich notgedrungen auch.
Der Hauptgrund weswegen ich das 12.04 noch starten wollte war auch von dort noch diverse Einstellungen, Layouts und ähnliches zu übernehmen. Und nicht zuletzt eine alte POP3 Mailbox die ich vergessen hatte zu sichern.
Die meisten Daten sind ohnehin gesichert, aber nicht alle. Ich habe dafür auch gerade keine USB-Platte mit entsprechendem Dateisystem, werde aber sowas wie Dokumente ect. vor der nächsten Aktion noch auf die normale USB-Platte ziehen. Ich habe eben nochmal eine Idee verfolgt und die UUID im 12.04 geprüft. Wie du schon vermutet hast, habe ich /home nachträglich geändert. Ich dachte vielleicht hat sich die UUID geändert und er findet es deswegen nicht. Das hätte auch schön ins Bild mit der grub-Fehlermeldung gepaßt. War aber leider nix, UUID war korrekt. Hast du noch weitere Ideen/Vorschläge zum eigentlichen Problem?
|
MannMitHut
Anmeldungsdatum: 22. Juni 2010
Beiträge: 806
|
Oelle82 schrieb: MannMitHut schrieb: Oelle82 schrieb: MannMitHut schrieb: Seitab: Reparatur bisheriges 12.04
Damit es vernünftig und mit vertretbarem Aufwand weiter geht: Du hast momentan auf einer Deiner HDDs – bei abgesteckter SSD – ein lauffähiges Ubuntu 16.04, ja? Von dort aus kommst Du an Deine Daten, welche intakt sind, sagst Du? Könntest Du als Interimslösung damit arbeiten, sodass wir uns ein Gebastel am alten 12.04 sparen können? (Bitte weiter nicht die bisherige /home in ein anderes System einhängen!)
Das hast du alles richtig verstanden!
Ich könnte jetzt damit arbeiten und mache ich notgedrungen auch.
Gut, dann fahren wir damit. Und …
Der Hauptgrund weswegen ich das 12.04 noch starten wollte war auch von dort noch diverse Einstellungen, Layouts und ähnliches zu übernehmen. Und nicht zuletzt eine alte POP3 Mailbox die ich vergessen hatte zu sichern.
Die meisten Daten sind ohnehin gesichert, aber nicht alle. Ich habe dafür auch gerade keine USB-Platte mit entsprechendem Dateisystem, werde aber sowas wie Dokumente ect. vor der nächsten Aktion noch auf die normale USB-Platte ziehen.
… mach doch eine Sicherung Deines alten /home bzw. Nutzerverzeichnisses (/home/Oelle82 o.ä.) mit tar. Ich lese heraus, auf Deiner externen HDD ist eine einzige Partition im NTFS-Format. Richtigerweise stellst Du fest, dass bei der 1:1-Dateisicherung da hin die für /home lebenswichtigen Rechte bzw. Besitzereinstellungen der Dateien verloren gingen. Gepackt in ein tar-Archiv bleiben sie erhalten. Mach das, die Wiederherstellung können wir später noch ansehen. Du kannst das gut von Deinem Interims-16.04 machen. Willst Du das ganze /home sichern, brauchst Du Rootrechte.
Ich habe eben nochmal eine Idee verfolgt und die UUID im 12.04 geprüft. Wie du schon vermutet hast, habe ich /home nachträglich geändert. Ich dachte vielleicht hat sich die UUID geändert und er findet es deswegen nicht. Das hätte auch schön ins Bild mit der grub-Fehlermeldung gepaßt. War aber leider nix, UUID war korrekt.
Wahrscheinlich hast Du’s zwischenzeitlich doch mal in eins der 16.04er eingehängt … 16.04 ist dann, wenig überraschend (da ja Versionsupgrades möglich sind), abwärtskompatibel; 12.04 ist aber nicht aufwärtskompatibel – wie auch. Da liegt wahrscheinlich der Hase im Pfeffer. Eingehängt ins 16.04 macht dieses nämlich seine Änderungen, bringt die Einstellungen in zwischenzeitlich erneuerte Formate. Ich warne ja immer, eine extra /home-Partition einfach so von einem System in ein anderes zu stöpseln, ohne Vorsicht und Vorkehrungen. Insofern sehe ich eben auch die Vorteile eines separeten /home im Hausgebrauch als sehr relativ. Unter den /home-Chefideologen hier bin ich dafür als schrulliger Warndreieckausrichter verschrien … 😈
Hast du noch weitere Ideen/Vorschläge zum eigentlichen Problem?
Schauen wir … kommt gleich …
|
MannMitHut
Anmeldungsdatum: 22. Juni 2010
Beiträge: 806
|
Und damit zurück zur eigentlichen Sch… Oelle82 schrieb: MannMitHut schrieb:
Das hier:
Oelle82 schrieb: Nur SSD, HDDs abgesteckt: SSD per Lice-CD mit GParted leer gemacht, Installation gestartet, etwas anderes gewählt und grub auf sda5 versteckt. Ergebnis: Boot disk failure. Insert System Disk and press Enter Passiert auch bei Standart-Installation.
nur die SSD angeschlossen, keine der HDDs angeschlossen im BIOS kontrollieren, dass die SSD oben steht Ubuntu Standard-Installation auf die SSD (automatisch, "Festplatte löschen und Ubuntu installieren" – kein Versenken von GRUB auf /dev/sda1 o.ä.!) Reboot – was passiert?
Genau das habe ich gemacht -siehe oben!
Also – damit kein Missverständnis bleibt: Es ist nur die SSD im System (nicht die HDDs) und nach einer durchgeführten Standard-Installation gehst Du davon aus, dass sich GRUB im MBR (nicht versenkt in einem Partitions-Boot-Record) befindet. Bitte bestätigen. Um einmal die einfachsten Abklärungen zu machen: In genau (!!) diesem Installationszustand (nur SSD im System, keine HDDs – frische automatische Standard-Installation mit "Festplatte löschen und Ubuntu installieren" auf der SSD) bitte mal ein Live-System starten und …
sudo parted -l
sudo fdisk -l /dev/sda # wenn die SSD /dev/sda ist! – müsste aber …
mal ganz plump im Dateimanager (Nautilus) die Systempartition auf der SSD öffnen (links unter Geräte müsste sie sein) und sehen, ob da der typische Linux-Verzeichnisbaum ist mal versuchen, irgendwo (an unkritischer Stelle, evtl. Testverzeichnis anlegen) auf dieser Partition ein paar Dateien hin und zurück zu schieben, einfach testweise. nächster Schritt: GRUB-Umgebung analysieren – vorher bzw. im Zuge dessen würde ich aber …
… mal probieren, ob Du das Ubuntu auf der SSD mit der Super-GRUB2-Disk gestartet bekommst. Ansonsten muss ich Dich auf meinen bereits vorgeschlagenen Schlachtplan verweisen, den Du bis auf Punkt 1 wohl noch nicht abgearbeitet hast. Auch die dazu vorgeschlagene Abkürzung könntest Du vorziehen: MannMitHut schrieb: […] Ubuntu auf die SSD installieren, aber den Bootloader auf die HDD installieren lassen, von der der Rechner dann bootet. […]
In diesem Fall bitte gleich bei der Installation auf die SSD auch die HDD(s) im System am Laufen haben. Ach, noch was: Oelle82 schrieb: Bitte immer Strom- und Datenkabel abziehen, um
Beschädigungen zu vermeiden eine Fehlerquelle auszuschließen
Man weiß nie …
|
Oelle82
(Themenstarter)
Anmeldungsdatum: 19. August 2012
Beiträge: 202
|
MannMitHut schrieb: Und damit zurück zur eigentlichen Sch… Also – damit kein Missverständnis bleibt: Es ist nur die SSD im System (nicht die HDDs) und nach einer durchgeführten Standard-Installation gehst Du davon aus, dass sich GRUB im MBR (nicht versenkt in einem Partitions-Boot-Record) befindet. Bitte bestätigen.
Ist hiermit bestätigt. Habe die Installation eben nochmal laufen lassen und konkret gesehen das kurz die Meldung "Installiere grub auf /dev/sda" erschien.
Um einmal die einfachsten Abklärungen zu machen: In genau (!!) diesem Installationszustand (nur SSD im System, keine HDDs – frische automatische Standard-Installation mit "Festplatte löschen und Ubuntu installieren" auf der SSD) bitte mal ein Live-System starten und …
sudo parted -l
sudo fdisk -l /dev/sda # wenn die SSD /dev/sda ist! – müsste aber …
ubuntu@ubuntu:~$ sudo parted -l
Modell: ATA Kingston SHPM228 (scsi)
Festplatte /dev/sda: 240GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: msdos
Disk-Flags:
Nummer Anfang Ende Größe Typ Dateisystem Flags
1 1049kB 234GB 234GB primary ext4 boot
2 234GB 240GB 5900MB extended
5 234GB 240GB 5900MB logical linux-swap(v1)
Modell: PLEXTOR DVDR PX-891SA (scsi)
Festplatte /dev/sr0: 4700MB
Sektorgröße (logisch/physisch): 2048B/2048B
Partitionstabelle: mac
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
1 2048B 6143B 4096B Apple
2 1479MB 1481MB 2425kB EFI
ubuntu@ubuntu:~$ sudo fdisk -l /dev/sda
Medium /dev/sda: 223,6 GiB, 240057409536 Bytes, 468862128 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: dos
Medienkennung: 0xaff02129
Gerät Boot Start Ende Sektoren Größe Id Typ
/dev/sda1 * 2048 457334783 457332736 218,1G 83 Linux
/dev/sda2 457336830 468860927 11524098 5,5G 5 Erweiterte
/dev/sda5 457336832 468860927 11524096 5,5G 82 Linux Swap / Solaris
Die Partition 2 beginnt nicht im Bereich der physischen Sektoren.
ubuntu@ubuntu:~$
Alles da → Screenshot
mal versuchen, irgendwo (an unkritischer Stelle, evtl. Testverzeichnis anlegen) auf dieser Partition ein paar Dateien hin und zurück zu schieben, einfach testweise.
Geht! → Screenshot
Im Anhang ist die Auswertung von dem extrem coolen Script!
… mal probieren, ob Du das Ubuntu auf der SSD mit der Super-GRUB2-Disk gestartet bekommst.
Mache ich jetzt, wollte das obige nur kurz posten da ich im Live-System bin und die Infos sonst gleich beim Neustart weg wären... Ach, noch was: Oelle82 schrieb: Bitte immer Strom- und Datenkabel abziehen, um
Beschädigungen zu vermeiden eine Fehlerquelle auszuschließen
Man weiß nie …
Ok, beachte ich!
- RESULTS.txt (12.1 KiB)
- Download RESULTS.txt
- Bilder
|
Oelle82
(Themenstarter)
Anmeldungsdatum: 19. August 2012
Beiträge: 202
|
MannMitHut schrieb: … mal probieren, ob Du das Ubuntu auf der SSD mit der Super-GRUB2-Disk gestartet bekommst.
Nö, geht nicht → Anhänge!
Auch die dazu vorgeschlagene Abkürzung könntest Du vorziehen: MannMitHut schrieb: […] Ubuntu auf die SSD installieren, aber den Bootloader auf die HDD installieren lassen, von der der Rechner dann bootet. […]
In diesem Fall bitte gleich bei der Installation auf die SSD auch die HDD(s) im System am Laufen haben.
Das hatte ich auch schon. So habe ich das ganze ja ursprungs angegangen. Ich hatte den PC so gelassen wie er war und nur die SSD DAZU gesteckt. Dann standartinstallation mit der Option Parallel-Installation. Ergebnis ist dann grub rescue.
Können wir aber gerne nochmal testen, wenn dir die obigen Infos keine neuen Erkenntnisse bringen!
- Bilder
|
MannMitHut
Anmeldungsdatum: 22. Juni 2010
Beiträge: 806
|
Ok. Aus all dem lässt sich m.E. folgern: Die SSD ist nicht direkt startbar, ein GRUB in ihrem MBR nützt uns nichts. Die SSD setzt sich aus Sicht des BIOS von der Nummerierung offensichtlich an die erste Stelle (obwohl gar nicht startbar!). (Für Linux ist sie gleichwohl /dev/sdc, wenn die beiden anderen HDDs am System sind – das ist aber nicht das eigentliche Problem.)
Diese Konstallation macht Dir die Schwierigkeiten. Die SSD kann nicht Bootlaufwerk sein, in der folglich auf einer der HDDs eingerichtete GRUB muss mit den richtigen Laufwerkskennungen eingerichtet sein. Schaffe bitte einmal Klarheit bzgl. der Laufwerksbezeichnungen aus Sicht von GRUB mittels grub-mkdevicemap. Im Prinzip wittere ich die Lösung (zu Fuß beschritten) hier: Linux starten aus der GRUB2-Shell. Oelle82 schrieb: MannMitHut schrieb: […] Ubuntu auf die SSD installieren, aber den Bootloader auf die HDD installieren lassen, von der der Rechner dann bootet. […]
In diesem Fall bitte gleich bei der Installation auf die SSD auch die HDD(s) im System am Laufen haben.
Das hatte ich auch schon. So habe ich das ganze ja ursprungs angegangen. Ich hatte den PC so gelassen wie er war und nur die SSD DAZU gesteckt. Dann standartinstallation mit der Option Parallel-Installation. Ergebnis ist dann grub rescue.
Können wir aber gerne nochmal testen, wenn dir die obigen Infos keine neuen Erkenntnisse bringen!
Das tönt wieder nicht nach dem, wie es sein sollte … ich mag mich gern täuschen. Vielleicht probierst Du’s erst nochmal auf dem Weg. Bitte exakt dies ausführen:
SSD und HDDs sind von Anfang an im System. Die HDD, von der das System ohne SSD erfolgreich startet, bleibt im BIOS das Bootlaufwerk. (Verifizieren!) Start von Live-CD mit dem zu installierenden Ubuntu. "Ubuntu ausprobieren" (Sprache Deutsch). Lt. Deinen Terminalangaben setze ich im Folgenden voraus, dass die SSD /dev/sdc und die bisherige Start-HDD /dev/sda sein werden – verifiziere es jetzt nochmals! (sudo parted --list oder Tool Laufwerke) gparted: SSD komplett löschen (neue Partitionstabelle) und darauf ext4-Partition anlegen fürs gleich zu installierende System. (keine /home oder dgl.! Swap müsste sowieso eine da sein … erst mal alles Wuscht!) Ubuntu-Installer starten und keine automatische Parallelinstallation sondern ▶ hier (Links folgen – gute Anleitung!) "Etwas Anderes" wählen. Die eben frisch angelegte Partition (wohl /dev/sdc1) ▶ hier als / (Wurzelverzeichnis) einbinden. Als "Gerät für die Bootloader-Installation" nicht die SSD, also nicht /dev/sdc auswählen (!!) sondern die bisherige Boot-HDD /dev/sda. (Zugleich nicht etwa eine Partition auswählen, also nicht etwas dort mit angehängter Ziffer.) Installation laufen lassen, Neustart.
|
Oelle82
(Themenstarter)
Anmeldungsdatum: 19. August 2012
Beiträge: 202
|
MannMitHut schrieb:
Die SSD ist nicht direkt startbar, ein GRUB in ihrem MBR nützt uns nichts.
Das ist mal schade für eine SSD!
Schaffe bitte einmal Klarheit bzgl. der Laufwerksbezeichnungen aus Sicht von GRUB mittels grub-mkdevicemap.
ubuntu@ubuntu:~$ grub-mkdevicemap
grub-mkdevicemap: Fehler: /boot/grub/device.map kann nicht geöffnet werden.
ubuntu@ubuntu:~$ grub-mkdevicemap --device-map=device Leider ist die dann erzeugte Datei leer.
Habe nur die SSD drin und von DVD gebootet und dann die Befehle eingegeben. Oder meintest du von den HDDs booten?
Das tönt wieder nicht nach dem, wie es sein sollte … ich mag mich gern täuschen. Vielleicht probierst Du’s erst nochmal auf dem Weg. Bitte exakt dies ausführen:
SSD und HDDs sind von Anfang an im System. Die HDD, von der das System ohne SSD erfolgreich startet, bleibt im BIOS das Bootlaufwerk. (Verifizieren!) Start von Live-CD mit dem zu installierenden Ubuntu. "Ubuntu ausprobieren" (Sprache Deutsch). Lt. Deinen Terminalangaben setze ich im Folgenden voraus, dass die SSD /dev/sdc und die bisherige Start-HDD /dev/sda sein werden – verifiziere es jetzt nochmals! (sudo parted --list oder Tool Laufwerke) gparted: SSD komplett löschen (neue Partitionstabelle) und darauf ext4-Partition anlegen fürs gleich zu installierende System. (keine /home oder dgl.! Swap müsste sowieso eine da sein … erst mal alles Wuscht!) Ubuntu-Installer starten und keine automatische Parallelinstallation sondern ▶ hier (Links folgen – gute Anleitung!) "Etwas Anderes" wählen. Die eben frisch angelegte Partition (wohl /dev/sdc1) ▶ hier als / (Wurzelverzeichnis) einbinden. Als "Gerät für die Bootloader-Installation" nicht die SSD, also nicht /dev/sdc auswählen (!!) sondern die bisherige Boot-HDD /dev/sda. (Zugleich nicht etwa eine Partition auswählen, also nicht etwas dort mit angehängter Ziffer.) Installation laufen lassen, Neustart.
Ok, dann wechsel ich gleich zu 'ner Version wo mein Drucker eingebunden ist, das wird sonst nix! 😉
|
MannMitHut
Anmeldungsdatum: 22. Juni 2010
Beiträge: 806
|
Oelle82 schrieb: MannMitHut schrieb:
Die SSD ist nicht direkt startbar, ein GRUB in ihrem MBR nützt uns nichts.
Das ist mal schade für eine SSD!
Das liegt wohl weniger an der SSD als solcher, sondern daran, dass sie über PCIe eingebunden ist.
ubuntu@ubuntu:~$ grub-mkdevicemap
grub-mkdevicemap: Fehler: /boot/grub/device.map kann nicht geöffnet werden.
ubuntu@ubuntu:~$ grub-mkdevicemap --device-map=device Leider ist die dann erzeugte Datei leer.
Klar, denn wenn Du mal in den verlinkten Artikel schaust, steht da: Erfordert Root-Rechte zur Ausführung.
Also, mach das ganze im Root-Terminal oder mit vorangestelltem sudo.
Habe nur die SSD drin und von DVD gebootet und dann die Befehle eingegeben. Oder meintest du von den HDDs booten?
Obige Abfrage ergibt (v.a.) dann Sinn für uns, wenn Du alle Laufwerke, also auch die beiden HDDs im System hast, wie Du es ja am Ende haben möchtest.
Ok, dann wechsel ich gleich zu 'ner Version wo mein Drucker eingebunden ist, das wird sonst nix! 😉
Genau …
|
Oelle82
(Themenstarter)
Anmeldungsdatum: 19. August 2012
Beiträge: 202
|
MannMitHut schrieb: Leider ist die dann erzeugte Datei leer.
Klar, denn wenn Du mal in den verlinkten Artikel schaust, steht da: Erfordert Root-Rechte zur Ausführung.
Also, mach das ganze im Root-Terminal oder mit vorangestelltem sudo.
Och Mist, übersehen. Also das gibt jetzt eine Datei mit folgendem Inhalt:
(hd0) /dev/disk/by-id/ata-WDC_WD740GD-00FLC0_WD-WMAKE2070641
(hd1) /dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1LYA22327
(hd2) /dev/disk/by-id/ata-Kingston_SHPM2280P2H_240G_50026B72630E1598 Ferner habe ich nach deiner Ausführung die Installation durchgeführt.
Die Optionen und das Ergebnis als Screenshot im Anhang.
Bringt uns das schon weiter?
- Bilder
|
Oelle82
(Themenstarter)
Anmeldungsdatum: 19. August 2012
Beiträge: 202
|
So, bin noch etwas weiter gegangen und habe noch etwas geforscht. Ob das richtig war, kannst du mir hoffentlich sagen! ☺ Die UUID die grub im Screenshot bemängelt (e039dcbc-c383...) gibt es nicht in meinem System. Und: In den grub-Konfig-Files finde ich den Eintrag auch nirgends!
Ferner finde ich in den Konfigs sehr wohl die korrekte UUID von sda1 und sdb5, welches den Optionen 12.04 oder 16.04 booten entspricht.
Demnach verstehe ich nun wirklich nicht, warum grub seinen Dienst verweigert bzw nichts findet:
Warum zeigt er die komische an? Warum steht das 16.04 auf sdc nicht in der grub.cfg? Scheint sich ja doch nicht richtig installiert zu haben...
|
MannMitHut
Anmeldungsdatum: 22. Juni 2010
Beiträge: 806
|
Auf die Spur wollte ich auch gerade – gut. Kläre bitte zunächst einmal diesen Widerspruch auf: Oelle82 schrieb: […] Ferner finde ich in den Konfigs sehr wohl die korrekte UUID von sda1 und sdb5, welches den Optionen 12.04 oder 16.04 booten entspricht. […] Warum zeigt er die komische an? Warum steht das 16.04 auf sdc nicht in der grub.cfg? Scheint sich ja doch nicht richtig installiert zu haben...
Eigentlich startet das BIOS doch erst einmal eine Festplatte (als Gerät) und nicht eine Partition darauf. Vielleicht liegt hier der Hund begraben mit der komischen UUID … Ich möchte erst einmal wissen, auf was diese UUID sich eigentlich bezieht – er zeigt ja leider nichts weiter. Kannst du mal bitte die Festplatte in der Bootsequenz ganz nach oben tun, sodass zuvor keine Bilschirmausgaben entstehen, etwa durch das CD/DVD-Laufwerk. Ansonsten könnte es jetzt hier weiter gehen: MannMitHut schrieb: […] Im Prinzip wittere ich die Lösung (zu Fuß beschritten) hier: Linux starten aus der GRUB2-Shell.
Gib auf der erscheinenden Kommandozeile mal nacheinander ein: set root=(hd2,1)
linux /vmlinuz root=/dev/sdc1 ro
initrd /initrd.img
boot Probiere dasselbe ggf. mal mit
set root=(hd0,1)
[…] Wohlgemerkt, ich schwimme herum …
|
Oelle82
(Themenstarter)
Anmeldungsdatum: 19. August 2012
Beiträge: 202
|
MannMitHut schrieb: Auf die Spur wollte ich auch gerade – gut.
☺
Kläre bitte zunächst einmal diesen Widerspruch auf: Oelle82 schrieb: […] Ferner finde ich in den Konfigs sehr wohl die korrekte UUID von sda1 und sdb5, welches den Optionen 12.04 oder 16.04 booten entspricht. […] Warum zeigt er die komische an? Warum steht das 16.04 auf sdc nicht in der grub.cfg? Scheint sich ja doch nicht richtig installiert zu haben...
Eigentlich startet das BIOS doch erst einmal eine Festplatte (als Gerät) und nicht eine Partition darauf. Vielleicht liegt hier der Hund begraben mit der komischen UUID … Ich möchte erst einmal wissen, auf was diese UUID sich eigentlich bezieht – er zeigt ja leider nichts weiter. Kannst du mal bitte die Festplatte in der Bootsequenz ganz nach oben tun, sodass zuvor keine Bilschirmausgaben entstehen, etwa durch das CD/DVD-Laufwerk.
Hab ich - screenshot! Würde den Widerspruch gerne weiter klären - nur wie?
MannMitHut schrieb: […] Im Prinzip wittere ich die Lösung (zu Fuß beschritten) hier: Linux starten aus der GRUB2-Shell.
Hab ich mir schon angesehen, verstehe das aber nicht bzw weiß ich nicht wie ich für mich da jetzt weiterkomme.
Gib auf der erscheinenden Kommandozeile mal nacheinander ein: set root=(hd2,1)
linux /vmlinuz root=/dev/sdc1 ro
initrd /initrd.img
boot Probiere dasselbe ggf. mal mit
set root=(hd0,1)
[…]
Leider nix, die meisten Befehle kennt er nicht!
- Bilder
|
MannMitHut
Anmeldungsdatum: 22. Juni 2010
Beiträge: 806
|
Jetzt schick mal nicht dauernd Beweisfotos, schon gar nicht in solchen Auflösungen. Schreibe lieber Text. Wir glauben Dir schon, was Du sagst. 😉 Es is aber auch eine harte Nuss! Hmm …
Man sollte jetzt im GRUB-Rettungsmodus genauer untersuchen, was der eigentlich sieht. Die Ausgaben von ls und von set wären wohl jetzt weiterführend. Was steht denn in der grub.cfg? Abfrage vom Live-System, wenn /dev/sdc gerade nicht als Normalnutzer eingehängt (z.B. mit der Laufwerksverwaltung zu überprüfen):
sudo mount /dev/sdc1 /mnt
cat /mnt/boot/grub/grub.cfg
Ich habe die Vermutung (zugegeben ohne alles hier genauestens studiert zu haben), es braucht für die SSD via PCIe einen speziellen Treiber, den GRUB nicht hat. Die Lösung könnte sein, dass Du den ganzen Linux-Kernel in die konventionelle Festplatte (/dev/sda) einbaust und von dort laden lässt, das restliche System aber dann von der SSD. Das erreichst Du, indem Du bei der Installation auf /dev/sda eine Boot-Partition anlegst (um ja keinen Stress zu haben sagen wir mal von 4 GiB) und die als /boot einbindest. Die Systempartition (/) aber bleibt auf /dev/sdc.
|
Oelle82
(Themenstarter)
Anmeldungsdatum: 19. August 2012
Beiträge: 202
|
MannMitHut schrieb: Jetzt schick mal nicht dauernd Beweisfotos, schon gar nicht in solchen Auflösungen. Schreibe lieber Text. Wir glauben Dir schon, was Du sagst. 😉
Sorry! Sagen wir mal 50% Beweis, 25% Faulheit abzutippen 25% Sicherheit gegen Vertippen und vergessen! 😉
ls
(hd0) (hd0,msdos5) (hd0,msdos1) (cd) set
cmdpath=(hd0)
prefix=(hd0)/boot/grub
root=hd0
sudo mount /dev/sdc1 /mnt
cat /mnt/boot/grub/grub.cfg
Das ist aber sehr lang! Mache ich mal lieber in eine Textdatei...
Achso, das würde dann bedeuten, das die Installation die SSD in grub einträgt er sie aber beim starten mangels Treiber nicht findet?!
Die Lösung könnte sein, dass Du den ganzen Linux-Kernel in die konventionelle Festplatte (/dev/sda) einbaust und von dort laden lässt, das restliche System aber dann von der SSD. Das erreichst Du, indem Du bei >der Installation auf /dev/sda eine Boot-Partition anlegst (um ja keinen Stress zu haben sagen wir mal von 4 GiB) und die als /boot einbindest. Die Systempartition (/) aber bleibt auf /dev/sdc.
Ui, klingt spannend! Wenn dir durch meine Angaben nichts weiteres einfällt werde ich das wohl mal probieren!
- ausgabe.txt (88.8 KiB)
- Download ausgabe.txt
|
MannMitHut
Anmeldungsdatum: 22. Juni 2010
Beiträge: 806
|
Uiiiii, ist spannend!! Sehr spannend!!! Kurzfassung: Mach die Installation wie beschrieben! Etwas längere Fassung: Du hast unter 12.04 wohl nie mal mit sudo apt-get autoremove alte Kernel entsorgt wie? … egal. Vergleiche die Ausgabe von ls jetzt mit Deiner Ausgabe von grub-mkdevicemap : "grub rescue" sieht als Laufwerke nur hd0 = Linux-Device /dev/sda = auf Deutsch Deine 75GB-HDD und das CD/DVD-Laufwerk (cd); hd2 = /dev/sdc = Deine SSD sieht der gar nicht! Die höheren Schichten von GRUB liegen aber auf der SSD, und deshalb bleibt er auf "grub rescue" hängen.
|