Hi I never got Rawhide booting in vmware-server 2.0 (RC2) Fedora 9 x86_64 is running well Also a upgraded system which was F9 before will not boot after sysupgrade The ISO-Image from Fedora 10 Alpha is booting well and so after chroot /mnt/sysimage i can upgrade the system in hope one of the next kernels will start working Attached a screenshot from the hanging vm Here the "Hardware"-Infos /boot, /, /var/log, /var/cache, /tmp, /data are own vmdks Processors 2 Memory 384 MB Hard Disk 1 (SCSI 0:0) 200 MB Hard Disk 2 (SCSI 0:1) 2.00 GB Hard Disk 3 (SCSI 0:2) 2.00 GB Hard Disk 4 (SCSI 0:3) 5.00 GB Hard Disk 5 (SCSI 0:4) 6.00 GB Hard Disk 6 (SCSI 0:5) 6.00 GB Hard Disk 7 (SCSI 0:6) 2.00 GB SCSI Controller 0 LSI Logic CD/DVD Drive 1 (IDE 0:0) Using file fc10-alpha-x86_64.iso Network Adapter 1 NAT
Created attachment 316699 [details] Screenshot fo VMware-Console
Created attachment 323639 [details] Screen shot of VMware booting FC10 At least your screen shot is more informative than mine. During boot, all I saw was a couple of white, light blue, and dark blue lines. The second line progressively turned all white, like a status bar. But I never got any more text than what you see here. I can't switch VT's on this either. vmware-vmx is at 100% CPU usage.
Oh, BTW, I'm running VMware Workstation 5.5.4 on a FC6 host, and have installed the FC10 Preview (i386). The installation appeared to complete without any problems, although it seemed to be extremely slow in the middle.
After removing "rhgb quiet" from the boot options in grub.conf, I got a lot more detail during boot. There was an interesting warning near the beginning: ------------[ cut here ]------------ WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1500 mtrr_trim_uncached_memory+0x30e/0x315() WARNING: strange, CPU MTRRs all blank? After that everything looks normal as it loads the device drivers, including the BusLogic SCSI driver. Then I see: Scanning logical valumes Reading all physical volumes. This may take a while... scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2 scsi scan: INQUIRY result too short (5), using 36 scsi scan: INQUIRY result too short (5), using 36 scsi scan: INQUIRY result too short (5), using 36 [message repeats about 30 times] sd 2:0:0:0: [sda] 33344716 512-byte hardware sectors (17072 MB) sd 2:0:0:0: [sda] Write Protect is off sd 2:0:0:0: [sda] Cache data unavailable sd 2:0:0:0: [sda] Assuming drive cache: write through sd 2:0:0:0: [sda] 33344716 512-byte hardware sectors (17072 MB) sd 2:0:0:0: [sda] Write Protect is off sd 2:0:0:0: [sda] Cache data unavailable sd 2:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sda2 sd 2:0:0:0: [sda] Attached SCSI disk sd 2:0:0:0: Attached scsi generic sg1 type 0 Activating logical volumes Volume group "VolGroup00" not found Unable to access resume device (/dev/VolGroup00/LogVol01) Creating root device. Mounting root filesystem. mount: error mounting /dev/root on /sysroot as ext3: No such file or directory Setting up other filesystems. setuproot: moving /dev failed: No such file or directory setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Mount failed for selinuxfs on /selinux: No such file or directory Switching to new root and running init. switchroot: mount failed: No such file or directory Booting has failed. _ When I boot the install DVD in rescue mode, it detects and mounts /dev/mapper/VolGroup00-LogVol00 without any problem. I can't figure out why it can't find the logical volumes.
I found the solution in bug #466071. From rescue mode, I created /etc/sysconfig/mkinitrd with the following line: MODULES="scsi_wait_scan" Then I edited /sbin/mkinitrd and fixed the case of the "buslogic" module name to "BusLogic" and ran this line from the kernel post-install script: /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.27.4-68.fc10.i686 I then rebooted and it came all the way up to the First Boot welcome screen. Reindl, you should see if this fix works for you as well. It looks like the Fedora maintainers just need to make sure mkinitrd-6.0.70 makes it into the final release.
I discovered this problem for a just installed rawhide machine using 3ware controller (3w_9xxx module). adding MODULES="scsi_wait_scan" to the /etc/sysconfig/mkinitrd file and rebuilding the initrd of running kernel solved the problem. we need a patch before official fedora 10 release, else after installing fedora 10 the system result unbootable. Best Regards
For me this time with "lsilogic" all works Guest is "Fedora 10 x86_64" on "VMware-server-2.0.0-122956.x86_64" scsi0.present = "TRUE" scsi0.pciSlotNumber = "16" scsi0.sharedBus = "none" scsi0.virtualDev = "lsilogic" I would like to see VMware-Products as host would be tested because they are easy to reproduce and we have running 10 Fedora-VMs as production-server since two months, its a good feeling to see the next release working long time before
I think it depends on what version of VMware you've got. Under VMware Workstation 5.5, Fedora won't work with the lsilogic driver but will work with the buslogic driver (it doesn't find any disks); while on the other hand Red Hat Enterprise Linux works with the lsilogic driver but not the buslogic driver. It's probably different with Workstation 6.x and Server. It would be really nice if someone (I don't know if it's a driver or emulator problem) would get both lsilogic and buslogic working at the same time, so we don't have to guess which controller to use when setting up a new virtual machine.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
It makes me really crazy The same with rawhide F11 and 2.6.28 Why is it a pokergame to get the system startet in vmware-server?
Here some additional infos from /var/log/messages with 2.6.29-0.41.rc2.fc11.x86_64 running in vmware-server 2.0 I need to stop and start the vm multiple times until it starts without hanging with a non-found sysroot, even if it boots there are many stack-traces flying over the screen Jan 18 02:29:30 rawhide kernel: Call Trace: Jan 18 02:29:30 rawhide kernel: [<ffffffff8104a4f9>] warn_slowpath+0xb9/0xfe Jan 18 02:29:30 rawhide kernel: [<ffffffff81381017>] ? printk+0x3c/0x45 Jan 18 02:29:30 rawhide kernel: [<ffffffff8119bcd7>] __debug_object_init+0x2a8/0x353 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d516>] ? trace_hardirqs_on+0xd/0xf Jan 18 02:29:30 rawhide kernel: [<ffffffff8119bdaf>] debug_object_init+0x14/0x19 Jan 18 02:29:30 rawhide kernel: [<ffffffff81054407>] init_timer+0x18/0x5b Jan 18 02:29:30 rawhide kernel: [<ffffffffa001022a>] mpt_config+0x1e4/0x305 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffff81015a51>] ? dma_generic_alloc_coherent+0xad/0x138 Jan 18 02:29:30 rawhide kernel: [<ffffffffa0011e54>] mpt_do_ioc_recovery+0x135c/0x15e8 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffff81046bc2>] ? finish_task_switch+0x5f/0xf6 Jan 18 02:29:30 rawhide kernel: [<ffffffff81046b63>] ? finish_task_switch+0x0/0xf6 Jan 18 02:29:30 rawhide kernel: [<ffffffff811961f5>] ? string+0x3d/0xa1 Jan 18 02:29:30 rawhide kernel: [<ffffffff8119663e>] ? vsnprintf+0x3e5/0x930 Jan 18 02:29:30 rawhide kernel: [<ffffffffa00122a2>] ? mpt_timer_expired+0x0/0x60 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffffa00122a2>] ? mpt_timer_expired+0x0/0x60 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffffa00122a2>] ? mpt_timer_expired+0x0/0x60 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffff8106cf03>] ? mark_lock+0x22/0x3ad Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d2f5>] ? mark_held_locks+0x67/0x83 Jan 18 02:29:30 rawhide kernel: [<ffffffffa00122a2>] ? mpt_timer_expired+0x0/0x60 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffff81062269>] ? up_read+0x26/0x2a Jan 18 02:29:30 rawhide kernel: [<ffffffffa001380c>] mpt_attach+0xa1b/0xb7f [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffffa002d3ad>] mptspi_probe+0x1a/0x3cd [mptspi] Jan 18 02:29:30 rawhide kernel: [<ffffffff811a4f13>] local_pci_probe+0x12/0x16 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105add7>] do_work_for_cpu+0x13/0x1b Jan 18 02:29:30 rawhide kernel: [<ffffffff8105af68>] run_workqueue+0x103/0x20a Jan 18 02:29:30 rawhide kernel: [<ffffffff8105af16>] ? run_workqueue+0xb1/0x20a Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d4e5>] ? trace_hardirqs_on_caller+0x12f/0x153 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105adc4>] ? do_work_for_cpu+0x0/0x1b Jan 18 02:29:30 rawhide kernel: [<ffffffff8105b14f>] worker_thread+0xe0/0xf1 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105edac>] ? autoremove_wake_function+0x0/0x38 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105b06f>] ? worker_thread+0x0/0xf1 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105ea34>] kthread+0x49/0x76 Jan 18 02:29:30 rawhide kernel: [<ffffffff8101262a>] child_rip+0xa/0x20 Jan 18 02:29:30 rawhide kernel: [<ffffffff81011f3e>] ? restore_args+0x0/0x30 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105e9c6>] ? kthreadd+0x176/0x19b Jan 18 02:29:30 rawhide kernel: [<ffffffff8105e9eb>] ? kthread+0x0/0x76 Jan 18 02:29:30 rawhide kernel: [<ffffffff81012620>] ? child_rip+0x0/0x20 Jan 18 02:29:30 rawhide kernel: ---[ end trace ef0ef742e64235c2 ]--- Jan 18 02:29:30 rawhide kernel: ODEBUG: object is on stack, but not annotated Jan 18 02:29:30 rawhide kernel: ------------[ cut here ]------------ Jan 18 02:29:30 rawhide kernel: WARNING: at lib/debugobjects.c:253 __debug_object_init+0x2a8/0x353() (Not tainted) Jan 18 02:29:30 rawhide kernel: Hardware name: VMware Virtual Platform Jan 18 02:29:30 rawhide kernel: Modules linked in: mptspi(+) mptscsih mptbase scsi_transport_spi Jan 18 02:29:30 rawhide kernel: Pid: 9, comm: events/0 Not tainted 2.6.29-0.41.rc2.fc11.x86_64 #1 Jan 18 02:29:30 rawhide kernel: Call Trace: Jan 18 02:29:30 rawhide kernel: [<ffffffff8104a4f9>] warn_slowpath+0xb9/0xfe Jan 18 02:29:30 rawhide kernel: [<ffffffff81381017>] ? printk+0x3c/0x45 Jan 18 02:29:30 rawhide kernel: [<ffffffff8119bcd7>] __debug_object_init+0x2a8/0x353 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d516>] ? trace_hardirqs_on+0xd/0xf Jan 18 02:29:30 rawhide kernel: [<ffffffff8119bdaf>] debug_object_init+0x14/0x19 Jan 18 02:29:30 rawhide kernel: [<ffffffff81054407>] init_timer+0x18/0x5b Jan 18 02:29:30 rawhide kernel: [<ffffffffa001022a>] mpt_config+0x1e4/0x305 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d516>] ? trace_hardirqs_on+0xd/0xf Jan 18 02:29:30 rawhide kernel: [<ffffffffa001165a>] ? mpt_do_ioc_recovery+0xb62/0x15e8 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffffa00116fe>] mpt_do_ioc_recovery+0xc06/0x15e8 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffff81046bc2>] ? finish_task_switch+0x5f/0xf6 Jan 18 02:29:30 rawhide kernel: [<ffffffff81046b63>] ? finish_task_switch+0x0/0xf6 Jan 18 02:29:30 rawhide kernel: [<ffffffff811961f5>] ? string+0x3d/0xa1 Jan 18 02:29:30 rawhide kernel: [<ffffffff8119663e>] ? vsnprintf+0x3e5/0x930 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105ccfc>] ? __kernel_text_address+0x3d/0x48 Jan 18 02:29:30 rawhide kernel: [<ffffffff81014bed>] ? print_context_stack+0xa8/0xc3 Jan 18 02:29:30 rawhide kernel: [<ffffffff8101414a>] ? dump_trace+0x269/0x27b Jan 18 02:29:30 rawhide kernel: [<ffffffff8101c12b>] ? save_stack_trace+0x2a/0x48 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106c312>] ? save_trace+0x3f/0x95 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106cf03>] ? mark_lock+0x22/0x3ad Jan 18 02:29:30 rawhide kernel: [<ffffffff8106cf03>] ? mark_lock+0x22/0x3ad Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d2f5>] ? mark_held_locks+0x67/0x83 Jan 18 02:29:30 rawhide kernel: [<ffffffff81383cd5>] ? _spin_unlock_irqrestore+0x47/0x57 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d4e5>] ? trace_hardirqs_on_caller+0x12f/0x153 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d516>] ? trace_hardirqs_on+0xd/0xf Jan 18 02:29:30 rawhide kernel: [<ffffffff81194cda>] ? __up_read+0x7c/0x85 Jan 18 02:29:30 rawhide kernel: [<ffffffff81062269>] ? up_read+0x26/0x2a Jan 18 02:29:30 rawhide kernel: [<ffffffffa001380c>] mpt_attach+0xa1b/0xb7f [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffffa002d3ad>] mptspi_probe+0x1a/0x3cd [mptspi] Jan 18 02:29:30 rawhide kernel: [<ffffffff811a4f13>] local_pci_probe+0x12/0x16 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105add7>] do_work_for_cpu+0x13/0x1b Jan 18 02:29:30 rawhide kernel: [<ffffffff8105af68>] run_workqueue+0x103/0x20a Jan 18 02:29:30 rawhide kernel: [<ffffffff8105af16>] ? run_workqueue+0xb1/0x20a Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d4e5>] ? trace_hardirqs_on_caller+0x12f/0x153 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105adc4>] ? do_work_for_cpu+0x0/0x1b Jan 18 02:29:30 rawhide kernel: [<ffffffff8105b14f>] worker_thread+0xe0/0xf1 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105edac>] ? autoremove_wake_function+0x0/0x38 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105b06f>] ? worker_thread+0x0/0xf1 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105ea34>] kthread+0x49/0x76 Jan 18 02:29:30 rawhide kernel: [<ffffffff8101262a>] child_rip+0xa/0x20 Jan 18 02:29:30 rawhide kernel: [<ffffffff81011f3e>] ? restore_args+0x0/0x30 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105e9c6>] ? kthreadd+0x176/0x19b Jan 18 02:29:30 rawhide kernel: [<ffffffff8105e9eb>] ? kthread+0x0/0x76 Jan 18 02:29:30 rawhide kernel: [<ffffffff81012620>] ? child_rip+0x0/0x20 Jan 18 02:29:30 rawhide kernel: ---[ end trace ef0ef742e64235be ]--- Jan 18 02:29:30 rawhide kernel: ODEBUG: object is on stack, but not annotated Jan 18 02:29:30 rawhide kernel: ------------[ cut here ]------------ Jan 18 02:29:30 rawhide kernel: WARNING: at lib/debugobjects.c:253 __debug_object_init+0x2a8/0x353() (Tainted: G W ) Jan 18 02:29:30 rawhide kernel: Hardware name: VMware Virtual Platform Jan 18 02:29:30 rawhide kernel: Modules linked in: mptspi(+) mptscsih mptbase scsi_transport_spi Jan 18 02:29:30 rawhide kernel: Pid: 9, comm: events/0 Tainted: G W 2.6.29-0.41.rc2.fc11.x86_64 #1 Jan 18 02:29:30 rawhide kernel: Call Trace: Jan 18 02:29:30 rawhide kernel: [<ffffffff8104a4f9>] warn_slowpath+0xb9/0xfe Jan 18 02:29:30 rawhide kernel: [<ffffffff8119b514>] ? debug_check_no_obj_freed+0x75/0x1b0 Jan 18 02:29:30 rawhide kernel: [<ffffffff81381017>] ? printk+0x3c/0x45 Jan 18 02:29:30 rawhide kernel: [<ffffffff8119bcd7>] __debug_object_init+0x2a8/0x353 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d516>] ? trace_hardirqs_on+0xd/0xf Jan 18 02:29:30 rawhide kernel: [<ffffffff8119bdaf>] debug_object_init+0x14/0x19 Jan 18 02:29:30 rawhide kernel: [<ffffffff81054407>] init_timer+0x18/0x5b Jan 18 02:29:30 rawhide kernel: [<ffffffffa001022a>] mpt_config+0x1e4/0x305 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffff81016e31>] ? nommu_free_coherent+0x1e/0x21 Jan 18 02:29:30 rawhide kernel: [<ffffffffa000f177>] ? pci_free_consistent+0x75/0x81 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffffa0011a60>] mpt_do_ioc_recovery+0xf68/0x15e8 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffff81046bc2>] ? finish_task_switch+0x5f/0xf6 Jan 18 02:29:30 rawhide kernel: [<ffffffff81046b63>] ? finish_task_switch+0x0/0xf6 Jan 18 02:29:30 rawhide kernel: [<ffffffff811961f5>] ? string+0x3d/0xa1 Jan 18 02:29:30 rawhide kernel: [<ffffffff8119663e>] ? vsnprintf+0x3e5/0x930 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105ccfc>] ? __kernel_text_address+0x3d/0x48 Jan 18 02:29:30 rawhide kernel: [<ffffffff81014bed>] ? print_context_stack+0xa8/0xc3 Jan 18 02:29:30 rawhide kernel: [<ffffffff8101414a>] ? dump_trace+0x269/0x27b Jan 18 02:29:30 rawhide kernel: [<ffffffff8101c12b>] ? save_stack_trace+0x2a/0x48 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106c312>] ? save_trace+0x3f/0x95 Jan 18 02:29:30 rawhide kernel: [<ffffffffa00122a2>] ? mpt_timer_expired+0x0/0x60 [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffff8106cf03>] ? mark_lock+0x22/0x3ad Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d2f5>] ? mark_held_locks+0x67/0x83 Jan 18 02:29:30 rawhide kernel: [<ffffffff81383cd5>] ? _spin_unlock_irqrestore+0x47/0x57 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d4e5>] ? trace_hardirqs_on_caller+0x12f/0x153 Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d516>] ? trace_hardirqs_on+0xd/0xf Jan 18 02:29:30 rawhide kernel: [<ffffffff81062269>] ? up_read+0x26/0x2a Jan 18 02:29:30 rawhide kernel: [<ffffffffa001380c>] mpt_attach+0xa1b/0xb7f [mptbase] Jan 18 02:29:30 rawhide kernel: [<ffffffffa002d3ad>] mptspi_probe+0x1a/0x3cd [mptspi] Jan 18 02:29:30 rawhide kernel: [<ffffffff811a4f13>] local_pci_probe+0x12/0x16 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105add7>] do_work_for_cpu+0x13/0x1b Jan 18 02:29:30 rawhide kernel: [<ffffffff8105af68>] run_workqueue+0x103/0x20a Jan 18 02:29:30 rawhide kernel: [<ffffffff8105af16>] ? run_workqueue+0xb1/0x20a Jan 18 02:29:30 rawhide kernel: [<ffffffff8106d4e5>] ? trace_hardirqs_on_caller+0x12f/0x153 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105adc4>] ? do_work_for_cpu+0x0/0x1b Jan 18 02:29:30 rawhide kernel: [<ffffffff8105b14f>] worker_thread+0xe0/0xf1 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105edac>] ? autoremove_wake_function+0x0/0x38 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105b06f>] ? worker_thread+0x0/0xf1 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105ea34>] kthread+0x49/0x76 Jan 18 02:29:30 rawhide kernel: [<ffffffff8101262a>] child_rip+0xa/0x20 Jan 18 02:29:30 rawhide kernel: [<ffffffff81011f3e>] ? restore_args+0x0/0x30 Jan 18 02:29:30 rawhide kernel: [<ffffffff8105e9c6>] ? kthreadd+0x176/0x19b Jan 18 02:29:30 rawhide kernel: [<ffffffff8105e9eb>] ? kthread+0x0/0x76 Jan 18 02:29:30 rawhide kernel: [<ffffffff81012620>] ? child_rip+0x0/0x20 Jan 18 02:29:30 rawhide kernel: ---[ end trace ef0ef742e64235bf ]--- Jan 18 02:29:30 rawhide kernel: ODEBUG: object is on stack, but not annotated
Same here, cannot boot an installed F11 alpha from the hard drive, it cannot find the drives. "Boot from local drive" also fails. I can boot into Rescue mode and see the drives. I installed with VMWare 6.5 defaults, but have switched to LSI and it still will not boot. I am going to attempt to mess with mkinitrd to see if that helps, but so far it has not.
With "nodmraid notsc scsi_mod.scan=sync" kernel-params i have never seen this any more Trie to reboot / halt and start the vm many times, it sounds crazy but sometimes it boots, after that you can add the params in /boot/grub/grub.conf I have made this in all my testing machines (VMware Server 2.0) also as in our production-servers (VMware ESXi) and now all seems to be ok since some months
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is a mass edit of all mkinitrd bugs. Thanks for taking the time to file this bug report (and/or commenting on it). As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on certain libraries it provides, but mkinitrd itself is no longer used. In Fedora 13 mkinitrd will be removed completely. This means that all work on initrd has stopped. Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.