Bug 429190 - rawhide does not boot on VirtualBox
rawhide does not boot on VirtualBox
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-01-17 15:18 EST by Mauricio Teixeira
Modified: 2009-07-14 11:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 11:41:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
f9 fails to boot on virtualbox (29.25 KB, image/png)
2008-01-17 15:18 EST, Mauricio Teixeira
no flags Details
Screenshot (212.47 KB, image/png)
2008-08-09 15:31 EDT, Andy Lawrence
no flags Details

  None (edit)
Description Mauricio Teixeira 2008-01-17 15:18:39 EST
I have installed Fedora 8 from a DVD image inside a VirtualBox 1.5.4 virtual
machine, with ACPI and VT enabled (1GB RAM + 10GB HD).

After the install, I enabled the fedora-development.repo, and run 'yum upgrade'.
All went fine, all packages installed well.

Now system fails to boot. A screen shot has been attached for reference.

Please, let me know if you need further information.
Comment 1 Mauricio Teixeira 2008-01-17 15:18:39 EST
Created attachment 292063 [details]
f9 fails to boot on virtualbox
Comment 2 Mauricio Teixeira 2008-01-24 06:51:08 EST
Ok, got down to the real problem... It seems that the F9 upgrade process didn't
create the correct initrd image. I'm not sure what was missing, but I reboot
with the boot.iso, entered rescue mode, chroot, mkinitrd, reboot, bingo!

Any other information I can provide to help fixing this?
Comment 3 Bug Zapper 2008-05-14 00:48:11 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 4 Andy Lawrence 2008-08-09 15:31:30 EDT
Created attachment 313884 [details]

Same result different cause.
Comment 5 Andy Lawrence 2008-08-09 15:38:48 EDT
Sorry, that's F10 in my case...
Comment 6 Chuck Ebbert 2008-08-14 00:14:01 EDT
(In reply to comment #4)
> Created an attachment (id=313884) [details]
> Screenshot
> Same result different cause.

The screenshot doesn't really tell us anything. Can you capture the entire oops?
Comment 7 Andy Lawrence 2008-08-14 06:38:53 EDT
I'm happy to provide any info I can get.  This hangs directly after the kernel select screen, or if ACPI is turned a bit of that will scroll through, then hang.  Maybe I could get the serial port output by capturing that boot in Virtualbox's auto capture function, never tried though.  It never makes it to LVM or udev.

Any ideas for capturing additional info?  I was using the i386 Fedora 10 Alpha Live CD.
Comment 8 Nicolás Ruiz 2008-08-19 21:19:03 EDT
Running a Fedora9 guest OS, booting from Fedora-10-Alpha-i386-netinst.iso (sha1sum 14ef750ec30eb14f3f78fb7aa59fb242ddcf8486), I get this oops:

ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfadb0, last bus=0
PCI: Using configuration type 1 for base access
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using PIC for interrupt routing
BUG: unable to handle kernel NULL pointer dereference at 00000246
IP: [<c067b3ab>] __mutex_lock_common+0x2a8/0x2f3
*pde = 00000000 
Modules linked in:

Pid: 11, comm: ftraced Not tainted (2.6.27-0.166.rc0.git8.fc10.i586 #1)
EIP: 0060:[<c067b3ab>] EFLAGS: 00010246 CPU: 0
EIP is at __mutex_lock_common+0x2a8/0x2f3
EAX: 00000246 EBX: cf062fa0 ECX: 00000003 EDX: 00000001
ESI: c079f150 EDI: 00000246 EBP: cf09af88 ESP: cf09af44
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process ftraced (pid: 11, ti=cf09a000 task=cf062fa0 task.ti=cf09a000)
Stack: 00000001 00000003 a02e5788 000000d7 00000000 00000002 c079f188 c079f174 
       c079f154 cf09af68 cf09af68 00000000 c079f150 cf09af68 00000000 c079f150 
       c046f4ae cf09af9c c067b49d c043ed58 cf0b17d0 cf0b17d0 cf09afac c043ed58 
Call Trace:
 [<c046f4ae>] ? __ftrace_update_code+0x0/0x1f1
 [<c067b49d>] ? mutex_lock_nested+0x33/0x3b
 [<c043ed58>] ? kthread_stop+0x18/0x7b
 [<c043ed58>] ? kthread_stop+0x18/0x7b
 [<c045fadd>] ? stop_machine_run+0x2f/0x3d
 [<c046fd64>] ? ftraced+0x9a/0x16a
 [<c046fcca>] ? ftraced+0x0/0x16a
 [<c043ed1a>] ? kthread+0x40/0x66
 [<c043ecda>] ? kthread+0x0/0x66
 [<c0404f67>] ? kernel_thread_helper+0x7/0x10
Code: 90 f7 c7 00 02 00 00 75 13 89 f8 50 9d 0f 1f 84 00 00 00 00 00 e8 e1 f0 dc
 ff eb 11 e8 21 fe dc ff 89 f8 50 9d 0f 1f 84 00 00 00 <00> 00 8d 45 e0 e8 e2 dc
 dc ff 31 c0 8d 65 f4 5b 5e 5f 5d c3 8b 
EIP: [<c067b3ab>] __mutex_lock_common+0x2a8/0x2f3 SS:ESP 0068:cf09af44
---[ end trace 4eaa2a86a8e2da22 ]---
ftraced used greatest stack depth: 2432 bytes left
BUG: unable to handle kernel NULL pointer dereference at 00000246
IP: [<c0495adc>] kmem_cache_free+0xc3/0xcd
*pde = 00000000 
Modules linked in:

Pid: 73, comm: kacpi_notify Tainted: G      D   (2.6.27-0.166.rc0.git8.fc10.i586
EIP: 0060:[<c0495adc>] EFLAGS: 00010246 CPU: 0
EIP is at kmem_cache_free+0xc3/0xcd
EAX: 00000246 EBX: c043d105 ECX: c044b1cd EDX: c0495ad1
ESI: 0000000c EDI: cf0110f0 EBP: c0875fa4 ESP: c0875f84
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kacpi_notify (pid: 73, ti=c0875000 task=cf0b5f40 task.ti=cf0c1000)
Stack: c0495ad1 c044b1cd c043d105 c1349ea8 00000246 c079f07c 00000000 00000001 
       c0875fb0 c043d105 c13d16cc c0875fb8 c043d12c c0875fcc c046b41e c07c8aa0 
       c086d708 00000001 c0875fd4 c046b4ac c0875ff8 c043258a c0870a80 c0870a80 
Call Trace:
 [<c0495ad1>] ? kmem_cache_free+0xb8/0xcd
 [<c044b1cd>] ? trace_hardirqs_on+0xb/0xd
 [<c043d105>] ? put_pid+0x30/0x47
 [<c043d105>] ? put_pid+0x30/0x47
 [<c043d12c>] ? delayed_put_pid+0x10/0x12
 [<c046b41e>] ? __rcu_process_callbacks+0x185/0x1f4
 [<c046b4ac>] ? rcu_process_callbacks+0x1f/0x38
 [<c043258a>] ? __do_softirq+0x89/0x10f
 [<c0432501>] ? __do_softirq+0x0/0x10f
 [<c04066a2>] ? do_softirq+0x7c/0xde
 [<c04321c4>] ? irq_exit+0x49/0x88
 [<c0414ec6>] ? smp_apic_timer_interrupt+0x73/0x81
 [<c0404d4d>] ? apic_timer_interrupt+0x2d/0x40
 [<c044b1cd>] ? trace_hardirqs_on+0xb/0xd
 [<c067c45f>] ? _spin_unlock_irq+0x27/0x34
 [<c044b1cd>] ? trace_hardirqs_on+0xb/0xd
 [<c044007b>] ? run_posix_cpu_timers+0x4e/0x793
 [<c04400d8>] ? run_posix_cpu_timers+0xab/0x793
 [<c067c468>] ? _spin_unlock_irq+0x30/0x34
 [<c042a8e8>] ? finish_task_switch+0x47/0x9b
 [<c042a8a1>] ? finish_task_switch+0x0/0x9b
 [<c067a99a>] ? schedule+0x67d/0x6f5
 [<c044a486>] ? trace_hardirqs_off+0xb/0xd
 [<c0422df9>] ? complete+0x34/0x3e
 [<c043bd5c>] ? worker_thread+0x0/0xdd
 [<c043ed03>] ? kthread+0x29/0x66
 [<c043ecda>] ? kthread+0x0/0x66
 [<c0404f67>] ? kernel_thread_helper+0x7/0x10
Code: f0 00 02 00 00 75 14 8b 45 f0 50 9d 0f 1f 84 00 00 00 00 00 e8 b1 49 fb ff
 eb 12 e8 f1 56 fb ff 8b 45 f0 50 9d 0f 1f 84 00 00 00 <00> 00 8d 65 f4 5b 5e 5f
 5d c3 55 89 e5 53 e8 81 f4 f6 ff 89 c2 
EIP: [<c0495adc>] kmem_cache_free+0xc3/0xcd SS:ESP 0068:c0875f84
Kernel panic - not syncing: Fatal exception in interrupt
Comment 9 Andy Lawrence 2008-09-05 20:28:51 EDT
This appears fixed in Virtualbox 2.0.

Others, please confirm.
Comment 10 Bug Zapper 2009-06-09 19:23:28 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 11 Bug Zapper 2009-07-14 11:41:12 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.