Red Hat Bugzilla – Bug 144827
RHEL 4 U1: Autopartitioning during install maintains old filesystem labels
Last modified: 2007-11-30 17:07:15 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
Version-Release number of selected component (if applicable):
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
3. Install a newer kernel
4. Reboot the machine
- The following message is displayed:
"mount: LABEL=/boot duplicate - not mounted"
- New installed kernel does not show up in grub menu
- No error messages on boot
- Should be able to boot into new kernel
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)
> 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.
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.
I used a system with 2 disks and chose the following options:
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 ?
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
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.
This is being caused by the LVM tools not properly wiping the ext3
metadata when creating a PV then.
pvcreate has been fixed to do this in 2.00.33.
*** This bug has been marked as a duplicate of 140329 ***
Official RC has lvm2 version 2.00.31-1.0. Will 2.00.33 be in Gold ?
Not likely. The official RC version is it unless something tragic happens.
Planned to be included in U1.
*** Bug 149220 has been marked as a duplicate of this bug. ***
Moving to PROD_READY.
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)
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
Created attachment 113399 [details]
Regressed on RHEL4 U1 Beta: Defect has been fixed.
149220 is not a duplicate of this defect as it is still open.
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.
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.