Bug 724713

For me yast crashes and leaves the install file systems mounted.

Bug 723777 maybe?

Please stop assigning everything to me you don't want!
There's no indication that this is a duplicate of bnc #723777 other than Steffen's wild guess. I don't know enough about YaST's internal voodoo to be able to debug this any further.

Please provide YaST logs, see http://en.opensuse.org/openSUSE:Bugreport_YaST.
Also /var/log/messages and /var/log/Xorg-logging might be useful.

Created attachment 457289 [details]
Xorg log

There you go. Xorg segfault.

I'm just about reproducing it again.

All virtual consoles other than vt7 with the X server for installation are dead. vt1 contains garbage, the other ones are just black. vt1 displays already at the beginning of installation the garbeled screen I reported.

Since the text consoles are inoperational, I cannot look at anything during installation. I have to let it crash, then open the filesystem with "Rettungssystem" and see whatever logfiles from the installation might be left over. If you have any suggestions where to look, I will be faster in providing it.


BTW Booting and shutdown of a 12.1b1, once you have installed it, seem to have improved so much in speed, that KDE startup starts to look pretty slow in comparision. Nice job!

For some reason the first try of reproduction today failed. Behaviour changed. It did not hang after trying kexec, but I found it in a real reboot. It went back to the CD, and in the Boot menu "Boot from Harddisk" worked flawlessly. Yesterday, when resetting the VM, rebooting from the virtual disk did not work. The boot loader just hung. These are surprises, after it was hanging every time, yesterday.

Moreover, I was looking for a switch to avoid kexec, and do a reboot after installation, but I could not find any switch to make it happen. That kexec stuff adds some cases more to take care of for all components in this game, X server, kernel, VirtualBox, and what else. I would accept, if installation in VirtualBox requires special settings, like turning kexec off. But I haven't found it. So theory.

I will just retry another time.

Reproduction failed a second time. It does not any more use kexec (change to installed system) but it does a proper installation of grub, and a nice reboot, and then it just works.

The only thing I have to report now, vt1 is garbeled, and all other vts but vt7 are black and inoperational. X server on vt7 is properly working. Will try to find anything interesting. The come back.

Created attachment 457359 [details]
First virtual console is garbeled.

This is the look of the first virtual screen as it was yesterday, when the system hung after installation tried to change into the installed system.

Today the same picture appears after a proper reboot, and the boot manager succeeds in booting. X server is running properly. No text console is operational. The first contains garbage, the others are black.

Created attachment 457361 [details]
A collection of files below /var/log from the system where installation succeeded today.

There are possibly unrelated bugs visible. 

In /var/log/xdm.errors it seems that cpp is a bit abused (don't know why cpp should be used to launch xdm), and fails for some reason because of missing plugins. This probably is because the installation was a "minimal X installation", so good old xdm is being installed and used, and seems to work, despite of the error messages.

Could not yet find anything suspicious in here. This time everything worked fine.

Well, so far I could not reproduce the hangup  after installing, before booting into the freshly installed system.

If I somehow succeed again in reproducing it, how can I get the logfiles from the installation system, which might include some nice information? Or do the logfiles from installation end up in the installed system? Could it happen, that booting the installed system overwrites old logfiles produced during installation?

If anybody has an idea, why yesterday everytime I tried to install, installation seemed to fail in kexec, and the installed system was not bootable, and today both times it does not try to use kexec, but does a proper installation of grub, then reboots successfully, and grub succeeds in booting the freshly installed system.

If there is a switch to turn kexec off, and do a proper reboot to get into the freshly installed system, this would be a fully acceptable resolution of the bug for me. I have not yet found this switch, myself.

Created attachment 457372 [details]
Vbox.log from a run, where installation hung after trying to kexec into the installed system.

Created attachment 457373 [details]
VBox.log from a run from today, where installation did not hang.

Comment on attachment 457372 [details]
Vbox.log from a run, where installation hung after trying to kexec into the installed system.

See after line 750.

The problem with the damaged virtual consoles after a X server has been started is subject in bug #717713. It is a VirtualBox issue, and a fix for VBox 4.1.y is on the way. My host system openSUSE 11.4 has

virtualbox-qt-4.0.12-0.2.1.x86_64
virtualbox-4.0.12-0.2.1.x86_64
virtualbox-host-kmp-desktop-4.0.12_k2.6.37.6_0.7-0.2.1.x86_64

So in fact, there is currently nothing reproducible left here. I have no more virtual disk with a failed installation, and cannot create another one. I cannot provide any information from a failed installation, but VirtualBox logs. The last failed installation was overwritten by a text-mode install, which worked, and since then every installation worked and succeeded in booting into the fresh system, even creating a fresh VM from scratch did not help.

See log comment #4.

*** This bug has been marked as a duplicate of bug 723777 ***

With 12.1 rc1 so far the text consoles are intact after X server has been started during installation, so there is hope to get more information, if it happens again.