Mageia Forum

Ich hoffe ja schon, dass in der bald folgenden Nachfolgeoption die Zusammenarbeit von Grub mit den anderen LinuxDistributionen problemlos funktioniert.
Als Beispiel habe ich auf einem Rechner mit 2 Festplatten 6 verschiedene Linusdistributionen installiert und nur die Mageia 4.1 läßt sich obwohl die Installation vorher problemlos war als einzige Distribution nicht von dem Grub der zuletzt Installierten Linuxdistribution (hier SuSE 13.2) starten.
Es geht nur bis zu einem Systempromt.
Frage wird das bei der neuen Version dann gut mit den anderen Distries zusammenarbeiten? Und wie installiere ich dann die neue Version ohne das der Bootmanager von pensuse verändert wird?

So einfach läßt sich Deine Frage für mich nicht beantworten, weil Du nicht konkret wirst.
Bei mir sieht das z.B. heute mit dem neuen 3.14.23 Kernel von MGA4-KDE so aus:

Code: Alles auswählen

update-grub2
grub.cfg wird erstellt …
Thema gefunden: /boot/grub2/themes/maggy/theme.txt
Linux-Abbild gefunden: /boot/vmlinuz-desktop
initrd-Abbild gefunden: /boot/initrd-desktop.img
Linux-Abbild gefunden: /boot/vmlinuz-3.14.23-desktop-1.mga4
initrd-Abbild gefunden: /boot/initrd-3.14.23-desktop-1.mga4.img
Linux-Abbild gefunden: /boot/vmlinuz-3.14.18-desktop-3.mga4
initrd-Abbild gefunden: /boot/initrd-3.14.18-desktop-3.mga4.img
Linux-Abbild gefunden: /boot/vmlinuz-3.12.25-desktop-3.mga4
initrd-Abbild gefunden: /boot/initrd-3.12.25-desktop-3.mga4.img
Mageia 4 flux (4) auf /dev/sdb1 gefunden
Mageia 5 KDE (5) auf /dev/sdb10 gefunden
antiX 14 (14) auf /dev/sdb11 gefunden
Mageia 5 LXQT (5) auf /dev/sdb12 gefunden
siduction LXQt-DR (2014.1 ) auf /dev/sdb13 gefunden
ROSA Desktop Fresh R4 (2014.1) auf /dev/sdb7 gefunden
Mageia 3 LXDE (3) auf /dev/sdb9 gefunden
Windows 7 (loader) auf /dev/sdc1 gefunden
erledigt


Bei den anderen Rechnern sieht es ähnlich aus., will sagen, ich habe keine Probleme mit dem Bootmanagement.
Auf zwei Rechner hat der Grub2 von Mageia das Sagen und auf dem dritten macht das Syslinux von Arch.

Gerschon hat geschrieben:Es geht nur bis zu einem Systempromt.

Das mußt Du schon näher erklären.

Hallo,
ja ich erkläre das übermorgen, weil das ist der Rechner zu Hause mit dem Problem.
Dann kann ich auch sowas wie den derzeitigen Stand von: update-grub schicken.

Gerschon hat geschrieben:Es geht nur bis zu einem Systempromt.

Das mußt Du schon näher erklären.[/quote]

Gestern habe ich allerdings das Mageia neu installiert. Das läuft jetzt dort wieder.
Aber.
Mageia hat das Bootmanagement übernommen. Eher will ich alles vom Bootmanagement der OpenSuSE 13.2 übernehmen lassen.
Der Stand ist nun:
Nach Start kommt Mageia Bootmanager. Dort ist die 13.2 SuSE aufgeführt.
Nach Auswahl von 13.2 OpenSUSE startet deren Bootmnager und damit das System.
Wenn ich in das graphische Tool dort reingehe sehe ich dass wieder das / rooot Verzeichnis vorgewählt ist und er will der Bootmanager auf SDB installieren.
(sdb3 und sb4 sind am Ende der 2. Platte die OpenSuSE Partitionen)
Ein Ändern, also eine Neukonfiguration im Yast auf sda und Sda vor sdb (Button Detail) wird aber nicht angenommen. Fehlermeldung er kann grub nicht in sda installieren.

Werde wohl diese letzte Distribution (also SuSE) nochmal neu installieren müssen.

PS: Bei dem anderen Rechner klappt das mit dem Bootmanagement mit OpenSuse13.2 und alle Distributionen dort sind zu starten.

Bevor Du hier weitermachst, hätte ich gern

Code: Alles auswählen

fdisk -l -u -c

und eine Erklärung, was was ist.
Beispiel:
sda = Grub2 von mga
sda1 = mga
sdb2 = suse
etc.


Edit: Sorry, falls Du gpt im System haben solltest, dann

Code: Alles auswählen

parted -l

Hier wie gewünscht die Angaben:

Code: Alles auswählen

fdisk -l -u -c

Disk /dev/sda: 114,5 GiB, 122942324736 bytes, 240121728 sectors
Units: Sektoren of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8ce38ce3

Gerät     Boot Start      Ende    Blocks  Id System
/dev/sda1 *       63 240107489 120053713+  7 HPFS/NTFS/exFAT


Disk /dev/sdb: 114,5 GiB, 122942324736 bytes, 240121728 sectors
Units: Sektoren of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000e26c8

Gerät     Boot     Start      Ende    Blocks  Id System
/dev/sdb1 *         2048   4475519   2236736  82 Linux swap / Solaris
/dev/sdb2        4478922 240120719 117820899   5 Extended
/dev/sdb5        4478976  36892799  16206912  83 Linux
/dev/sdb6       36896768 240120719 101611976  83 Linux


Auf sda ist immer noch WinXPSP3
Auf sdb ist Mageia 4.1, wobei sdb1 Swap ist, sdb5 / ist und /sdb6 /home ist.
Das ursprüngliche Problem siehe oben!!! auf einem anderen Rechner von mir ist gelöst. Dadurch einfach, dass ich das Bootmanagement von Open SuSE mit ext4 formatiert habe. Dadurch konnte der Bootmanager in sda installiert werden. Das neue Dateisystem btrfs macht da wohl ganz schön Probleme.
Hier auf diesem ältesten Rechner (Aldi-Rechner glaube von 2001 oder so) mit 2 * 120 GB Festplatten habe ich die beiden Betriebssysteme drauf wie vor geschrieben. Es ist noch ein System ohne sata. 1 GB Arbeitspeicher und Intel P4.
Nur bei längerem Betrieb und darauffolgendem Neustart kommt ein Bootproblem hinzu wobei Grub meldet stage 1.5 error 18 usw...
Nach Ruhepause geht das Bootmangement wieder.

Code: Alles auswählen

 parted -l
Modell: ATA Maxtor 6Y120P0 (scsi)
Festplatte  /dev/sda:  123GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk Flags:

Nummer  Anfang  Ende   Größe  Typ      Dateisystem  Flags
 1      32,3kB  123GB  123GB  primary  ntfs         boot

                                                                                                                                                                               
Modell: ATA Maxtor 6Y120P0 (scsi)                                                                                                                                             
Festplatte  /dev/sdb:  123GB                                                                                                                                                   
Sektorgröße (logisch/physisch): 512B/512B                                                                                                                                     
Partitionstabelle: msdos                                                                                                                                                       
Disk Flags:                                                                                                                                                                   
                                                                                                                                                                               
Nummer  Anfang  Ende    Größe   Typ       Dateisystem     Flags                                                                                                               
 1      1049kB  2291MB  2290MB  primary   linux-swap(v1)  boot                                                                                                                 
 2      2293MB  123GB   121GB   extended                                                                                                                                       
 5      2293MB  18,9GB  16,6GB  logical   ext4                                                                                                                                 
 6      18,9GB  123GB   104GB   logical   ext4                                                                                                                                 
                                                       

Gibt es ein Grub zuverlässiges Reparationstool ?

Hier vom jetzigen Rechner die Grub-Einträge in menu.lst:

Code: Alles auswählen

timeout 10
color black/cyan yellow/cyan
gfxmenu (hd1,4)/boot/gfxmenu
default 0

title linux
kernel (hd1,4)/boot/vmlinuz BOOT_IMAGE=linux root=UUID=75b99c4b-3ede-40fa-90fb-f750b2725823 splash quiet resume=UUID=c9871f21-8d4e-4d94-a0b8-828d13e225e5 vga=788
root (hd1,4)
initrd /boot/initrd.img

title Windows XP Professional SP3
root (hd0,0)
makeactive
chainloader +1

title desktop 3.3.6-2.mga2
kernel (hd1,4)/boot/vmlinuz-3.3.6-desktop-2.mga2 BOOT_IMAGE=desktop_3.3.6-2.mga2 root=UUID=75b99c4b-3ede-40fa-90fb-f750b2725823 splash quiet resume=UUID=c9871f21-8d4e-4d94-a0$
root (hd1,4)
initrd /boot/initrd-3.3.6-desktop-2.mga2.img

title desktop 3.4.34-1.mga2
kernel (hd1,4)/boot/vmlinuz-3.4.34-desktop-1.mga2 BOOT_IMAGE=desktop_3.4.34-1.mga2 root=UUID=75b99c4b-3ede-40fa-90fb-f750b2725823 splash quiet resume=UUID=c9871f21-8d4e-4d94-$
root (hd1,4)
initrd /boot/initrd-3.4.34-desktop-1.mga2.img

title desktop 3.4.45-1.mga2
kernel (hd1,4)/boot/vmlinuz-3.4.45-desktop-1.mga2 BOOT_IMAGE=desktop_3.4.45-1.mga2 root=UUID=75b99c4b-3ede-40fa-90fb-f750b2725823 splash quiet resume=UUID=c9871f21-8d4e-4d94-$
root (hd1,4)
initrd /boot/initrd-3.4.45-desktop-1.mga2.img

title linux-nonfb
kernel (hd1,4)/boot/vmlinuz BOOT_IMAGE=linux-nonfb root=UUID=75b99c4b-3ede-40fa-90fb-f750b2725823 splash quiet resume=UUID=c9871f21-8d4e-4d94-a0b8-828d13e225e5
root (hd1,4)
initrd /boot/initrd.img

title failsafe
kernel (hd1,4)/boot/vmlinuz BOOT_IMAGE=failsafe root=UUID=75b99c4b-3ede-40fa-90fb-f750b2725823 splash quiet failsafe
root (hd1,4)
initrd /boot/initrd.img

title windows
root (hd0,0)
makeactive
chainloader +1

title desktop 3.8.13.4-1.mga3
kernel (hd1,4)/boot/vmlinuz-3.8.13.4-desktop-1.mga3 BOOT_IMAGE=desktop_3.8.13.4-1.mga3 root=UUID=75b99c4b-3ede-40fa-90fb-f750b2725823 splash quiet resume=UUID=c9871f21-8d4e-4$
root (hd1,4)
initrd /boot/initrd-3.8.13.4-desktop-1.mga3.img

title desktop 3.10.24-2.mga3
kernel (hd1,4)/boot/vmlinuz-3.10.24-desktop-2.mga3 BOOT_IMAGE=desktop_3.10.24-2.mga3 root=UUID=75b99c4b-3ede-40fa-90fb-f750b2725823 splash quiet resume=UUID=c9871f21-8d4e-4d9$
root (hd1,4)
initrd /boot/initrd-3.10.24-desktop-2.mga3.img


Kann ich davon die meisten löschen?

Zum Aldi-Rechner.

Es fäält auf, dass beide Platten das Bootflag besitzen. Für das Bios ist das unüblich.
Wahrscheinlich konntest Du aber genau deswegen die Kiste starten. Der Fehler 18 hängt damit zusammen (scrolle bis ERROR 18 herunter): http://www.gentoo.org/doc/de/grub-error-guide.xml
Lösung wäre also MGA auf sda zu installieren.

Kann ich davon die meisten löschen?

Ja.
Mach das aber Bitte über das MCC>Softwareverwaltung>links oben "ALLE">daneben "Installiert>und in die Such-Zeile>Kernel
'reinschreiben.

unklar hat geschrieben:Lösung wäre also MGA auf sda zu installieren.

Nach hier könntest Du das schnapp ab auch durch eine Um-Partitionierung von sdb erreichen. Dazu müßtest die Swap (sdb1) an das Ende der Platte platzieren. Also würde das so aussehen:

sdb1 = /
sdb2 = Extended
sdb5 = /home
sdb6 = swap

Gerschon hat geschrieben:Auf sdb ist Mageia 4.1, wobei sdb1 Swap ist, sdb5 / ist und /sdb6 /home ist.
...
Hier vom jetzigen Rechner die Grub-Einträge in menu.lst:

In der menu.lst kann ich keine mga4.1 erkennen.

Gerschon hat geschrieben:Frage wird das bei der neuen Version dann gut mit den anderen Distries zusammenarbeiten? Und wie installiere ich dann die neue Version ohne das der Bootmanager von pensuse verändert wird?

und

Mageia hat das Bootmanagement übernommen. Eher will ich alles vom Bootmanagement der OpenSuSE 13.2 übernehmen lassen.
...
Nach Start kommt Mageia Bootmanager. Dort ist die 13.2 SuSE aufgeführt.
Nach Auswahl von 13.2 OpenSUSE startet deren Bootmnager und damit das System.
Wenn ich in das graphische Tool dort reingehe sehe ich dass wieder das / rooot Verzeichnis vorgewählt ist und er will der Bootmanager auf SDB installieren.
(sdb3 und sb4 sind am Ende der 2. Platte die OpenSuSE Partitionen)
Ein Ändern, also eine Neukonfiguration im Yast auf sda und Sda vor sdb (Button Detail) wird aber nicht angenommen. Fehlermeldung er kann grub nicht in sda installieren.

und

Das ursprüngliche Problem siehe oben!!! auf einem anderen Rechner von mir ist gelöst. Dadurch einfach, dass ich das Bootmanagement von Open SuSE mit ext4 formatiert habe. Dadurch konnte der Bootmanager in sda installiert werden. Das neue Dateisystem btrfs macht da wohl ganz schön Probleme.

Um das mal zum Abschluß zu bringen...

Btrfs ist Zitat:

Der Installer bietet weiterhin als Alternative auch btrfs als Dateisystem an. Bitte beachtet unbedingt die Warnungen in dem
Zusammenhang. Die Unterstützung von btrfs ist immer noch als experimentell anzusehen und es sollte noch nicht auf Produktivsystemen eingesetzt werden. Regelmäßige Backups sind absolut Pflicht!

Quelle
Du hattest also eine richtige Entscheidung getroffen auf das Dateisystem ext4 zu wechseln, weil der grub2 von OpenSuSE
(zumal auf sdb (!) und in einem Multibootsystem), wie alle GRUB's2 mit btrfs nicht richtig umgehen können.
Dieser BUG in einem anderen Zusammenhang, besteht nun seit 2011. Mir ist nicht klar, wer von den Entwicklern hier den Hut auf hat, die von btrfs oder grub.

Deine bisherigen Angaben lassen mich zu dem Schluß kommen, Deine Multibootsysteme richtest Du so ein, dass Du es immer den Installern überläßt, wohin Sie GRUB installieren. Da dies immer der MBR von sda ist, kommt es, das dieses MGA den vorher dort befindlichen von OpenSuSE einfach platt macht.
Daher empfehle ich Dir zukünftig über eine seperate /boot-Partition nachzudenken.

PS: Wenn das für Dich ausreichend ist, dann markiere den Faden Bitte entsprechend. Danke.

unklar hat geschrieben:Du hattest also eine richtige Entscheidung getroffen auf das Dateisystem ext4 zu wechseln, weil der grub2 von OpenSuSE
(zumal auf sdb (!) und in einem Multibootsystem), wie alle GRUB's2 mit btrfs nicht richtig umgehen können.
Dieser BUG in einem anderen Zusammenhang, besteht nun seit 2011. Mir ist nicht klar, wer von den Entwicklern hier den Hut auf hat, die von btrfs oder grub.

Ist ja interessant - am Wochenende hab ich auf meinem neuen Rechenknecht Mageia 5 Beta 1 installiert,
interessehalber mit btrfs für / und /home. Automatisch wurde vom Installer grub2 ausgewählt und eingerichtet.
Funzt wunderbar.

Auch der Hinweis, dass es instabil ist, ist schon lange überholt. Nicht umsonst setzt SLES12 standardmäßig auf btrfs.
Siehe auch http://www.heise.de/open/meldung/Btrfs- ... 37356.html

@dok
es ist wohl wieder mal soweit.
Welches Multibootsystem hattest Du auf Deinem neuen Rechenknecht eingerichtet...

Nicht umsonst bist Du hier der Doktor und die Anderen alle ein bissel bl...
Wenn Dir mein Lob/Empfehlung an den TE gegen den Strich gehen dann erinnere Dich an Deine Sprüche: "Wer lesen kann..."
UND " ...aber, mach nur!"

unklar hat geschrieben:Welches Multibootsystem hattest Du auf Deinem neuen Rechenknecht eingerichtet...

Bis jetzt noch nix außer Windows 7 und Mageia.

unklar hat geschrieben:Wenn Dir mein Lob/Empfehlung an den TE gegen den Strich gehen dann erinnere Dich an Deine Sprüche: "Wer lesen kann..."
UND " ...aber, mach nur!"

Glaube du hast da was falsch verstanden - ich hab nur bekundet dass es hier mit btrfs und grub2, der davon bootet keine Probleme gibt.

Was btrfs angeht - der Entwickler von btrfs hat es selbst für stabil erklärt, bis auf intensive Nutzung von RAID 5/6.
Es wird im SuSe Enterprise Server als Standard eingesetzt - meinst du das machen die mit einem instabilen Dateisystem?

Hallo,

nicht nur SLES, auch openSUSE setzt btrfs seit 13.2 als Dateisystem ein. Mein Eindruck ist allerdings, daß sie dem auch noch nicht so richtig trauen, eine andere Erkärung dafür, daß für /home als Standard xfs vorgeschlagen (siehe Screenshot) wird, habe ich nicht wirklich. Allerdings bin ich relativ sicher, daß die oS-Leute das Ding auch mit grub2 vom btrfs gestartet bekommen, bzw. konnte ich mich davon überzeugen, daß es funktioniert.

Grüße
Lutz

lula hat geschrieben:Mein Eindruck ist allerdings, daß sie dem auch noch nicht so richtig trauen, eine andere Erkärung dafür, daß für /home als Standard xfs vorgeschlagen (siehe Screenshot) wird, habe ich nicht wirklich.

Ich denke das hat andere Gründe. btrfs werden sie für die OS-relevanten Dateisysteme nutzen, da YaST und die anderen SuSE-Tools angepasst wurden, damit sie vor und nach Änderungen btrfs-Snapshots erzeugen, welche man wiederum wunderbar vergleichen und auch später Änderungen rückgängig machen kann auf Dateisystemebene, damit hat das Tool dann weniger zu tun.

Für /home evtl. die bessere Eignung für größere Dateien, welche dort bei weitem öfter anzutreffen sind.
Zum Vergleich, Redhat hat für RHEL 7 das Standard-Dateisystem von ext4 auf xfs umgestellt.

Siehe auch die Diskussion in https://forums.opensuse.org/showthread. ... FS-vs-Ext4
oder den ausführlichen Bericht dazu von einem gewissen Herrn Kofler: https://kofler.info/opensuse-13-2-ausprobiert/
[siehe unten den Abschnitt Dateisystem und seinen Kommentar darunter]

Ja, und... ??

Noch mal zum mitschreiben:
Der TE hat das Suse mit btrfs-Dateisystem auf der zweiten Platte sdb installiert gehabt. Dessen Grub2 war im MBR von sda.
Später hat er mga4 installiert und dessen Grub2 hat den von Suse gekillt, weil er nicht darauf geachtet hat, den in den PBR von / installieren zu lassen.
Nun wollte er gern aber den von Suse wieder haben (als Hauptbootloader seines Multibootsystems) und hat dabei festgestellt, der läßt sich innerhalb der Bordmittel von Suse nicht wieder unter btrfs in sda installieren, unter ext4 aber schon.

Könntet Ihr das auf euren Kisten mal nachvollziehen?
Ich mag mir Suse genau so wenig, wie *buntu, auf meinen Kisten antun!

Öhmm, entweder steh ich auf dem Schlauch, aber grub wird doch in den MBR installiert, und nicht in ein Dateisystem?
Die Installation sollte sich doch per chroot von Mageia in die SuSe-Installation händisch nochmal nachziehen lassen ...

doktor5000 hat geschrieben:Öhmm, entweder steh ich auf dem Schlauch, aber grub wird doch in den MBR installiert, und nicht in ein Dateisystem?

Beides:
boot.img = MBR
<alle anderen>.img = /boot/grub
Quelle: http://www.gnu.org/software/grub/manual ... stallation (Chap 10, Second Headline)

Ja, der letztere Teil ist schon klar. Wobei dazwischen eigentlich noch stage 1.5 liegt, welche zwischen MBR und 1. Partition geschrieben wird.

Was den Fehler angeht (stage 1.5 error 18) das scheint mir kein Problem vom Zieldateisystem zu sein, siehe u.a.
http://www.gnu.org/software/grub/manual ... 2e5-errors
http://members.iinet.net.au/~herman546/p15.html#18
https://launchpad.net/ubuntu/+source/gr ... /+bug/9006

unklar hat geschrieben:

unklar hat geschrieben:Lösung wäre also MGA auf sda zu installieren.

Nach hier könntest Du das schnapp ab auch durch eine Um-Partitionierung von sdb erreichen. Dazu müßtest die Swap (sdb1) an das Ende der Platte platzieren. Also würde das so aussehen:

sdb1 = /
sdb2 = Extended
sdb5 = /home
sdb6 = swap

Gerschon hat geschrieben:Auf sdb ist Mageia 4.1, wobei sdb1 Swap ist, sdb5 / ist und /sdb6 /home ist.
...
Hier vom jetzigen Rechner die Grub-Einträge in menu.lst:

In der menu.lst kann ich keine mga4.1 erkennen.

Habe es nun so gemacht.

Festplatten getauscht, dh. Slave zu Master und Master zu Slave.
(Ist noch kein SATA System diese beiden 120 GB Platten!)

Dann so installiert wie vorgeschlagen, nur das dies halt dann auf sda passiert ist.
Hatte hier alle Partitionen gelöscht und neu angelegt.
(Einfach dem Linux den Vorzug gegeben, was es ja auch verdient )
Jetzt läuft es wieder und anscheinend gut, da frisch installiert.
Bei der Gelegenheit wurden dann auch dann gleich die überflüssigen Einträge im Bootmenü gelöscht.

Noch als kleine Anmerkung:
Grub2 hat die desighnetscheidung gemach nicht nur den Dateisystemtreiber sondern auch große Teile des restes von Grub (das gesamte kernel.img) in core.img zu legen. Das liegt nach dem MBR aber vor der ersten Partition. (Da wo im Grub der Stage 1.5 lag.)

Problem: So ein kernel.img hat typischerweise so ~20K. So ein ext Treiber ist so ~6K => Insgseamt 26K.
Problem: btrfs_Treiber: 15K 20K+15K=35K du hast aber auf sda nur 31,8K Platz. (Und das ist Über Jahrzehnte so die standardkonfiguration gewesen.)
Mit LZMA kompression bekommt man das dann weit genug runter. Aber dazu braucht man erstmal einen Grub der das kann. Und ein Konfigurationstool, dass dann auch -C xz anhängt.