Univention Bugzilla – Bug 21988
Falscher Masterboot-Record in UCS-Installation bei automatischer Partitionierung
Last modified: 2011-12-13 15:49:14 CET
scheinbar wird grub nicht korrekt installiert (siehe oben); im univention-installer setzt die automatisch Partitionierung xvda als Festplatte, anschließend schlägt der Bootloader als Gerät für den Master-Boot-Record xvdb vor. Das Problem konnte für paravirtualisierte Xen-Instanzen reproduziert werden und scheint unabhängig von der Virtualisierungsart der Festplatte/des CD-Rom-Laufwerkes zu sein. Es wurde das Image ucs_2.4-0-20110302134649-dvd-amd64.iso verwendet. Auf einem solchen System scheint xvdb als erste Festplatte erkannt zu werden: > $ cat /proc/partitions > major minor #blocks name > 202 16 2716248 xvdb > 202 0 20971520 xvda > 202 1 208813 xvda1 > 202 2 1020127 xvda2 > 202 3 19735852 xvda3 > 254 0 19300352 dm-0 ==================== <domain type='xen' id='21'> <name>test3_ucs_pv_dev_pv</name> <uuid>73bc9db0-ec0d-0f60-6af2-bece317c6183</uuid> <memory>524288</memory> <currentMemory>524288</currentMemory> <vcpu>1</vcpu> <bootloader>/usr/bin/pygrub</bootloader> <bootloader_args>-q</bootloader_args> <os> <type>linux</type> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> <disk type='file' device='cdrom'> <driver name='tap' type='aio'/> <source file='/var/lib/libvirt/images/ucs_2.4-0-20110302134649-dvd-amd64.iso'/> <target dev='xvdb' bus='xen'/> <readonly/> </disk> <disk type='file' device='disk'> <driver name='tap' type='aio'/> <source file='/var/lib/libvirt/images/test_ucs_pv_dev_pv-0.raw'/> <target dev='xvda' bus='xen'/> </disk> <interface type='bridge'> <mac address='00:16:3e:ef:9b:62'/> <source bridge='eth0'/> <script path='/etc/xen/scripts/vif-bridge'/> <target dev='vif21.0'/> </interface> <console type='pty' tty='/dev/pts/0'> <source path='/dev/pts/0'/> <target type='xen' port='0'/> </console> <input type='mouse' bus='xen'/> <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0' keymap='de'/> </devices> </domain> ====================
Mir war hier am Rande aufgefallen, dass ein CDROM-Laufwerk in XEN immer xvdb wird, auch wenn man die XML händisch verändert. Außerdem wird der MBR auch auf xvdb angelegt, wenn sich mehrere Festplatten(xvdc, xvdd, etc.) im System befinden
(In reply to comment #0) > Auf einem solchen System scheint xvdb als erste Festplatte erkannt zu werden: > > $ cat /proc/partitions > > major minor #blocks name > > 202 16 2716248 xvdb > > 202 0 20971520 xvda > > 202 1 208813 xvda1 > > 202 2 1020127 xvda2 > > 202 3 19735852 xvda3 > > 254 0 19300352 dm-0 ... > <disk type='file' device='cdrom'> > <target dev='xvdb' bus='xen'/> > </disk> > <disk type='file' device='disk'> > <target dev='xvda' bus='xen'/> > </disk> In univention-installer/installer/modules/15_bootloader.py#layout() wird immer der 1. Eintrag aus /proc/partitions als Installationsziel für Grub extrahiert. Bei einer Xen-PV-Installation steht dort als erstes immer das _momentane_ Boot-Device, was zum Installationszeitpunkt natürlich das CDROM-Laufwerk ist. Danach folgen dann alle weiteren Laufwerke. Das war IMHO schon vor 2.4-2-Zeiten so, aber ggf. siehe auch Bug #21938. Sinnvoll wäre es hier, das Device zu übergehen, daß dem Installationsmedium entspricht → cdrom_device
Der Installer überprüft nun anhand von /sys/block/*/capability und /sys/block/*/ro, ob das Block-Device ein CDROM oder eine Read-Only-Medium ist. Falls einer der Tests wahr ist, wird das Block-Device nicht im Partitonierungsdialog angezeigt. Nebenbei wurden auch noch einige Fehler in der Konfiguration für Xen korrigiert, da /proc/xen auch auf System vorhanden ist, die nicht Xen-fähig sind. Statt dessen wird nun explizit für die Konsole auf /dev/hvc0 und für die Block-Devices /sys/block/* getestet. Weitere kleine Anpassungen: - fehlerhaftes Shell-Redirekt für Fehlermeldungen korrigiert - fehlende Abhängigkeiten in debian/rules ergänzt - locale-Fehlermeldungen unterdrückt - Dokumentation für Entwickler ergänzt svn28368..28374, univention-installer_7.0.124-1.894.201110261927 ChangeLog: svn10554 \item The installer now ignores block devices for partitioning, which are detected as CD-ROM or read-only block devices (\ucsBug{21988}).
<schwardt> PARTITION:1531: Error querying vdc/ro: [Errno 2] Datei oder Verzeichnis nicht gefunden: '/sys/block/%s/ro' fn = '/sys/block/%s/ro' f = open(fn, 'r')
Der Platzhalter wird nun korrekt mit dem Basisnamen des Block-Devices ausgefüllt. Erfolgreich getestet auf in einer kvm-Instanz. svn29050, univention-installer_7.0.143-1.916.201111111057 ChangeLog: ±0
Auf einer VM mit zwei Festplatten und einem CDROM (Xen paravirtualisiert) tritt der folgende Installer Traceback auf: Traceback (most recent call last): File "main.py", line 743, in <module> elif next_screen(): File "main.py", line 638, in next_screen installer.obj[installer.current].postrun() File "10_hardware.py", line 179, in postrun self.sub.draw() File "objects.py", line 2177, in draw self.function() File "10_hardware.py", line 439, in function self.parent.debug('cdrom_device=%s' % self.parent.container['cdrom_device']) KeyError: 'cdrom_device'
Exakt den gleichen Traceback hatte ich in einer ähnlichen Konstellation auch schon mal. Ursache ist, das in der Schleife kein Installationsmedium gefunden wird (bei mir damals wegen zu langsamer Erkennung des USB-Sticks). Direkt nach der Schleife wird dann die Fundstelle für das Febugging ausgegeben, was dann fehlschlägt.
(In reply to comment #7) > Exakt den gleichen Traceback hatte ich in einer ähnlichen Konstellation auch > schon mal. > Ursache ist, das in der Schleife kein Installationsmedium gefunden wird (bei > mir damals wegen zu langsamer Erkennung des USB-Sticks). Direkt nach der > Schleife wird dann die Fundstelle für das Febugging ausgegeben, was dann > fehlschlägt. OK, das passt, es war eine paravirtualisierte Xen 4.1 Installation: Bug #18357 Comment #18. Dann mache ich die QA erneut, wenn der Bug durch ist.
Die Installation einer Xen-PV-Domain mit 2 HD scheitert derzeit daran, das in der chroot-Umgebung viele Prozesse mit einem SegFault enden: # chroot /instmnt bash Segmentation fault # dmesg [ 275.760324] cat[19756]: segfault at 0 ip (null) sp 00007fff88b15228 error 14 in cat[400000+b000] [ 275.916792] stty[19766]: segfault at 0 ip (null) sp 00007fffb5a94f98 error 14 in stty[400000+f000] [ 275.920032] stty[19768]: segfault at 0 ip (null) sp 00007fff9bcce2a8 error 14 in stty[400000+f000] [ 275.939440] cat[19783]: segfault at 0 ip (null) sp 00007fff52155b18 error 14 in cat[400000+b000] [ 276.040536] cat[19810]: segfault at 0 ip (null) sp 00007fff54361ac8 error 14 in cat[400000+b000] [ 276.138275] stty[19821]: segfault at 0 ip (null) sp 00007fff469cc168 error 14 in stty[400000+f000] [ 276.141626] stty[19823]: segfault at 0 ip (null) sp 00007fffd8e2c298 error 14 in stty[400000+f000] [ 276.162435] cat[19838]: segfault at 0 ip (null) sp 00007fff1a3b5dc8 error 14 in cat[400000+b000] [ 276.439150] cat[19905]: segfault at 0 ip (null) sp 00007fffb7228998 error 14 in cat[400000+b000] [ 276.525016] stty[19916]: segfault at 0 ip (null) sp 00007fff08fe5438 error 14 in stty[400000+f000] [ 281.077524] __ratelimit: 52 callbacks suppressed [ 281.077528] dpkg-deb[20269]: segfault at 0 ip (null) sp 00007fff64fc8618 error 14 in dpkg-deb[400000+1f000] [ 281.080211] dpkg-deb[20271]: segfault at 0 ip (null) sp 00007fff837ae318 error 14 in dpkg-deb[400000+1f000] [ 281.082732] dpkg-deb[20273]: segfault at 0 ip (null) sp 00007fff8dcafa68 error 14 in dpkg-deb[400000+1f000] [ 281.085367] dpkg-deb[20275]: segfault at 0 ip (null) sp 00007fff609953f8 error 14 in dpkg-deb[400000+1f000] [ 281.087859] dpkg-deb[20277]: segfault at 0 ip (null) sp 00007fffa4861bd8 error 14 in dpkg-deb[400000+1f000] [ 281.090406] dpkg-deb[20279]: segfault at 0 ip (null) sp 00007fff1ad10328 error 14 in dpkg-deb[400000+1f000] [ 281.092980] dpkg-deb[20281]: segfault at 0 ip (null) sp 00007ffff2b66a08 error 14 in dpkg-deb[400000+1f000] [ 281.095501] dpkg-deb[20283]: segfault at 0 ip (null) sp 00007fffdaf86e58 error 14 in dpkg-deb[400000+1f000] [ 281.098041] dpkg-deb[20285]: segfault at 0 ip (null) sp 00007fff70e911b8 error 14 in dpkg-deb[400000+1f000] [ 281.100597] dpkg-deb[20287]: segfault at 0 ip (null) sp 00007ffff35ae3b8 error 14 in dpkg-deb[400000+1f000] Dadurch wird grub nicht installiert; /instmnt/boot bleibt bis auf boot.msg leer. # pygrub --debug /var/lib/libvirt/images/ucs30-64-test-pv-0.raw Traceback (most recent call last): File "/usr/bin/pygrub", line 776, in <module> chosencfg = run_grub(file, entry, fs, incfg["args"]) File "/usr/bin/pygrub", line 567, in run_grub g = Grub(file, fs) File "/usr/bin/pygrub", line 220, in __init__ self.read_config(file, fs) File "/usr/bin/pygrub", line 424, in read_config raise RuntimeError, "couldn't find bootloader config file in the image provided." RuntimeError: couldn't find bootloader config file in the image provided. Traceback (most recent call last): File "/usr/bin/pygrub", line 768, in <module> fs = fsimage.open(file, offset, bootfsoptions) IOError: [Errno 95] Operation not supported Traceback (most recent call last): File "/usr/bin/pygrub", line 768, in <module> fs = fsimage.open(file, offset, bootfsoptions) IOError: [Errno 95] Operation not supported Traceback (most recent call last): File "/usr/bin/pygrub", line 794, in <module> raise RuntimeError, "Unable to find partition containing kernel" RuntimeError: Unable to find partition containing kernel # gdb /bin/chroot ) set args /instmnt /bin/bash ) run Program received signal SIGSEGV, Segmentation fault. ) bt #0 0x0000000000493d20 in rl_function_of_keyseq () #1 in rl_bind_keyseq_if_unbound_in_map () #2 in ?? () #3 in _rl_init_terminal_io () #4 in _rl_set_screen_size () #5 in get_net_window_size () #6 in get_tty_state () #7 0x0000000000420f31 in main () Der folgende Aufruf zeigt, das mehrere Dateien eine andere Checksumme haben, als sie laut Paketdatei haben müssten: # md5sums -c /var/lib/dpkg/info/bash.md5sums Welche Dateien sich genau unterscheiden unterscheidet sich von Installationsversuch zu Installationsversuch. Von daher vermute ich hier erstmal ein Problem mit den bltap2-Prozessen!
Da das Auftreten der Speicherkorruption bisher nur auf einen Rechnertyp begrenz ist, wird das getrennt über Bug #25102 weiterbearbeitet. Ansonsten funktioniert die Installation auch bei mehreren PV-Platten problemlos.
Die Installation eines 3.0 Gast mit mehreren Festplatten und der anschließende Boot + Anmeldung funktioniert bei mir problemlos.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"