Hide Forgot
Description of problem: as in the 0.7 version, pv is created on /dev/disk/by-id/dm-name-3600a0b80005b0acc00008c204c7744bap3, butnot /dev/mapper/3600a0b80005b0acc00008c204c7744bap3, this make the rhev-hypervisor treat it as 2 different disk, specify "storage_init=/dev/mapper/360*" path, then it will fail with "There appears to be an installation on another disk /dev/disk/by-id/dm-name-3600a0b80005b0acc00008c204c7744bap3" Version-Release number of selected component (if applicable): rhev-hypervisor 6.2-0.7 How reproducible: always Steps to Reproduce: 1.installed rhev-hypervisor (not limited to 6.2-0.7) 2.auto install rhev-hypervisor with "storage_init=/dev/mapper/360*ba" 3. Actual results: Expected results: Additional info:
Created attachment 515435 [details] auto reinstall fail
Please try w/o rd_NO_LVM in bootparams.
Please provide full kernel cmdline you're using (console log or the complete pxelinux.cfg)
Created attachment 515826 [details] console output
> 2.auto install rhev-hypervisor with "storage_init=/dev/mapper/360*ba" That was the important part: ovirt-cleanup dracut module (added to fix reinstall issues - bug 688168) does not expand wildcard, we'll fix that and in the meantime workaround is to not use wildcards. Also important for automated reinstall is that both storage_init _and_ firstboot (or alias reinstall) boot parameters are present.
Code is actually written to handle wildcards in the same way that ovirt-early does. The problem is related to dracut itself and it's handling of parameters. When trying to read storage_init with a wildcard, it automatically expands it. The plugin wasn't expecting or handling this. Example with storage_init=/dev/vd* # cat /proc/cmdline initrd=initrd0.img root=live:CDLABEL=rhev-hypervisor rootfstype=auto ro liveimg nomodeset check rootflags=ro crashkernel=512M-2G:64M,2G-:128M elevator=deadline processor.max_cstate=1 install quiet rd_NO_LVM rhgb rd_NO_LUKS rd_NO_MD rd_NO_DM console=ttyS0,115200n8 storage_init=/dev/vd* firstboot local_boot BOOTIF=eth0 rdbreak BOOT_IMAGE=vmlinuz0 # getarg storage_init /dev/vda /dev/vda1 /dev/vda2 /dev/vda3 /dev/vdb /dev/vdb1
Created attachment 515921 [details] Patch Issue was that /dev/mapper/360* would get expanded earlier than expected which broke the functionality later. Testing: Pretty much all uninstall and reinstall tests should be re-run Specifically, run uninstall/reinstall with patterns like /dev/vd* /dev/vda,/dev/vdb /dev/vda;/dev/vdb /dev/vda,/dev/vdb;/dev/vdc /dev/vd*;/dev/vdb check outputs to ensure that it's trying to clean up the correct filesystem.
upstream patch (in 2.0.1): http://git.fedorahosted.org/git/?p=ovirt/node.git;a=commitdiff;h=fca41445ae8fa451639d28105a10746a86b7eb1a
Created attachment 518242 [details] serial console output
The issue with multiple disks and wildcards is captured in bug 726843, moving back to ON_QA
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1783.html