Hi all,
i have installed sles 10 64 bit on a VMware workstation.
While installation I have checked the option of "LVM type installation"
Now if I am trying to boot the system, i am always forced to used the cdrom and select boot an installed system"
I understand there is some problem in booting the system with lvm FS.
Any quick way to fix it?
_____________________________________________________________________
menu.lst file
# Modified by YaST2. Last modification on Mon Mar 7 17:22:20 UTC 2011
default 0
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,1)/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux Enterprise Server 10 SP3
root (hd0,1)
kernel /vmlinuz-2.6.16.60-0.54.5-default root=/dev/system/root vga=0x332 resume=/dev/system/swap splash=silent showopts
initrd /initrd-2.6.16.60-0.54.5-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- SUSE Linux Enterprise Server 10 SP3
root (hd0,1)
kernel /vmlinuz-2.6.16.60-0.54.5-default root=/dev/system/root vga=0x332 showopts ide=nodma apm=off acpi=off noresume edd=off 3
initrd /initrd-2.6.16.60-0.54.5-default
_____________________________________________________________________

slesVX:~ # lvdisplay
--- Logical volume ---
LV Name /dev/system/root
VG Name system
LV UUID oP2z7p-pXDx-Jhla-KLm0-e6SL-cu7P-8Bd68W
LV Write Access read/write
LV Status available
# open 2
LV Size 7.36 GB
Current LE 1885
Segments 2
Allocation inherit
Read ahead sectors 0
Block device 253:0

--- Logical volume ---
LV Name /dev/system/swap
VG Name system
LV UUID qhVbzm-pyai-vOZC-QuPv-JNzl-UFJL-s6kdlc
LV Write Access read/write
LV Status available
# open 1
LV Size 560.00 MB
Current LE 140
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:1
_____________________________________________________________________________
slesVX:~ # mount -l
/dev/system/root on / type reiserfs (rw,acl,user_xattr) []
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/hda2 on /boot type ext2 (rw,acl,user_xattr) []
securityfs on /sys/kernel/security type securityfs (rw)
tmpfs on /dev/vx type tmpfs (rw,size=4k,nr_inodes=2097152,mode=0755)
none on /dev/odm type vxodmfs (rw,smartsync)
slesVX:~ # cat /etc/fstab
/dev/system/root / reiserfs acl,user_xattr 1 1
/dev/disk/by-id/ata-VMware_Virtual_IDE_Hard_Drive_00000000000000000001-part2 /boot ext2 acl,user_xattr 1 2
/dev/system/swap swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0

# NOTE: When adding or modifying VxFS or VxVM entries, add '_netdev'
# to the mount options to ensure the filesystems are mounted after VxVM and
__________________________________________________________________________________
slesVX:~ # dmesg|grep -i dm
device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
dm-netlink version 0.0.2 loaded
device-mapper: table: 253:2: linear: dm-linear: Device lookup failed
device-mapper: table: 253:3: linear: dm-linear: Device lookup failed
device-mapper: table: 253:4: linear: dm-linear: Device lookup failed
ReiserFS: dm-5: found reiserfs format "3.6" with standard journal
ReiserFS: dm-5: using ordered data mode
ReiserFS: dm-5: journal params: device dm-5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-5: checking transaction log (dm-5)
ReiserFS: dm-5: Using r5 hash to sort names
ReiserFS: dm-0: found reiserfs format "3.6" with standard journal
ReiserFS: dm-0: using ordered data mode
ReiserFS: dm-0: journal params: device dm-0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-0: checking transaction log (dm-0)
ReiserFS: dm-0: Using r5 hash to sort names
ReiserFS: dm-0: found reiserfs format "3.6" with standard journal
ReiserFS: dm-0: using ordered data mode
ReiserFS: dm-0: journal params: device dm-0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-0: checking transaction log (dm-0)
ReiserFS: dm-0: Using r5 hash to sort names
__________________________________________________________
slesVX:~ # lvscan -v
Finding all logical volumes
ACTIVE '/dev/system/root' [7.36 GB] inherit
ACTIVE '/dev/system/swap' [560.00 MB] inherit
__________________________________________________________

It sounds like maybe the CD/DVD drive device type is set to access a datastore iso file.

I found this solution in another post on another site. It should help:


Solution found for no boot with 2.6.27-3 and LVM and VMware

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) --
HTML Code:
<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.

some seniors pls look into this if I can be helped,
i booted the system in rescue mode and tried using parted and move the partition, but the operation fails, giving a message "invalid partition flag set"