Bug 140992 - Installer doesn't check for lvm signature on drive without partition table
Installer doesn't check for lvm signature on drive without partition table
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
7
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
FC4
:
: 154564 (view as bug list)
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2004-11-27 10:41 EST by Ariano Bertacca
Modified: 2008-06-16 21:09 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:09:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Gzipped anaconda dump file (anacdump.txt.gz) (2.00 KB, application/octet-stream)
2006-08-22 15:48 EDT, Len Reed
no flags Details

  None (edit)
Description Ariano Bertacca 2004-11-27 10:41:38 EST
Description of problem:
Maybe it's wrong to call this a bug, but it may cause data loss if
someone doesn't know what he's doing.

When using a lvm setup with multiple drives that are only being used
with lvm, you don't need to set up partitions on that drives. This
works fine with lvm, but when anaconda starts diskdruid while
installing/upgrading a fedora core installation, diskdruid offers to
write a partition table to that disks. I did not test what happens to
that disks if someone actually writes a partition table to a lvm used
disk, but it may cause data corruption or even loss of data.


Best regards

Ariano

How reproducible:
Always

Steps to Reproduce:
1. set up lvm without using partition tables on a harddrive.
2. install/upgrade fc on a system that contains one or more lvm used
harddrives.
    
Actual Results:  The installer offered to initialize the lvm hds ad
write a partition table on it without recognizing the lvm data on the
harddrives.

Expected Results:  Anaconda/Diskdruid should probably check for lvm
signatures on drives that seem to have no partition table and skip the
partition table init on such drives.

As there's a warning when "initializing" a disk without a partition
table on it, most people should be warned anyway. I also assume that
lvm users know about their hd setup, so it may be not a big problem at
all.
Comment 1 Jeremy Katz 2004-11-30 22:53:33 EST
We don't really support LVM on the bare disk without a partition table
for reasons like this.

Adding to a list to look into for FC4
Comment 2 Aaron Kurtz 2005-05-09 19:44:25 EDT
*** Bug 154564 has been marked as a duplicate of this bug. ***
Comment 3 Matt Domsch 2005-06-18 09:49:52 EDT
FC4 still has this behavior.  Furthermore, as my /home is really on 2 LVM-only
(no partition table) drives, anaconda refuses upgrade from FC3 to FC4, as it
says it can't mount /home.  My only choice was "OK" to reboot at that point, I
couldn't get to a shell to fix it manually.

 It did find and start my / file system which is on a partition+LVM (default FC3
install).
Comment 4 Matthew Miller 2006-07-10 19:24:18 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 5 Len Reed 2006-08-22 15:48:48 EDT
Created attachment 134665 [details]
Gzipped anaconda dump file (anacdump.txt.gz)

Ok, I don't understand Jeremy's comment #1, since making a drive a physical LVM
volume is perfectly legitimate and works great until you try to load or upgrade
FC (and maybe RHEL, too: didn't try that).

Using the FC5 DVD, I can neither upgrade nor install without destroying the PV
on /dev/hdg (on an IDE expansion card).  The upgrade or install fails even if I
don't want to do anything at all to that drive.  (That is, I can't upgrade the
root partition on /dev/hda.)

After clicking "Upgrading an existing installation" or "Install Fedora Core", I
get "Warning: The partition table of device hdg was unreadable.  To create new
partitions it must be initialized, causing the loss of ALL DATA on this
drive....Would you like to initialize this drive, erasing ALL DATA?"

If I say No, anaconda crashes.	(I'm not going to say Yes, I can't afford to
wipe that disk.)

"An unhandled exceptions has occurred.	This is most likely a bug..." (No
kidding!)

The attachment is what I get on a floppy when I dump the anaconda state.

I worked around this by unplugging the drive cable and upgrading root on
/dev/hda.  If I'd needed to upgrade on /dev/hdg I'd have been completely out of
luck.
Comment 6 Vic Ricker 2007-06-23 03:19:58 EDT
This is still a problem in F7.  Anaconda doesn't crash when you choose to not
wipe out your physical volumes but you can't continue with the installation if
you say "No".

I have my /home spread across 3 drives.  Two of which have no partitions.  I was
assuming that I'd be able to leave /home alone and install just the OS from scratch.

My gut tells me that the drives won't be touched unless I try to lay partitions
on them but the volume that they belong to is 1.1T and I only have space to
backup the critical files so I'm not going to risk it right now.  I have another
400G drive coming in about a week.  I may backup the rest of /home to the new
drive and try again later.

It would be nice if the installer would recognize these drives correctly or, if
the installer isn't really going to wipe them out, maybe that warning message
could be changed to explain what it's really going to do?
Comment 7 Bug Zapper 2008-05-14 07:53:34 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stopmaintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longermaintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, 
simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end 
of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it 
for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by 
events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If 
possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Bug Zapper 2008-06-16 21:09:51 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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