Bug 144827 - RHEL 4 U1: Autopartitioning during install maintains old filesystem labels
Summary: RHEL 4 U1: Autopartitioning during install maintains old filesystem labels
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Frank Hirtz
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 137160
TreeView+ depends on / blocked
 
Reported: 2005-01-11 19:57 UTC by Amit Bhutani
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version: RHBA-2005-192
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-20 20:03:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Anaconda Dump (777.76 KB, text/plain)
2005-04-20 09:24 UTC, Charles Rose
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:192 0 low SHIPPED_LIVE lvm2 bug fix and enhancement update 2005-06-09 04:00:00 UTC

Description Amit Bhutani 2005-01-11 19:57:10 UTC
Description of problem:
During install, if "Autopartition" is selected, the installer creates 
the /boot partition, LVM partitions on all available drives and 
creates logical volumes within them. 

If one of the drives (besides the one with the /boot partition) 
contains a partition with "/boot" filesystem label, the installer 
does not delete/overwrite this. Installation completes successfully 
and we see a message during the next reboot

--------------------------------------------------------------
mount: LABEL=/boot duplicate - not mounted
--------------------------------------------------------------

As a result of the above problem, the REAL /boot does not get 
mounted. /etc/grub.conf is not accessible (as it is a softlink 
to /boot/grub/grub.conf). When a new kernel rpm is installed, the new 
kernel image is copied to /boot directory which is actually on 
the "/" filesystem. The system therefore cannot be started with the 
new kernel.

Version-Release number of selected component (if applicable):
anaconda-10.1.1.11-1

How reproducible:
Easy

Steps to Reproduce:
1. Setup a system with 2 hard drives with second drive having a /boot 
label.
2. Install RHEL 4 pre-rc2 on it with autopartioning + "Delete all 
partitions" option
3. Install a newer kernel
4. Reboot the machine 
  
Actual results:
- The following message is displayed:
"mount: LABEL=/boot duplicate - not mounted"
- New installed kernel does not show up in grub menu

Expected results:
- No error messages on boot
- Should be able to boot into new kernel

Additional info:

Comment 1 Jeremy Katz 2005-01-11 20:12:09 UTC
Did you select to ignore the first drive?  Also, what's the filesystem
type on the other /boot?

(note that we don't really support dual-boot of Linux)

Comment 2 Amit Bhutani 2005-01-11 20:18:48 UTC
> Did you select to ignore the first drive?
No.
> Also, what's the filesystem type on the other /boot?
ext2
> note that we don't really support dual-boot of Linux
Understand. This is not a dual-boot configuration attempt....just a 
plain Linux install with default autopartioning.



Comment 3 Matt Domsch 2005-01-11 20:39:38 UTC
Jeremy, I'm pretty sure the autopartitioning decided it didn't need 
to use one of the available disks, so it didn't touch it, leaving the 
existing partition table and file systems intact there.

Comment 4 Amit Bhutani 2005-01-12 01:16:18 UTC
To re-iterate:
I used a system with 2 disks and chose the following options:
1. Autopartioning 
2. Remove all partitions on this system
3. Select the drive(s) you want to use for this installation --> I 
selected both 'sda' and 'sdb'

Question: Irrespective of the state the drives are in, shouldn't step 
#3 wipe everything (partition table, label info, fs et.al) from all 
selected disks, in this case being sda and sdb ?

Comment 5 Jeremy Katz 2005-01-12 02:32:27 UTC
I would expect that by selecting to use both drives, you'd get
physical volumes comprising all of both drives (with the exception of
the space on sda for /boot).  What does the partition table look like
post-install?

Comment 6 Amit Bhutani 2005-01-13 22:10:02 UTC
The partition table is exactly what you have described:
/boot --> regular fixed size ext2 partition on disk 1
swap --> LVM partition on disk 1
/ --> LVM partition spanning all available disks (in the case of the 
two SCSI disk system this would span sda and sdb)

The ironical part of this issue is that the WARNING message - "All 
partitions (DATA) will be lost on the following disks: sda sdb" is 
displayed yet the duplicate /boot label on sdb is left intact.

Comment 7 Jeremy Katz 2005-01-13 22:18:46 UTC
This is being caused by the LVM tools not properly wiping the ext3
metadata when creating a PV then.

Comment 8 Jeremy Katz 2005-01-13 22:40:55 UTC
Wrong lvm.

Comment 9 Alasdair Kergon 2005-01-13 23:28:57 UTC
pvcreate has been fixed to do this in 2.00.33.

Comment 10 Alasdair Kergon 2005-01-13 23:30:25 UTC

*** This bug has been marked as a duplicate of 140329 ***

Comment 11 Amit Bhutani 2005-01-13 23:52:10 UTC
Official RC has lvm2 version 2.00.31-1.0. Will 2.00.33 be in Gold ?

Comment 12 Jay Turner 2005-01-14 07:23:06 UTC
Not likely.  The official RC version is it unless something tragic happens.

Comment 13 Alasdair Kergon 2005-01-14 10:03:35 UTC
Planned to be included in U1.

Comment 16 Matt Domsch 2005-02-21 16:51:05 UTC
*** Bug 149220 has been marked as a duplicate of this bug. ***

Comment 18 Jay Turner 2005-04-16 18:38:44 UTC
Moving to PROD_READY.

Comment 19 Charles Rose 2005-04-20 09:15:08 UTC
On RHEL4 U1 Beta we see a Python exception:
I installed two identical PE2850 machines (A and B) with single SCSI disks (No
RAID) with the autopartitioning scheme. Disks on both machines were at SCSI ID0.
The partitions on both the disks (from machine A and machine B) were:
   sda1 (ext3, /boot)
   sda2 (LVM2)
After installation, I moved the disk from machine B and plugged it in machine A
at SCSI ID1 and started the installation (GUI).
I chose to do a fresh Install with autopartition. After the package selection
screen where we usually see the "Formatting" messages, anaconda throws an
exception (file attached) during "lvmremove". Repeated attempts have the same
results.

Comment 20 Charles Rose 2005-04-20 09:24:17 UTC
Created attachment 113399 [details]
Anaconda Dump

Comment 21 Charles Rose 2005-04-20 09:39:01 UTC
Regressed on RHEL4 U1 Beta: Defect has been fixed.
149220 is not a duplicate of this defect as it is still open.

Comment 22 Amit Bhutani 2005-04-20 20:03:59 UTC
The original issue which was the maintaining of stale fs labels has been 
resolved. I am closing this one and re-opening BZ149220 ("Python exception 
while creating LVM2 volumes") as that was mistakenly closed as a dup of this 
issue and that is still reproducible with U1 Beta.

Comment 23 Tim Powers 2005-06-09 12:29:58 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-192.html



Note You need to log in before you can comment on or make changes to this bug.