ubuntuusers.de

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Status: Gelöst | Ubuntu-Version: Xubuntu 14.04 (Trusty Tahr)
Antworten |

ninsa

Anmeldungsdatum:
20. Februar 2012

Beiträge: 62

Hallo zusammen,

Zum Spaß und austesten habe ich mir vor ein paar Tagen ein Manjaro 15.09 auf eine freie Partition meiner SSD installiert (nach ausprobieren in Vbox). Den Bootloader habe ich nicht mit installiert, sondern später von Ubuntu aus sudo update-grub ausgeführt, was auch gut funktioniert hat. In dem Manjaro habe ich vor dem aufgetretenen Problem keine weiteren Updates mehr installiert, noch was tiefgreifendes am System geändert.

Nach einem Update in Ubuntu 14.04, meinem Hauptsystem, bootet das Manjaro nun nicht mehr und bricht ab mit der Fehlermeldung

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Da ich in der Manjaro-Install nichts verändert hatte muss ja Ubuntu für diesen Fehler verantwortlich sein. Ich habe aber im Ubuntu-Update keine neuen Kernel installiert oder etwas an Grub verändert, siehe history.log im Anhang, ein Ausschnitt hier:

Der Fehler trat nach diesem Update auf:

Start-Date: 2015-12-11  19:40:48
Commandline: apt-get dist-upgrade
Upgrade: oxideqt-codecs-extra:amd64 (1.10.3-0ubuntu0.14.04.1, 1.11.3-0ubuntu0.14.04.1), gir1.2-gst-plugins-base-1.0:amd64 (1.2.4-1~ubuntu1, 1.2.4-1~ubuntu2), libgstreamer-plugins-base1.0-0:amd64 (1.2.4-1~ubuntu1, 1.2.4-1~ubuntu2), libgstreamer-plugins-base1.0-0:i386 (1.2.4-1~ubuntu1, 1.2.4-1~ubuntu2), gstreamer1.0-plugins-base:amd64 (1.2.4-1~ubuntu1, 1.2.4-1~ubuntu2), coreutils:amd64 (8.21-1ubuntu5.1, 8.21-1ubuntu5.3), gstreamer1.0-x:amd64 (1.2.4-1~ubuntu1, 1.2.4-1~ubuntu2), python-apt:amd64 (0.9.3.5ubuntu1, 0.9.3.5ubuntu2), grub-common:amd64 (2.02~beta2-9ubuntu1.4, 2.02~beta2-9ubuntu1.5), chromium-codecs-ffmpeg-extra:amd64 (45.0.2454.101-0ubuntu0.14.04.1.1099, 47.0.2526.73-0ubuntu0.14.04.1.1106), flashplugin-installer:amd64 (11.2.202.548ubuntu0.14.04.1, 11.2.202.554ubuntu0.14.04.1), grub2-common:amd64 (2.02~beta2-9ubuntu1.4, 2.02~beta2-9ubuntu1.5), chromium-browser-l10n:amd64 (45.0.2454.101-0ubuntu0.14.04.1.1099, 47.0.2526.73-0ubuntu0.14.04.1.1106), libsndfile1:amd64 (1.0.25-7ubuntu2, 1.0.25-7ubuntu2.1), libsndfile1:i386 (1.0.25-7ubuntu2, 1.0.25-7ubuntu2.1), python3-apt:amd64 (0.9.3.5ubuntu1, 0.9.3.5ubuntu2), grub-pc-bin:amd64 (2.02~beta2-9ubuntu1.4, 2.02~beta2-9ubuntu1.5), grub-pc:amd64 (2.02~beta2-9ubuntu1.4, 2.02~beta2-9ubuntu1.5), lightdm:amd64 (1.10.5-0ubuntu1.1, 1.10.6-0ubuntu1), liblightdm-gobject-1-0:amd64 (1.10.5-0ubuntu1.1, 1.10.6-0ubuntu1), python-apt-common:amd64 (0.9.3.5ubuntu1, 0.9.3.5ubuntu2), chromium-browser:amd64 (45.0.2454.101-0ubuntu0.14.04.1.1099, 47.0.2526.73-0ubuntu0.14.04.1.1106), unattended-upgrades:amd64 (0.82.1ubuntu2.3, 0.82.1ubuntu2.4), ntpdate:amd64 (4.2.6.p5+dfsg-3ubuntu2.14.04.5, 4.2.6.p5+dfsg-3ubuntu2.14.04.6)
End-Date: 2015-12-11  19:41:23

Was nun tun? Ich habe bei der Web-Suche tausende Threads gefunden, auch hier in unserem Forum, aber alle beschreiben ein etwas anderes Problem mit anderer Lösung. Meistens wird die Lösung mit chroot ins nicht bootende System angegeben, mit Neuinstallation des Bootloaders, aber das will ich eben nicht. Manjaro soll ohne Bootloader bleiben, Grub ist und bleibt bei Ubuntu, da möchte ich keine Verwirrung oder Durcheinander.

Als Anhang noch das bootinfoscript, /var/log/apt/history.log, und ein Screenshot des Kernelpanics beim booten von Manjaro.

Viele Grüße und schon mal Danke für eventuelle Lösungsvorschläge,

ninsa

P.S.: Ich weiß schon dass das nicht-bootende System Manjaro ist und ich mich an deren Community wenden sollte, was ich dann auch machen werde. Doch wollte ich erst hier fragen, weil das Problem erst bei Updates in Ubuntu (grub) aufgetreten ist. In Manjaro wurde gar nichts verändert. Zudem ist Ubuntu mein Hauptsystem.

RESULTS.txt (33.7 KiB)
Download RESULTS.txt
history.txt (4.7 KiB)
Download history.txt
Bilder

tomtomtom Team-Icon

Supporter
Avatar von tomtomtom

Anmeldungsdatum:
22. August 2008

Beiträge: 55281

Wohnort: Berlin

Sieht glatt so aus, alsob Manjaro da einfach nur einen anderen Eintrag erwartet als den Standard- der von GRUB genau so erkannt wurde, wie das zu erwarten war.

Wähle mal im GRUB-Menü den Manjaro-Eintrag aus, öffne ihn zum Editieren und ändere die Zeile

initrd	/boot/intel-ucode.img

in

initrd	/boot/intel-ucode.img /boot/initramfs-4.1-x86_64.img

Hint: Das ist eine temporäre Änderung, die nicht bestehen bleibt, und erstmal zum Ausprobieren gedacht.

EDIT:

Manjaro hat os-prober gepatched.

Du könntest also in der Theorie das Paket selbst mit dem Patch kompilieren, müsstest das dann aber auch selbst pflegen.

ninsa

(Themenstarter)

Anmeldungsdatum:
20. Februar 2012

Beiträge: 62

Hallo tomtomtom,

Und vielen Dank für die Antwort. Das Manjaro startet mit deiner Änderung tatsächlich anstandslos! Super! Wie bekomme ich es nun hin, das diese Änderung bestehen bleibt? Muss ich /boot/grub/grub.cfg editieren?

tomtomtom schrieb:

Sieht glatt so aus, alsob Manjaro da einfach nur einen anderen Eintrag erwartet als den Standard- der von GRUB genau so erkannt wurde, wie das zu erwarten war.

Deine Vermutung hat sich wohl bestätigt.

Manjaro hat os-prober gepatched.

Danke für der Link. Das hat früher aber funktioniert, sudo update-grub hatte ich nur in Ubuntu ausgeführt. Nur nach diesen Ubuntu-Updates vom 11. Dezember eben nicht mehr:

grub-common:amd64 (2.02~beta2-9ubuntu1.4, 2.02~beta2-9ubuntu1.5
grub2-common:amd64 (2.02~beta2-9ubuntu1.4, 2.02~beta2-9ubuntu1.5)
grub-pc-bin:amd64 (2.02~beta2-9ubuntu1.4, 2.02~beta2-9ubuntu1.5)
grub-pc:amd64 (2.02~beta2-9ubuntu1.4, 2.02~beta2-9ubuntu1.5)

Nun ist die Frage, ob das grub-Update von Ubuntu oder der gepatchte Manjaro-bootloader dafür verantwortlich ist. Ich tippe mal auf letzteres (obwohl ich nicht die geringste Ahnung von der Materie habe).

Du könntest also in der Theorie das Paket selbst mit dem Patch kompilieren, müsstest das dann aber auch selbst pflegen.

Ok danke, das ist gut zu wissen. Da ich Wert auf ein stabiles Hauptsystem lege, werde ich das nicht tun, aber ich werde das dann mal den Manjaro-Leuten berichten und hoffe, dass die eine Lösung finden.

Viele Grüße, ninsa

P.S.: Entschuldigung auch für meine zeitverzögerte Antwort, ich bin hier in Korea.

tomtomtom Team-Icon

Supporter
Avatar von tomtomtom

Anmeldungsdatum:
22. August 2008

Beiträge: 55281

Wohnort: Berlin

ninsa schrieb:

Wie bekomme ich es nun hin, das diese Änderung bestehen bleibt?

Am besten mit einem entsprechenden GRUB 2/Skript. 😉

Muss ich /boot/grub/grub.cfg editieren?

Ich empfehle die Lektüre der zweiten Zeile der Datei.

sed -ne '2p' /boot/grub/grub.cfg

Das hat früher aber funktioniert, sudo update-grub hatte ich nur in Ubuntu ausgeführt. Nur nach diesen Ubuntu-Updates vom 11. Dezember eben nicht mehr:

Das Changelog führt keine Änderung auf, die da etwas bewirken sollte.

Nun ist die Frage, ob das grub-Update von Ubuntu oder der gepatchte Manjaro-bootloader dafür verantwortlich ist. Ich tippe mal auf letzteres (obwohl ich nicht die geringste Ahnung von der Materie habe).

Nun, das Skript in Ubuntu erzeugt nicht den Eintrag, den dein Manjaro zum Starten braucht.

aber ich werde das dann mal den Manjaro-Leuten berichten und hoffe, dass die eine Lösung finden.

Was sollen die daran ändern, dass für Ubuntu paketierte Skript dsa nicht kann? 😉

Da würde sich eher ein Bug-Report eignen. Ist ja schließlich Sinn und Zweck von os-prober, andere Systeme zu erkennen.

Solange du wirklich nur die zwei Systeme auf dem Rechner nutzen willst kannst du os-prober einfach mittels

sudo chmod -x /etc/grub.d/30_os_prober

Dann die Manjaro-Partition einbinden

sudo mount /dev/sda5 /mnt

und die Datei rüberkopieren

sudo cp /mnt/etc/grub.d/30_os-prober /etc/grub.d/31_os-prober-manjaro

Abschließend die Konfiguration neu einlesen per

sudo grub-mkconfig -o /boot/grub/grub.cfg

Benno-007

Anmeldungsdatum:
28. August 2007

Beiträge: 29240

Wohnort: Germany

chmod deaktiviert das Script - da fehlte ein Wort. 😉

ninsa

(Themenstarter)

Anmeldungsdatum:
20. Februar 2012

Beiträge: 62

Wie bekomme ich es nun hin, das diese Änderung bestehen bleibt?

Am besten mit einem entsprechenden GRUB 2/Skript. 😉

Uff... das wird ein paar Tage dauern, bis ich mich da eingearbeitet habe. Nach kurzem Überfliegen, und auf die Gefahr hin mich jetzt zu balmieren (garantiert ☺) ein erster Schuss ins Blaue:

/etc/grub.d/43_custom

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry 'Manjaro Linux (15.12-rc1) (auf /dev/sda5)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-036f9282-decc-4a8b-af78-8647f0d60dbf' {
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos5'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  036f9282-decc-4a8b-af78-8647f0d60dbf
	else
	  search --no-floppy --fs-uuid --set=root 036f9282-decc-4a8b-af78-8647f0d60dbf
	fi
	linux /boot/vmlinuz-4.1-x86_64 root=UUID=036f9282-decc-4a8b-af78-8647f0d60dbf rw quiet
	initrd /boot/intel-ucode.img /boot/initramfs-4.1-x86_64.img
}
sed -ne '2p' /boot/grub/grub.cfg

Ich empfehle die Lektüre der zweiten Zeile der Datei.

Das habe ich erst mal gar nicht gecheckt, aber nach der Eingabe deines Einzeilers habe ich erstmal richtig laut gelacht. ☺ Ja, okay, ich werde nichts an /boot/grub/grub.cfg rumeditieren.

aber ich werde das dann mal den Manjaro-Leuten berichten und hoffe, dass die eine Lösung finden.

Was sollen die daran ändern, dass für Ubuntu paketierte Skript dsa nicht kann? 😉

Soweit ich das hier https://forum.manjaro.org/index.php?topic=19118.0 richtig verstehe, gab es den gleichen Fehler (Kernel Panic und nicht funktionierender OS-Prober) schon mal, der zu dem Patch in dem Paket führte.

Da würde sich eher ein Bug-Report eignen. Ist ja schließlich Sinn und Zweck von os-prober, andere Systeme zu erkennen.

Ich glaube auch, du hast Recht. Im oben genannten Thread wurde auch dieser Bug-Report an Arch-Linux gesendet: https://bugs.archlinux.org/task/43254

Solange du wirklich nur die zwei Systeme auf dem Rechner nutzen willst kannst du os-prober einfach mittels

sudo chmod -x /etc/grub.d/30_os_prober

Dann die Manjaro-Partition einbinden

sudo mount /dev/sda5 /mnt

und die Datei rüberkopieren

sudo cp /mnt/etc/grub.d/30_os-prober /etc/grub.d/31_os-prober-manjaro

Abschließend die Konfiguration neu einlesen per

sudo grub-mkconfig -o /boot/grub/grub.cfg

Das hat leider nicht funktioniert. Der neue Eintrag in der grub.conf führt wieder zur Kernel-Panic. Der Eintrag initrd /boot/intel-ucode.img /boot/initramfs-4.1-x86_64.img wurde nicht hinzugefügt.

Viele Grüße, Ninsa

ninsa

(Themenstarter)

Anmeldungsdatum:
20. Februar 2012

Beiträge: 62

Benno-007 schrieb:

chmod deaktiviert das Script - da fehlte ein Wort. 😉

Dann wie heißt es richtig?

Vej Team-Icon

Moderator, Supporter
Avatar von Vej

Anmeldungsdatum:
7. März 2013

Beiträge: 3400

Hallo ninsa.

ninsa schrieb:

Dann wie heißt es richtig?

Richtig wäre:

tomtomtom schrieb:

Solange du wirklich nur die zwei Systeme auf dem Rechner nutzen willst kannst du os-prober einfach mittels

sudo chmod -x /etc/grub.d/30_os_prober

deaktivieren.

Benno-007 wollte wohl nur sicherstellen, dass du weißt was du da tust. Der Befehl ist soweit ich das beurteilen kann richtig.

Viele Grüße

Vej

Xeno Team-Icon

Ehemalige

Anmeldungsdatum:
6. April 2005

Beiträge: 2595

Wohnort: Schweiz

LiebeR ninsa

Meine Lösung für das Problem:

Benutze den GRUB von Manjaro statt den von Ubuntu für Dein Mulibootsystem. Der Manjaro-GRUB bootet nämlich jedes Ubuntu anstandslos, ebenso andere Distris, die nämlich dasselbe Problem produzieren (etwa openSUSE und auch Fedora).

Damit Dir dann nicht jedes zweite Ubuntu-Update den Manjaro-GRUB wieder überschreibt, musst Du den Ubuntu-GRUB in die betreffende Ubuntu-Partition installieren statt in den MBR. Dasselbe gilt für ggf. weitere Distris. Eine andere Lösung wäre Ubuntu ganz ohne GRUB zu installieren oder den Ubuntu-GRUB gar nachträglich zu entfernen; beides ist deutlich fummeliger als mein Vorschlag; vom nachträglichen Entfernen rate ich persönlich sogar klar ab.

Es ist die einfachste Lösung, wobei es andere gibt, mit denen Du aber tief in die Gefilde der angewandten GRUBologie eintauchen musst.

Happy multibooting!

Lg. X.

Lindiot

Anmeldungsdatum:
22. August 2006

Beiträge: 693

Wenn in deiner /etc/grub.d/40_custom auf sda1 noch "nichts" drinsteht, dann editierst die zu folgendem Ergebnis

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
#
# Made by ninsa 13.Dez.2015
menuentry 'Manjaro Linux (15.12-rc1) (auf /dev/sda5) ninsa' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-036f9282-decc-4a8b-af78-8647f0d60dbf' {
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos5'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  036f9282-decc-4a8b-af78-8647f0d60dbf
	else
	  search --no-floppy --fs-uuid --set=root 036f9282-decc-4a8b-af78-8647f0d60dbf
	fi
	linux /boot/vmlinuz-4.1-x86_64 root=UUID=036f9282-decc-4a8b-af78-8647f0d60dbf rw quiet
	initrd /boot/intel-ucode.img /boot/initramfs-4.1-x86_64.img
}
submenu 'Erweiterte Optionen für Manjaro Linux (15.12-rc1) (auf /dev/sda5) ninsa' $menuentry_id_option 'osprober-gnulinux-advanced-036f9282-decc-4a8b-af78-8647f0d60dbf' {
	menuentry 'Manjaro Linux (auf /dev/sda5)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.1-x86_64--036f9282-decc-4a8b-af78-8647f0d60dbf' {
		insmod part_msdos
		insmod ext2
		set root='hd0,msdos5'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  036f9282-decc-4a8b-af78-8647f0d60dbf
		else
		  search --no-floppy --fs-uuid --set=root 036f9282-decc-4a8b-af78-8647f0d60dbf
		fi
		linux /boot/vmlinuz-4.1-x86_64 root=UUID=036f9282-decc-4a8b-af78-8647f0d60dbf rw quiet
		initrd /boot/intel-ucode.img /boot/initramfs-4.1-x86_64.img
	}
	menuentry 'Manjaro Linux (Kernel 4.1.13-1-MANJARO x64) (auf /dev/sda5) ninsa' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.1-x86_64--036f9282-decc-4a8b-af78-8647f0d60dbf' {
		insmod part_msdos
		insmod ext2
		set root='hd0,msdos5'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  036f9282-decc-4a8b-af78-8647f0d60dbf
		else
		  search --no-floppy --fs-uuid --set=root 036f9282-decc-4a8b-af78-8647f0d60dbf
		fi
		linux /boot/vmlinuz-4.1-x86_64 root=UUID=036f9282-decc-4a8b-af78-8647f0d60dbf rw quiet
		initrd /boot/intel-ucode.img /boot/initramfs-4.1-x86_64.img
	}
	menuentry 'Manjaro Linux (Kernel 4.1.13-1-MANJARO x64 - fallback initramfs) (auf /dev/sda5) ninsa' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.1-x86_64--036f9282-decc-4a8b-af78-8647f0d60dbf' {
		insmod part_msdos
		insmod ext2
		set root='hd0,msdos5'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  036f9282-decc-4a8b-af78-8647f0d60dbf
		else
		  search --no-floppy --fs-uuid --set=root 036f9282-decc-4a8b-af78-8647f0d60dbf
		fi
		linux /boot/vmlinuz-4.1-x86_64 root=UUID=036f9282-decc-4a8b-af78-8647f0d60dbf rw quiet
		initrd /boot/intel-ucode.img /boot/initramfs-4.1-x86_64-fallback.img
	}
}

Danach ist vermutlich noch ein grub-update (oder auch nur "grub mkconfig" in korrekter Aufrufform) in Ubuntu (sda1) auszuführen und die angepassten Einträge sollten im Bootmenü erscheinen (möglicherweise nun doppelt, die korrigierten erkennst am ninsa). Automatisch anpassen, bei neuen Kernel-Versionen auf sda5, tut sich das selbstverständlich nicht (40_custom, Betonung auf custom), aber bis dahin könnte ja eine verbesserte Ubuntu Grub-Version vorliegen, die das wieder korrekt übernehmen könnte.

ninsa

(Themenstarter)

Anmeldungsdatum:
20. Februar 2012

Beiträge: 62

Hallo zusammen,

Vej schrieb:

Benno-007 wollte wohl nur sicherstellen, dass du weißt was du da tust. Der Befehl ist soweit ich das beurteilen kann richtig.

Okay danke, habe ich jetzt verstanden.

Xeno schrieb:

Meine Lösung für das Problem:

Benutze den GRUB von Manjaro statt den von Ubuntu für Dein Mulibootsystem. Der Manjaro-GRUB bootet nämlich jedes Ubuntu anstandslos, ebenso andere Distris, die nämlich dasselbe Problem produzieren (etwa openSUSE und auch Fedora).

Danke für den Tipp und die Info, das andere Distris den selben Fehler produzieren! Ich überlege mir das so wie von dir vorgeschlagen zu machen.

Lindiot schrieb:

Wenn in deiner /etc/grub.d/40_custom auf sda1 noch "nichts" drinsteht, dann editierst die zu folgendem Ergebnis

Wow! Vielen Dank für die Hilfe! Das funktionierte absolut perfekt. Nach sudo grub-mkconfig -o /boot/grub/grub.cfg wird der neue Menüeintrag angezeigt und bootet auch.

Ich setze jetzt auf gelöst, und vielen Dank an alle Helfer!

Viele Grüße, ninsa

Lindiot

Anmeldungsdatum:
22. August 2006

Beiträge: 693

Falls noch Interesse besteht, so habe ich möglicherweise eine dauerhafte, sich "automatisch" Updates anpassende, Lösung. Betonung liegt auf "möglicherweise", da ich das explizit mit einem Manjaro-Sytem nicht nachprüfen kann.

Xeno Team-Icon

Ehemalige

Anmeldungsdatum:
6. April 2005

Beiträge: 2595

Wohnort: Schweiz

Lieber Lindiot

Klar besteht das Interesse. Ubuntu-Manjaro-Systeme sind gar nicht mehr so abgefahren selten. Immer nur her mit neuen Ansätzen! Ich habe mich nur auf den beschriebenen Workaround zurückgezogen und aus den anspruchsvollen Sonderdiskussionen der Höheren Grubologie ausgeklinkt, weil es mir zu komplex (mehr: zu zeitaufwändig) wurde, das Gesamtkunstwerk GRUB Zeile um Ziele, Variable um Variable zu zersägen.

Lg X.

P.S.: Ich teste das ggf. dann (wenn Du das willst), aber vorm 28. Dezember kann ich es nicht (versprechen).

ninsa

(Themenstarter)

Anmeldungsdatum:
20. Februar 2012

Beiträge: 62

Hallo Lindiot,

Danke für deine Hilfe. Ich hatte es jetzt dann doch so gemacht wie von Xeno vorgeschlagen, was auch reibungslos und sehr elegant (!) funktioniert. Manjaro gefällt mir auch ziemlich gut, jedoch betrachte ich Xuntuntu 14.04 weiterhin als mein Hauptsystem. Interesse besteht bei mir deshalb auf jeden Fall, und ich würde das gerne probieren.

Viele Grüße, ninsa

Lindiot

Anmeldungsdatum:
22. August 2006

Beiträge: 693

Speziell für das hier vorliegende Beispiel von ninsa,

wäre folgendes der Datei "/etc/grub.d/40_custom" HINZUZUFÜGEN und ein "update-grub" im laufenden Ubuntu-Sytem aufzurufen, Fertig. Zuvor sollte noch überprüft werden, ob sich die Datei "core.img auf Festplatte sda5!!" (letzte Zeile) auch an dem unten angegebenen Pfad befindet. Bei Bedarf den Pfad anpassen.

menuentry "   ===================  Manjaro Boots  ===================" {
	insmod multiboot
	insmod part_msdos
	insmod ext2
	set root='(hd0,5)'
	search --no-floppy --fs-uuid --set 036f9282-decc-4a8b-af78-8647f0d60dbf
	multiboot /boot/grub/i386-pc/core.img
}

Allgemein,

"Grub2" Bios Boot, MBR-Partitionstabelle : (evtl auch für GPT?, aber nicht zusammen mit UEFI),

ohne Bezug auf Vorhandenes, sollte Folgendes

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "   ===================  Manjaro Boots  ===================" {
	insmod multiboot
	insmod part_msdos
	insmod ext2
	set root='(hdX,Y)'
	search --no-floppy --fs-uuid --set <UUID der Partition Y auf hdX>
	multiboot <Pfad zur Datei core.img auf hdX Partition Y im /boot/grub/... (zB: /boot/grub/i386-pc/core.img)>
}

X, Y, < ... > sind den vorliegenden Verhältnissen entsprechend zu ersetzen

abgespeichert als Datei "42_custom" (Datei 42_custom noch nicht vorhanden) im Verzeichnis "/etc/grub.d/" , mit nachfolgendem Aufruf von "update-grub" unter laufendem Ubuntu, zum erwünschten Ziel führen.

Zum Nur-Testen (temporäres Edit) im Ubuntu Grub-Menü vorm Boot, kann der search-Befehl auch mal weggelassen werden, sofern alle anderen Angaben korrekt sind.

Antworten |