Please post the message.

Can you please attach the /var/log/YaST2 directory (as a tar file)?
Please take a look at http://www.opensuse.org/Bug_Reporting_FAQ#YaST
if you have any questions about this.

BTW, I happened to update a 9.3 to 10.0 with LVM, and it worked, so it cannot be a generic problem ==> Severity=Major.

The error messages displayed by "vgchange -a y" are definitely needed.
Additionally the output of the following commands is needed:

vgscan -vvv
vgchange -vvv -a y 

Please attach output of both commands.

Created attachment 55490 [details]
Output of vgscan/vgchange from 9.3 and 10.0

I hope this helps. It´s the output of vgscan and vgchange from both SuSE 9.3 and 10.0. 9.3 can activate the LVM group named lotus

Some additional information about the disk layout:

/dev/hdf1               1         638     5124703+   7  HPFS/NTFS
/dev/hdf2   *         639        5005    35077927+   5  Erweiterte
/dev/hdf5             639         704      530113+  83  Linux
/dev/hdf6             705        5005    34547751   8e  Linux LVM

/dev/hde1   *           1         638     5124703+   7  HPFS/NTFS
/dev/hde2             639        5005    35077927+   5  Erweiterte
/dev/hde5             639         704      530113+  82  Linux Swap / Solaris
/dev/hde6             705        5005    34547751   8e  Linux LVM

/dev/hdf5 is the root partition. All other partition are within the volume group lotus with approx. 70GB of space.

Thanks for the logs. The problem looks pretty strange.
It seems that LVM version of SL 10.0 is somehow unable to match PE size of the 
VG lotus correctly. Could either be a general bug in new LVM handling old style
PVs or there were additional checks added in new LVM that uncover an 
inconsistency that was not detected in older LVM version. I will have to look
into sources of both LVM versions to be able to say more.

Manwhile the following additional information would be helpful:
- Do you still know with which LVM version you created the VG lotus?
- Did you do something unusual with this VG (e.g. vgconvert/vgimport/vgexport/
  vgsplit)
- Did you use EVMS on SL 9.3
- please attach the output of "vgdisplay -v lotus" in SL 9.3
- please attach the complete content of /etc/lvm in SL 9.3

Maybe the following would work around your problem:
- converting the VG metadata to new on disk format in SL 9.3 with vgconvert
- try if the VG is successfully detected in SL 10.0

But be aware that this involves some risk. If the problem is not caused by
a bug in new LVM version but by an incosistency in your VG on SL 9.3 that
is simply undetected on old LVM version it might be possible that you make
your VG unreadable also under SL 9.3. So I would strongly suggest to backup
your valuable data just in case. If you try to vgconvert I would 
appreciate if you provide me the information I requested before you 
vgconvert the VG.

Created attachment 55582 [details]
vgdisplay output and content of /etc/lvm

I'm not sure but i think i originally created the volume with SL 9.0. I did not use EVMS and the only actions on the volume was to resize logical volumes. 

I would try the vgconvert this weekend after backing up the valuable data (which is /srv/ftp, all /home stuff is imported via nfs).

Thanks for the log files, on a quick look there was nothing unusual in the
metadata of your VG. I assume it is indeed a bug in lvm version on SL 10.0.
So the workaround using vgconvert should indeed help (of course I nevertheless
would advice to make a backup of valuable data anyway ;-).

I will have a look at the sources as soon as possible but unfortunately I am
busy with other tasks yet, therefore I will probably not be able provide
a fix really soon. Since the problem seems to happen when reading the
on disk metadata the following data would be very helpful to reproduce and
verify the bug locally.

dd if=/dev/hde6 of=metadata.hde6 bs=512 count=4174
dd if=/dev/hdf6 of=metadata.hdf6 bs=512 count=4174

This copies the complete metedata area of both PVs into the two files 
metadata.hde6 and metadata.hdf6. With this data I am probably able to reproduce
the problem locally after I write this metadata onto two partitions of appropriate size. Please attach this data to this bug.

I would be very interested if the workaround with vgconvert worked.

Created attachment 55624 [details]
Metadata from hde6, hdf6

Here the requested metadata. I hope this helps. Will try to convert. vgconvert -M2 lotus should be the command?

Thanks for the logs, as expected I could reproduce the problem here after
I copied the metadata to partitions of sufficient size.

Yes, "vgconvert -M2 lotus" should covert the PVs to new on-disk metadata format.
To be on the save side I would convert it while the VG is not activated (so you 
have to be either in a state where you can umount /var and /usr or you boot from
the SL 9.3 rescue system).

As you expected, after converting the volume group to LVM2 format, i can use the SuSE 10.0 installer to update my installation (but due to lots of third party packages from apt repos, there are so many unresolved dependencies, that i´ll better try a fresh installation).

Thanks for verifying this.
So at least there is a reasonably easy workaround.

I have now a fix for LVM.
The problem is that in LVM 2.01.12 added some checks for consistency that
fail for LVs with stripe sizes larger than 1 in VGs with old metadata format.

I fixed this for STABLE but wee need to fix this also in SLES9 SP3 since
we plan to use LVM 2.01.14 for SLES9 SP3. 

Gerald I need your approval to fix this also for SLES9 SP3.

If this is to avoid a regression, and since we already have the new version,
yes please!  Thanks for keeping this in mind, Thomas!

Yes, this is a regression intrduced with LVM 2.01.12.
I provided a package with this bug fixed in /work/src/done/SLES9-SP3/lvm2