Alternative für Grub2 die XEN starten kann

[minimike]

Hi

Ich suche gerade eine Alternative für Grub2 die XEN starten kann. Gibt es da überhaupt was?

Vorrausgegangen ist das ich Debian mit Hilfe von GRML und debootstrap in ein BTRFS Subvolume installiert habe. Einfach um unter Anderem auch die Option zu haben, mehrere Systeme auf dem selben FS zu haben. So wie man das von FreeBSD und Solaris mit ZFS halt gewohnt ist.
Unter Debian kommt im Userland Grub2 aber mit der Konstellation gar nicht klar. Ich habe eine kleine EXT3 partition für /boot und Grub2 ist im MBR installiert. Booten to ich das in dem ich dann im Grubpromt die passenden Parameter eintippe. Eine automatische Konfiguration unter Debian scheint nicht möglich.

[rendegast]

Code: Alles auswählen

$ apt-cache search btrfs
btrfs-tools-dbg - Checksumming Copy on Write Filesystem utilities (debug)
btrfs-tools - Checksumming Copy on Write Filesystem utilities
...
extlinux - collection of boot loaders (ext2/3/4 and btrfs bootloader)
syslinux-common - collection of boot loaders (common files)
syslinux - collection of boot loaders

-----------------------------------------------------------------------

in ein BTRFS

Code: Alles auswählen

$ cat /boot/grub/fs.lst 
affs
afs
afs_be
befs
befs_be
cpio
ext2
fat
hfs
hfsplus
iso9660
jfs
minix
nilfs2
ntfs
pxe
reiserfs
sfs
tar
udf
ufs1
ufs2
xfs
zfs

$ ll *fs*
-rw-r--r-- 1 root root  4580 11. Feb 10:26 affs.mod
-rw-r--r-- 1 root root  4880 11. Feb 10:26 afs.mod
-rw-r--r-- 1 root root  4896 11. Feb 10:26 afs_be.mod
-rw-r--r-- 1 root root  4768 11. Feb 10:26 befs.mod
-rw-r--r-- 1 root root  4796 11. Feb 10:26 befs_be.mod
-rw-r--r-- 1 root root   128 11. Feb 10:26 fs.lst
-rw-r--r-- 1 root root  2764 11. Feb 10:26 fshelp.mod
-rw-r--r-- 1 root root  6028 11. Feb 10:26 hfs.mod
-rw-r--r-- 1 root root  5892 11. Feb 10:26 hfsplus.mod
-rw-r--r-- 1 root root  5832 11. Feb 10:26 jfs.mod
-rw-r--r-- 1 root root  6676 11. Feb 10:26 nilfs2.mod
-rw-r--r-- 1 root root  9996 11. Feb 10:26 ntfs.mod
-rw-r--r-- 1 root root  3548 11. Feb 10:26 ntfscomp.mod
-rw-r--r-- 1 root root  9868 11. Feb 10:26 reiserfs.mod
-rw-r--r-- 1 root root  2168 11. Feb 10:26 search_fs_file.mod
-rw-r--r-- 1 root root  2312 11. Feb 10:26 search_fs_uuid.mod
-rw-r--r-- 1 root root  4104 11. Feb 10:26 sfs.mod
-rw-r--r-- 1 root root  4684 11. Feb 10:26 ufs1.mod
-rw-r--r-- 1 root root  5000 11. Feb 10:26 ufs2.mod
-rw-r--r-- 1 root root  5844 11. Feb 10:26 xfs.mod
-rw-r--r-- 1 root root 24400 11. Feb 10:26 zfs.mod
-rw-r--r-- 1 root root  6208 11. Feb 10:26 zfsinfo.mod

Nix btrfs.

eine kleine EXT3 partition für /boot

Auch ein Subvolume?
Fehlt noch 'insmod part_bsd' o.ä.?

Code: Alles auswählen

$ ll *part*
-rw-r--r-- 1 root root 2372 11. Feb 10:26 msdospart.mod
-rw-r--r-- 1 root root 1688 11. Feb 10:26 part_acorn.mod
-rw-r--r-- 1 root root 1672 11. Feb 10:26 part_amiga.mod
-rw-r--r-- 1 root root 2112 11. Feb 10:26 part_apple.mod
-rw-r--r-- 1 root root 2004 11. Feb 10:26 part_bsd.mod
-rw-r--r-- 1 root root 2276 11. Feb 10:26 part_gpt.mod
-rw-r--r-- 1 root root 2100 11. Feb 10:26 part_msdos.mod
-rw-r--r-- 1 root root 1788 11. Feb 10:26 part_sun.mod
-rw-r--r-- 1 root root 1704 11. Feb 10:26 part_sunpc.mod
-rw-r--r-- 1 root root   82 11. Feb 10:26 partmap.lst
-rw-r--r-- 1 root root   17 11. Feb 10:26 parttool.lst
-rw-r--r-- 1 root root 4488 11. Feb 10:26 parttool.mod

Eine automatische Konfiguration unter Debian scheint nicht möglich.

Erstellte grub.cfg?

[minimike]

Nein es sind zwei Partitionen. Einmal GPT partitioniert mit 200 MB für ext3 und dann den Rest mit 2 TB für BTRFS.
Die Skripte schlagen fehl weil sie /dev nicht finden. Es wäre mir zu müssig das alles zu entschärfen, Sicher sind die schön tief im System verteilt.
Darum wäre eine Alternative für Grub nicht verkehrt

[rendegast]

EDIT dieses Post habe ich in der falschen Annahme geschrieben,
daß ein (btrfs-) subvolume == BSD-Partition (in einem slice) ist.
Sorry.
------------------------------------------------------------------------------

Debian mit Hilfe von GRML und Debiandebootstrap in ein BTRFS Subvolume

Nein es sind zwei Partitionen. Einmal GPT partitioniert mit 200 MB für ext3 und dann den Rest mit 2 TB für BTRFS.

Müssen bei GPT immer noch Subvolumes benutzt werden?

Welche Id hat das BSD-Slice?
Auf einem normalen Nicht-GPT-Image kann zBsp. fdisk mit Id a6 (OpenBSD) keine BSD-Partitionen anlegen.

Die Partition beginnt etwas hinter dem slice?
Nicht daß btrfs das BSD-Label zerstört.
(Passiert zBsp. mit einem ext4fs, nach der Formatierung sind das bsd-Label und die Partitionen weg.
Einen Zylinder freizulassen scheint bei einer klassischen Adressierung zu genügen.)

Hat update-grub kein 'insmod part_gpt' gesetzt?
Zusätzliche Module können über GRUB_PRELOAD_MODULES eingebunden werden, siehe 00_header.



Welche manuellen Zusätze meinst Du?
IMO sollte grub nichts Besonderes brauchen, um den Kernel von /boot zu starten.
Um die BSD-Partitionen zu erkennen, braucht es nur part_bsd,
dann zBsp. 'root (hd2,msdos2,bsd1)'.
Jedoch erfolgt der Zugriff auf das btrfs ja schon mit dem Kernel.




------------------------------
Nebenbei, 'update-grub' beschwert sich wortreich über die (obsolete) 4te BSD-Partition d:
(von fdisk per default angelegt).
Nach deren Löschung verschwinden die Warnungen.

[minimike]

Ich habe GRUB im MBR instaliert. Evtl. habe ich mich missverständlich ausgedrückt. OK die Installation gelingt nur von einem Chroot aus. Jedenfalls ich kann Linux damit starten. Problem ist nur das Debian GRUB automatisch konfigurieren lässt. Sobald ich in init 3 bin und mit Grub arbeiten will schlagen die Skripte (grub-mkconfig) völlig fehl. Bei jedem Update von Kerneln oder Grub werde ich deshalb Probleme bekommen.
Gerne kann ich dir die TestVM überlassen

[rendegast]

Nun weiß ich endlich, was mit "subvolume" gemeint war.
Ich habe diese als die BSD-Partitionen in einer herkömmlichen primären Partition aufgenommen,
das gab Anlaß zur Verunsicherung, siehe oben.
BTRFS/
BTRFS/debian6/ (subvolume mit squeeze/64)

Nein es sind zwei Partitionen. Einmal GPT partitioniert mit 200 MB für ext3 und dann den Rest mit 2 TB für BTRFS.

Also ganz gewöhnlich GPT-partitioniert, sda1 = ext3fs, sda2 = btrfs.
--------------------------------------------------------------------------------------





Zuerst fällt im Image auf, daß die grub.cfg leer war,
und in /boot/ eine Datei "o=" vorliegt.

Das lag wohl daran:

Code: Alles auswählen

# update-grub
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted ?).
#
# /usr/sbin/grub-probe -d /dev/sda2
/usr/sbin/grub-probe: error: unknown filesystem.
#
# mount
/dev/sda2 on / type btrfs (rw,subvol=debian6)
...

( liegt wohl am grub2 = (noch-)Nix-btrfs )

Falls diese (Haupt-)Hürde genommen würde
kommt das Problem, daß
BTRFS/update-grub
BTRFS/debian6/update-grub
mit anderen Parametern in dieselbe grub-cfg schreiben.
Läßt sich wohl mit 'update-grub -o andere_grub.cfg' umschiffen.

Weiterhin machen die update-initramfs dieselbe initrd,
aber mit unterschiedlich gespeicherten md5-Summen.

Eine weitere organisatorische Schwierigkeit sehe ich darin,
daß das linux im subvolume ja auch ein eigenes System darstellt, das gesondert gepflegt werden will.
Möglichkeit: Gelegentliche 'chroot /debian6' -> 'apt-get [update|upgrade]'


Idee:
Für jedes subvolume-System ein eigenes /boot*/grub*/-Verzeichnis in /dev/sda1
('GRUB_PREFIX' in den jeweiligen /etc/default/grub, weiterhin 'BOOTDIR' und '$image_dir'),
Die Verbindung ins nächste /boot*/grub*/ über einen include-Eintrag in der /boot*/grub*/custom.cfg.




-----------------------------
Nebenbei, der Kernel 2.6.37 (sid) ist zu empfehlen,
denn mit dem squeeze 2.6.32-5 bekomme ich keine Ausgabe bei 'btrfs subvolume list'.
-----
Ich kämpe auf meinem squeeze/32 zunächst mal damit,
daß 'qemu-system-x86_64 -enable-kvm' bei mir nicht funktioniert.
Also laufen meine Versuche derzeit ermüdend langsam ab.
(Ein ähnlich aussehendes Versagen von kvm bei der antivir-rescue-cd unter 2.6.3[56]
habe ich mit kvm_amd.npt=0 umschiffen können,
hier klappt dieser Trick aber leider nicht.)

[minimike]

Hi

Das o= hat technische Gründe. Unter Fedora 14, sofern sich ein US Keyboard in einer VM befindet bekomme ich mit der deutschen Tastatur keine = Zeichen hin. In Grub /o und TAB gibt dann /o= in der Grubshell. Das /o vor dem = Löschen und ich habe mein = Zeichen.
Elegantere Lösungen erfordern mehr an Arbeit

Im Prinziep könnte man eine Datei in /etc löschen oder mit einer leeren ersetzen. Ab da muss dann jeder Eintrag von Hand mit dem vim gemacht werden. Damit erspart sich bei der Installation/Upgrade von Kerneln diverse Fehler mit APT.
Allerdings auch nicht wirklich elegant.

Was mich wundert ist das unter ZFS eine ähnliche Problematik besteht aber Debian kFreeBSD das perfekt gelöst hat. Auch wenn Debian mit dem booten via Grub sehendes Auges ein Mangel an Funktion im FreeBSD Kernel in Kauf nimmt

[rendegast]

Im Prinziep könnte man eine Datei in /etc löschen oder mit einer leeren ersetzen. Ab da muss dann jeder Eintrag von Hand mit dem vim gemacht werden. Damit erspart sich bei der Installation/Upgrade von Kerneln diverse Fehler mit APT.
Allerdings auch nicht wirklich elegant.

Was mich wundert ist das unter ZFS eine ähnliche Problematik besteht aber Debian kFreeBSD das perfekt gelöst hat. Auch wenn Debian mit dem booten via Grub sehendes Auges ein Mangel an Funktion im FreeBSD Kernel in Kauf nimmt

Ich denke, Du möchtest hier eine Funktion, die Du auf einer herkömmlichen Maschine
MBR+boot-Partition - debian - fedora - suse
nicht vorraussetzen würdest: Daß alle Betriebssysteme dasselbe /boot benutzen.
(IMO weder mit lilo noch grub eine gute Idee)
grub1 hat die Funktionalität (entsprechendes FS vorrausgesetzt), IN der Partition installierbar zu sein.
grub2 hatte das zu Anfang gar nicht, mittlerweile mit 'force' möglich, aber IMO noch im Experimentierstadium.
btrfs ist auch noch im Experimentierstadium, also erst recht auch das Zusammenspiel grub2+btrfs.
Aber es ist ja glücklicherweise Work-in-Progress, siehe obiges Beispiel zu 'btrfs subvolume list' unter 2.6.32 -> 2.6.37.

Speziell hier aber würde das grub-Feature "In-der-Partiton" nicht weiterhelfen,
da es dennoch Zugriff auf den Startsektor benötigt,
was hier im Falle eines Betriebssystems aus dem Subvolume (technisch ein Unterverzeichnis / im praktischen Fall eventuell eine Art chroot für eine virtuelle Maschine ala openvz oder vserver) wohl auch gar nicht wünschenswert wäre.




OffTopic

Unter Fedora 14, sofern sich ein US Keyboard in einer VM befindet bekomme ich mit der deutschen Tastatur keine = Zeichen hin.

Auch nicht mit der ´-Taste oder +*~-Taste?