Bug 537350

we need yast logs. I did not have this problem when installing from DVD

sure, I'll provide logs soon.

Created attachment 317172 [details]
yast2 logs of the right machine

Created attachment 317174 [details]
system logs of the right machine

Created attachment 317180 [details]
yast2 logs of the left machine

Created attachment 317181 [details]
system logs of the left machine

I've sent ACPI-Shutdown to both machines and:

left / vbox1:
 - booted the left one again into the installed system; this time I was able
   to click OK to the FW msg box, but it stopped later.
 - ACPI-Shutdown again, booted into rescue to provide the logs
right / vbox2:
 - booted into rescue to provide the logs

Please take a look into var/log/messages in vbox1 system logs (comment #6);
it is full of kernel backtraces.

 kernel: [  238.001009] BUG: unable to handle kernel NULL pointer dereference at 0000000000000246
 kernel: [  238.001126] IP: [<0000000000000246>] 0x246
 kernel: [  238.001126] PGD d0ce067 PUD d027067 PMD 0 
 kernel: [  238.001126] Oops: 0010 [#22] PREEMPT SMP 
 kernel: [  238.001126] last sysfs file: /sys/module/x_tables/initstate
 kernel: [  238.001126] CPU 0 
 kernel: [  238.001126] Modules linked in: ip6t_REJECT ipt_REJECT xt_tcpudp ip6t_LOG nf_conntrack_ipv6 ip6table_raw xt_NOTRACK xt_pkt
 kernel: [  238.001126] Pid: 4929, comm: rm Tainted: G      D    2.6.31-rc8-5-desktop #1 VirtualBox
 kernel: [  238.001126] RIP: 0010:[<0000000000000246>]  [<0000000000000246>] 0x246
 kernel: [  238.001126] RSP: 0018:ffff8800149a7f90  EFLAGS: 00010246
 kernel: [  238.001126] RAX: 00007fdd5d93c000 RBX: 0000000000001000 RCX: 0000000000000001
 kernel: [  238.001126] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
 kernel: [  238.001126] RBP: ffffffff8100c682 R08: ffff88000d0d5588 R09: 0000000000100073
 kernel: [  238.001126] R10: ffff88000d0d5558 R11: 0000000000100073 R12: 0000000000400040
 kernel: [  238.001126] R13: 0000000000000000 R14: 0000000000000010 R15: 0000000000000100
 kernel: [  238.001126] FS:  00007f232556d6f0(0000) GS:ffff880001c71000(0000) knlGS:0000000000000000
 kernel: [  238.001126] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 kernel: [  238.001126] CR2: 0000000000000246 CR3: 000000000d001000 CR4: 00000000000006f0
 kernel: [  238.001126] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 kernel: [  238.001126] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
 kernel: [  238.001126] Process rm (pid: 4929, threadinfo ffff8800149a6000, task ffff88000d060080)
 kernel: [  238.001126] Stack:
 kernel: [  238.001126]  0000000000000022 0000000000000000 00000000ffffffff 0000000000000009
 kernel: [  238.001126] <0> 0000000000000000 0000000000000003 0000000000001000 0000000000000000
 kernel: [  238.001126] <0> 0000000000000009 00007fdd5d73543a 0000000000000033 0000000000010293
 kernel: [  238.001126] Call Trace:
 kernel: [  238.001126] Inexact backtrace:
 kernel: [  238.001126] 
 kernel: [  238.001126] Code:  Bad RIP value.
 kernel: [  238.001126] RIP  [<0000000000000246>] 0x246
 kernel: [  238.001126]  RSP <ffff8800149a7f90>
 kernel: [  238.001126] CR2: 0000000000000246
 kernel: [  238.030401] ---[ end trace a215f48c18ff7d21 ]---

Note, that I've full ipv6 connectivity to the internet in my network...
this seems to be the trigger for the above problems.

There isn't much the installation framework can do with kernel oopses triggered by firewall (re)start
On to kernel maintainers

I'm not sure how many will run into this problem, but it sounds bad and if Marius needs quite a while to figure it's ipv6, then it will be very frustrating to users.

The logs are loaded with traces, all of them suspicious. When I see traces like that, they're almost invariably VirtualBox bugs. I've already installed M7 several times with automatic configuration enabled and it's succeeded.

If you're able to reproduce with physical hardware (or a more reliable virtual machine), then please re-open this report. For now I'm closing as INVALID.

No, I didn't found this problem on a physical machine during my
last tests.

But just closing it as invalid makes IMO not much sense.
When this is a virtualbox problem, a seek for a fix of virtualbox
(on 11.1) would be cool - reassigning to the maintainer with lower
importance and reseted ship-stopper flag.

did you try with later VB versions?

(In reply to comment #14)
> did you try with later VB versions?

No, I'm still running virtualbox on 11.1 -- no time to update the
vb host machine until now.

On VirtualBox from openSUSE-11.2, the e1000 seems to cause Oopses;
something with paging -- it scrolled too fast and I was unable to
catch it / scroll back. Using pcnet32 (II) seems to work until now.

Created attachment 328418 [details]
dmesg output from 11.2

Using pcnet32 it installed fine, but later in 2nd stage oopses again;
yast2 crashed at the end, iptables while final boot into the system too.

I'm having this problem also, but with both autoconfig and without. I just installed 11.2 x86_64 on my MacBook as a guest in virtualbox 3.1. First try was with autoconfig and second was without but result was the same both times. 

The second part of the install doesn't complete successfully. I was booted into runlevel 5 with a login screen but the user I created was not available and I could only log in as root. No repos were added to software management. 

Subsequent reboots switch from graphical to text with much output in text mode and then ends with the YaST screen that says part of the install failed and I may need to put in some information again. After pressing enter, it takes me to the KDE log in screen. The system seems to be working fine once I'm logged in. I was able to add repos and a regular user with auto login that continues to work. 

Every reboot takes about twice as long as usual and results in the YaST error screen I described above.

I just updated to VirtualBox 3.1.4 and this problem still exists. I tried to re-install 11.2 after updating VB and had the same problem with the second part of the install. 

The only way I could get the configuration to run in the second part of the install was to use text only mode.

kevin:
please test Milestone7, I use it many times and your reported bug should be
fixed already, if not please file a new bug report, as this bug report was
originally created against 11.2

thanks

should be fixed in 11.3, if not please reopen