6.06 Dapper to 8.04 Hardy: LVM fails to load properly

[uberalex]

Hi,
In the process of upgrading from Dapper to Hardy, we ran into a problem with the LVM-mounted parts of the drive. Our initial difficulty was an error reported by the boot process which could not mount the UUIDs, and it crashed to an emergency prompt. We were able to get past this part by modprobing dm-mod.

However, now when we try to boot up the lvm manager does not seem to load, and the system does not find the lvm volumes, and returns to the emergency prompt.

vgs and lvs both seem to report ok, the devices only appear in /dev/mapper after we run vgchange -a y

dm-mod is in etc/modules

Is the lvm supposed to discover the drives during the boot process, and if so, where should this happen, and why are we not getting it?

Thanks for your help.

output of mount:


mount -v
/dev/sda3 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda2 on /boot type ext3 (rw)
/dev/mapper/lvg01-home on /home type ext3 (rw)
/dev/mapper/lvg01-mysql on /var/mysql type ext3 (rw)
/dev/mapper/lvg01-svn on /var/svn type ext3 (rw)
/dev/mapper/lvg01-www on /var/www type ext3 (rw)
securityfs on /sys/kernel/security type securityfs (rw)


Fstab


#/etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda3 -- converted during upgrade to edgy
UUID=178b3234-9235-4991-98a2-10480ec6582d / ext3 defaults,errors=remount-ro 0 1
# /dev/sda2 -- converted during upgrade to edgy
UUID=d3da9406-8720-48da-a1db-588b2e1be27b /boot ext3 defaults 0 2

# /dev/mapper/lvg01-home -- converted during upgrade to edgy
UUID=f09f0af5-5a6c-44ea-8afb-f9643e2ef0c6 /home ext3 defaults 0 2
#/dev/mapper/lvg01-home /home ext3 defaults 0 2

# /dev/mapper/lvg01-mysql -- converted during upgrade to edgy
UUID=fb94dcb0-c6a5-4b50-b84c-4702784c13a8 /var/mysql ext3 defaults 0 2
#/dev/mapper/lvg01-mysql /var/mysql ext3 defaults 0 2

# /dev/mapper/lvg01-svn -- converted during upgrade to edgy
UUID=b5fad63b-041c-4b07-bea2-f91c8a5ae4d5 /var/svn ext3 defaults 0 2
#/dev/mapper/lvg01-svn /var/svn ext3 defaults 0 2

# /dev/mapper/lvg01-www -- converted during upgrade to edgy
UUID=f292668b-3959-43a8-bdb7-f6d6dc56b1bb /var/www ext3 defaults 0 2
#/dev/mapper/lvg01-www /var/www ext3 defaults 0 2

# /dev/sda1 -- converted during upgrade to edgy
UUID=9b84c1b2-e3b9-4699-abb1-7916e6ab22b7 none swap sw 0 0
/dev/cdrom /media/cdrom0 udf,iso9660 user,noauto 0 0




cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04.2"

[IanOKeeffe]

I have done some digging around in an attempt to solve this problem. I found this bug report:

https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/147216

It suggests that the problem is with the LVM udev rule. The difference in our case is that the LVM partition is not on a RAID array, just a simple single disk.

To satisfy my curiosity, I ran vol_id on the LVM partition to verify that it was being reported as LVM. This is the output that I got:



ID_FS_USAGE=raid
ID_FS_TYPE=LVM2_member
ID_FS_VERSION=LVM2 001
ID_FS_UUID=
ID_FS_UUID_ENC=
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=


As you can see, the ID_FS_TYPE should match the condition in the LVM udev rule, which should result in vgchange -a y being executed.

At this point I still have no resolution to the problem.