Bug 445680

Summary: Labeling but not Formatting Existing Partitions Crashes FC8 Install
Product: [Fedora] Fedora Reporter: Bill Gorder <w.gorder>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-09 09:46:38 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:
Attachments:
Description Flags
The anaconda dump file none

Description Bill Gorder 2008-05-08 14:12:12 UTC
Description of problem:
I did a new install (not upgrade) of 64 bit Fedora Core 8 to a system that had
been running Fedora Core 6.  I chose to reuse my previously defined partitions
and used the custom option.  Most of the partitions I formatted, defined as ext3
and labeled.  For three mountable partitions (defined as "noauto,user" in FC6) I
tried to relabel them, but not format them.  This scenario resulted in anaconda
crashing.  I tried lots of variations and in the end I think I just didn't
"touch" the mountable partitions in the custom partition step.  This allowed the
install to complete, but even on this case warnings were issued.  I recovered
one of them from /var/log/anaconda.log and it is shown immediately below.

20:17:07 CRITICAL: parted exception: Error: Error informing the kernel about
modifications to partition /dev/sda5 -- Device or resource busy.  This means
Linux won't know about any changes you made to /dev/sda5 until you reboot -- so
you shouldn't mount it or use it in any way before rebooting.

I think the problem is the process doesn't handle a custom defined partition for
pre-existing partitions where only some of them are labeled, formatted, and have
a file type defined.  It especially doesn't handle attemting to relabel one of
these partitions without also formatting and specifying a file type.  To help
identify the "problem" partitions in the dump look for /mnt/tdisk, /mnt/work1,
and /mnt/work2

The consequence of this to a user is that even though the install "worked", the
system wouldn't boot because the previous labels of these three partitions were
incompatible with FC8 (because FC8 defines all of my drives as /dev/sd? where
FC6 defined some of the as /dev/hd?).  I recovered from this (thanks to Knoppix)
by relabeling the partitions offline.

Note that I am up and running and not looking for anything further from you. 
This information is provided with the hope that it may help improve a great
product and maybe help someone else.

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


How reproducible:
This should be easy to reproduce

Steps to Reproduce:
1.Existing partition not needed by OS in custom partition part of install
2.Relabel the partition but do not format or define a file type
3.
  
Actual results:
Install fails and dumps

Expected results:
Successful install

Additional info:Not accessing the existing partition during the custom
partitioning step allows install to complete, but may have undesirable side
effects as explained above.

Comment 1 Bill Gorder 2008-05-08 14:12:12 UTC
Created attachment 304865 [details]
The anaconda dump file

Comment 2 Joel Andres Granados 2008-05-09 09:46:38 UTC
In rawhide we are trying to avoid the whole label thing.  It bring a lot of
unnecessary complexity to the equation.  We are now using the uuid, so the issue
where your installation will not boot due to a label conflict is not the case
anymore.  If you see similar behavior with f9 or rawhide, please reopen this bug.