Bug 144827 - RHEL 4 U1: Autopartitioning during install maintains old filesystem labels
RHEL 4 U1: Autopartitioning during install maintains old filesystem labels
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Frank Hirtz
Depends On:
Blocks: 137160
  Show dependency treegraph
Reported: 2005-01-11 14:57 EST by Amit Bhutani
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2005-192
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-20 16:03:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Amit Bhutani 2005-01-11 14:57:10 EST
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):

How reproducible:

Steps to Reproduce:
1. Setup a system with 2 hard drives with second drive having a /boot 
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 15:12:09 EST
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 15:18:48 EST
> 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
Understand. This is not a dual-boot configuration attempt....just a 
plain Linux install with default autopartioning.

Comment 3 Matt Domsch 2005-01-11 15:39:38 EST
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-11 20:16:18 EST
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-11 21:32:27 EST
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
Comment 6 Amit Bhutani 2005-01-13 17:10:02 EST
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 17:18:46 EST
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 17:40:55 EST
Wrong lvm.
Comment 9 Alasdair Kergon 2005-01-13 18:28:57 EST
pvcreate has been fixed to do this in 2.00.33.
Comment 10 Alasdair Kergon 2005-01-13 18:30:25 EST

*** This bug has been marked as a duplicate of 140329 ***
Comment 11 Amit Bhutani 2005-01-13 18:52:10 EST
Official RC has lvm2 version 2.00.31-1.0. Will 2.00.33 be in Gold ?
Comment 12 Jay Turner 2005-01-14 02:23:06 EST
Not likely.  The official RC version is it unless something tragic happens.
Comment 13 Alasdair Kergon 2005-01-14 05:03:35 EST
Planned to be included in U1.
Comment 16 Matt Domsch 2005-02-21 11:51:05 EST
*** Bug 149220 has been marked as a duplicate of this bug. ***
Comment 18 Jay Turner 2005-04-16 14:38:44 EDT
Moving to PROD_READY.
Comment 19 Charles Rose 2005-04-20 05:15:08 EDT
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
Comment 20 Charles Rose 2005-04-20 05:24:17 EDT
Created attachment 113399 [details]
Anaconda Dump
Comment 21 Charles Rose 2005-04-20 05:39:01 EDT
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 16:03:59 EDT
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 08:29:58 EDT
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.


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