Univention Bugzilla – Bug 25183
Booten von Systemen mit Software-RAID nicht möglich
Last modified: 2017-08-08 07:07:22 CEST
Ich kann UCS 3.0 mit Software-RAID installieren, die Systeme booten aber nicht mehr wenn die erste Platte entfernt wird (obwohl GRUB in den MBR aller Platten geschrieben wurde). Ich habe das ganze nur in KVM getestet, dort gibt es entweder "no such disk" (/boot auf LVM in RAID5) Meldungen oder Boot-Loops vom SeaBIOS (/boot auf RAID1). Details zu einer Test-Installation an bug25169
grub2 in Version 1.98 (squeeze-Version) enthält noch sehr viele RAID-/LVM- spezifische Bugs, die eine korrekte Funktion im genannten Szenario verhindern. Besonders ärgerlich ist, dass grub2 zunächst zu funktionieren scheint, fehlt jedoch die erste Festplatte aus dem RAID-Verbund, kann das System nicht mehr ohne BootCD gestartet werden. Eine aktualisierte Grub-Version sollten wir mit UCS 3.1 ausliefern. Getestete Szenarien (mit 1.98): Szenario 1) - 4 Festplatten - auf jeder Festplatte eine Partition ab Zylinder 1 mit Typ "fd" (Linux raid autodetect) - RAID 5 über alle 4 Partitionen - auf dem RAID 5 wurde ein LVM mit rootfs angelegt → Grub2 1.98 bootet, solange die erste Platte vorhanden ist, sonst erscheint nur die grub rescue shell → Grub2 1.99 lässt sich nur dann installieren, wenn die Partition nicht bei Zylinder 1 anfängt (Cyl > 1). Zwischen MBR und Beginn der ersten Partition müssen mehr als 32KiB Platz sein, um das core.img von Grub dort unterzubringen. Da für das Booten sowohl RAID, RAID5 und LVM benötigt wird, ist das core.img ein paar Bytes größer als 32KiB und kann nicht installiert werden. Wird der Partitionsanfang um einen Zylinder (ca. 8MB) nach hinten verschoben, bootet das System (von allen Platten). Szenario 2) - 4 Festplatten - auf jeder Festplatte zwei Partitionen mit Typ "fd" (Linux raid autodetect) - RAID 1 (mirroring) über die jeweils erste Partitionen jeder Festplatte - RAID 5 über die jeweils zweite Partitionen jeder Festplatte - auf dem RAID 5 wurde ein LVM mit rootfs/ext3 angelegt - auf dem RAID 1 wurde ein ext3 mit /boot angelegt → Grub2 1.98 bootet nicht → Grub2 1.99 lässt sich nur dann installieren, wenn die Partition nicht bei Zylinder 1 anfängt (Cyl > 1). Zwischen MBR und Beginn der ersten Partition müssen mehr als 32KiB Platz sein, um das core.img von Grub dort unterzubringen. Da für das Booten sowohl RAID, RAID5 und LVM benötigt wird, ist das core.img ein paar Bytes größer als 32KiB und kann nicht installiert werden. Wird der Partitionsanfang um einen Zylinder (ca. 8MB) nach hinten verschoben, bootet das System. → Achtung! Grub2 1.99 war unter VMWare in eine Dauerbootschleife gefallen, wenn die erste Platte entfernt wurde Debian-Changelogeintrag von grub2 1.99 (wheezy): grub2 (1.99-1) unstable; urgency=low . * New upstream release. - Ensure uniqueness of RAID array numbers even if some elements have a name (closes: #609804). - Remove unnecessary brackets from tr arguments (closes: #612564). - Add grub-mkrescue info documentation (closes: #612585). - Avoid generating invalid configuration when something that looks like a Xen hypervisor is present without any Xen kernels (closes: #612898). - Fix memory alignment when calling 'linux' multiple times on EFI (closes: #616638). - Fix grub-install on amd64 EFI systems (closes: #617388). - Automatically export pager variable (closes: #612995). - Fix parser error with "time" (closes: #612991). - Ignore case of bitmap extensions (closes: #611123). - Skip vmlinux-* on x86 platforms (closes: #536846, #546008). - Accept old-style Xen kernels (closes: #610428). - Skip damaged LVM volumes (closes: #544731). - Handle LVM mirroring (closes: #598441). - Detect spares and report them as not RAID members (closes: #611561). - Don't enable localisation unless gfxterm is available (closes: #604609). - Fix partitioned RAID support (closes: #595071, #613444). - Dynamically count the number of lines for the lower banner (closes: #606494). - Improve quoting in grub-mkconfig, to support background image file names containing spaces (closes: #612417). - Flush BIOS disk devices more accurately (closes: #623124). - Identify RAID devices by their UUID rather than by their guessed name (closes: #624232). - Add "SEE ALSO" sections to most man pages (closes: #551428).
Warten bis die UEFI Erweiterungen durch sind.
Nochmal unter vmware-server mit grub2 in Version 1.98 (squeeze-Version) angetestet: - vier 8GB-Platten - Partitionierung mit GPT: - 8MB BIOS-Boot (ef02) - 256MB RAID1 (8e00) für /boot - Rest RAID5 (8e00) für LVM (inkl. rootfs) RAID1 über alle 4 Platten mit mdadm-1.2-Metadaten für /boot. RAID5 über alle 4 Platten mit mdadm-1.2-Metadaten für LVM. Auf dem LVM ein rootfs. ucr set installer/device/0/name=/dev/mapper/vg_ucs-rootfs installer/device/0/fs=ext3 installer/device/0/mp=/ installer/device/1/name=/dev/md0 installer/device/1/fs=ext3 installer/device/1/mp=/boot Nach der Installation das System booten und folgende Befehle ausführen: update-grub grub-install /dev/sda grub-install /dev/sdb grub-install /dev/sdc grub-install /dev/sdd System bootet, sofern nicht die erste Festplatte fehlt. Der Grub lädt dann zwar einige Grub-Module nach und sucht nach Devices, VMWare bootet dann aber die Instanz neu. Ursache unbekannt.
(In reply to comment #3) > System bootet, sofern nicht die erste Festplatte fehlt. Der Grub lädt dann zwar > einige Grub-Module nach und sucht nach Devices, VMWare bootet dann aber die > Instanz neu. Ursache unbekannt. Gleiches Verhalten unter KVM. rootfs auf LVM auf RAID5 mit fehlender /dev/vda führt zu Bootschleife im Grub.
Sollten / und/oder /boot auf einem Software-RAID vorhanden sein, kann es Probleme beim Booten mit GRUB geben, wenn die erste Festplatte (hda/vda/sda) nicht mehr vorhanden ist. Sollte eine andere Festplatte aus dem RAID-Verbund fehlen, hat GRUB i.d.R. keine Probleme das System zu booten, sofern genügend Devices für den RAID-Level vorhanden sind. Sollte die erste Festplatte fehlen, kann der GRUB mit einer UCS-Installations-DVD leicht wieder repariert werden: - UCS-Installations-DVD booten und Sprache/Keyboadlayout auswählen - ALT-F2 - mdadm --assemble --scan pvscan vgchange -ay /bin/mount /dev/$ROOTFSDEVICE /mnt /bin/mount /dev/$BOOTDEVICE /mnt/boot cd /mnt /bin/mount -o bind /dev dev /bin/mount -o bind /sys sys /bin/mount -o bind /proc proc chroot . /bin/bash update-grub grub-install /dev/$ERSTE_NOCH_FUNKTIONIERENDE_PLATTE grub-install /dev/$ZWEITE_NOCH_FUNKTIONIERENDE_PLATTE ... exit umount /mnt/boot umount /mnt/dev umount /mnt/sys umount /mnt/proc umount /mnt sync reboot
Über Bug 29445 wurde grub 1.99 importiert. Zusammen mit der neuen Version und der BIOS-Boot-Partition, die jetzt für GRUB angelegt wird, dürfte es erstmal zu keinen Platzproblemen mehr kommen. Es ist jetzt zu testen, ob GRUB 1.99 jetzt auch mit einer fehlenden primären Festplatte im RAID1-Verbund zurechtkommt.
Aufgrund von Problemen mit Grub 1.99 wurde in UCS 3.1 wieder die Grub-Version 1.98 ausgeliefert (Ausnahme ist die UEFI-DVD; hier wird Grub1.99 verwendet).
Dies wurde intensiv mit Bug 31111 in Vmware und auf Hardware getestet und konnte nicht nachgestellt werden.
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
This issue has been filed against UCS 3.0. UCS 3.0 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen this issue. In this case please provide detailed information on how this issue is affecting you.