Bug 426093

Summary:	2 anaconda installations on a single system use conflicting partition labels
Product:	Red Hat Enterprise Linux 5	Reporter:	Chris Pepper <pepper>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.1
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-06-21 16:07:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Pepper 2007-12-18 14:17:25 UTC

Description of problem:
I installed RHEL5.1 on sda. Then I did another install onto sdb to test my kickstart.
anaconda used the same labels on sdb as on sda (as it does on everything), meaning that when I 
booted from sdb1 (/boot), I got the rest of the filesystems from sda, and lots of things broke.

Since anaconda doesn't check for the presence of labels before using assigning labels to partitions, it's 
impossible to do two anaconda installs onto the same system without conflicts which require manual 
resolution.

Version-Release number of selected component (if applicable):
RHEL 5.1

How reproducible:
Always.

Steps to Reproduce:
1.Install onto partitions on sda.
2.Install onto partitions on sdb.
3.Reboot. 

Actual results:
anaconda leaves GRUB pointing to sdb, but when booted /boot on sdb1 mounts the earlier filesytems 
on sda by labels.
Things break, particularly modules.

Expected results:
anaconda should not assign labels without checking to see if they're in use.

Additional info:
kickstart should have an option to use partition devices rather than labels.

Comment 1 Chris Lumens 2008-06-21 16:07:58 UTC

The next major release of RHEL will be using UUIDs for partition identification
instead of labels, so you should no longer be seeing these sorts of problems. 
If you require this fix in an update release of RHEL5, please talk to your
support representative who will raise it to us through the appropriate channels.