Kernel 2.6.27-1 & -3 in vmware vm failure

[crainey69]

Anybody else running 10 beta as a VM in vmware? Starting with 2.6.27-1, I haven't been able to get it to boot. It fails to see the logical volume and of course fails miserably. I can drop back to the older kernels and it works fine.

I did see another post in the test list saying the same thing but no action other than a suggestion to remove and re install the kernel which doesn't work.

[Seve]

Hello:
Seems to be running fine here with VMware Server 2.0.0 Build 116503
Kernel 2.6.27-1.fc10.x86_64
Kernel 2.6.27-3.fc10.x86_64

Seve

[bmeeks8]

Anybody else running 10 beta as a VM in vmware? Starting with 2.6.27-1, I haven't been able to get it to boot. It fails to see the logical volume and of course fails miserably. I can drop back to the older kernels and it works fine.
Ditto for me here on VMware Workstation 6.5. With the original install's kernel it works fine. After the update to 2.6.27-1 and now 2.6.27-3, it fails on boot unable to find the Logical Volume as you say. Incidentally, the only way to see the error is to disable rhgb. Otherwise, it just freezes forever with no message.

I've seen other posts saying the 2.6.27-1 kernel was "broken", but with no specifics on what was broken. Looks like 2.6.27-3 is broken, too.

[crainey69]

Well, I'm 32 bit so that may be the difference between Seve and I. A have an actual f10 install as well and it boots fine. I usually don't use LVM but for the VM install and the actual install of alpha, for some reason, I let it use LVM. Not sure why I did that. When I finally go to 10, I won't be using LVM, I should have at least set the actual install up differently.

[bmeeks8]

I found the cause of the boot failure on my WMware workstation installs of Fedora 10 Beta with the latest 2.6.27-1 and 2.6.27-3 kernel updates. I'm not an expert, but I think this will only happen with folks using Logical Volume Manager. Of course, this is the default setup. I also don't know if this is specific to just VMware virtual machine installs or not. I have not tried Fedora 10 Beta on real hardware.

Anyway, here is what fixed mine. The problem is in the Grub config file where it identifies the root device for booting. The original kernel install for Fedora 10 referenced the Logical Volume where the root file system was located by using the UUID. The new kernel upgrades reference it via the old /dev/LogicalVolumeName syntax.

To fix my system, I just copied the root= part of the boot line up from the working older kernel to the updated kernel's line. For example, here is how the default boot entry for the latest kernel looks in my menu.lst file (this works) --
<pre>title Fedora (2.6.27-3.fc10.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.27-3.fc10.x86_64 ro root=UUID=f7346087-d51a-44d0-b56
0-3e3dabe11dda rhgb
initrd /initrd-2.6.27-3.fc10.x86_64.img
</pre>

The default upgrade script for the 2.6.27-1 and 2.6.27-3 kernels sets "root=/dev/LogVolGroup00" or something similar for the boot entry. I don't remember the exact syntax. Your UUID may well be different than mine, so just copy whatever is shown in your "working kernel's" "root=" section.

Perhaps the real issue is something missing in the initrd image that makes it unable to translate the Logical Volume name into the correct UUID. I'm not familiar at all with how that works. I just sort of stumbled into this fix while staring at the grub.conf file and noticing that UUID line in the working kernel and seeing it missing in the non-working kernel.

Update -- after a crashed X-session and subsequent reboot, the "fix" above did not work. I successfully booted into 2.6.27-3 previously, but can't get in again. The older original kernel still works.

[crainey69]

I've looked at my grub.conf file also and all of the kernels use the /dev/LogVolGroup

[bmeeks8]

I've looked at my grub.conf file also and all of the kernels use the /dev/LogVolGroup

Must be something weird with installs in VMware virtual machines if it works with your installs on "real" machines. I had the same failure message with kernel 2.6.27-1 and 2.6.27-3. I don't have the exact message in front of me, but it was something along the lines "can't find the volume group so I quit". Of course that is not the actual text of the message.

Changing my grub.conf to use the UUID fixed the boot of the latest 2.6.27-3 kernel on Fedora 10 Beta. I'm using VMware Workstation 6.5.

Update -- after a reboot from a crashed X-session, the "fix" above did not work. I successfully booted into 2.6.27-3 once, but can't get in again.

[crainey69]

essage: 8
Date: Mon, 13 Oct 2008 13:05:37 -0400
From: "Michael H. Warfield" <mhw@WittsEnd.com>
Subject: Re: kernel 2.6.26.6-67.fc9
To: For testers of Fedora Core development releases
<fedora-test-list@redhat.com>
Cc: mhw@WittsEnd.com
Message-ID: <1223917537.7723.185.camel@canyon.wittsend.com>
Content-Type: text/plain; charset="us-ascii"

Slightly off topic,

I've now also got 2.6.27-3 from rawhide running in F9 once I worked
around an initrd race condition with the VMware scsi drivers now that
dm-mirror, dm-zero, and dm-snapshot are no longer modules in 2.6.27.
Problem was causing lvm to run too early and not detect the physical
volumes.

https://bugzilla.redhat.com/show_bug.cgi?id=466071

Now that I'm past that, 2.6.27 seems pretty solid and has not shown
signs of the IPSec dain bramage that was present in 2.6.26.5.

Mike

On Sun, 2008-10-12 at 13:31 -0400, Michael H. Warfield wrote:
> > On Sat, 2008-10-11 at 14:44 +0200, Carlo Raudino wrote:
>> > > Today (after using the old RC1) I installed the kernel-2.6.26.6-67.fc9
>> > > from koji....

>> > > I think is very stable, for now it's running without troubles.

>> > > Has anyone encountered problems?

> > Nope. No problems here. And this appears to fix the IPSec related
> > random kernel hangs in 2.6.26.5 that I've reported.

> > https://bugzilla.redhat.com/show_bug.cgi?id=466303

>> > > I remember in .6 were dropped old patches... so it's a nice mantainance
>> > > update.
> >
>> > > Will it be pushed to updates? :-)
> >
> > Sounds like it, or something very much like it, based on the comments
> > Dave Jones made in the bugzilla thread.
> >
>> > > --
>> > > fedora-test-list mailing list
>> > > fedora-test-list@redhat.com
>> > > To unsubscribe:
>> > > https://www.redhat.com/mailman/listinfo/fedora-test-list
> >
> > Mike
> > --
> > fedora-test-list mailing list
> > fedora-test-list@redhat.com
> > To unsubscribe:
> > https://www.redhat.com/mailman/listinfo/fedora-test-list
-- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw@WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : https://www.redhat.com/archives/fedora-test-list/attachments/20081013/3bd1db39/attachment.bin ------------------------------

[bmeeks8]

Thanks for posting the link to this bug report ---

https://bugzilla.redhat.com/show_bug.cgi?id=466071

I think that might explain why I got a successful boot on the 2.6.27-3 kernel that one time. Through pure blind luck (and maybe the random aligment of the moon and planets...:)) my VMware SCSI driver may have won the race condition described in the bug.

I'm going to try the mkinitrd fix described in the bugzilla report and see if that works for me as well.