Bug 445680 - Labeling but not Formatting Existing Partitions Crashes FC8 Install
Labeling but not Formatting Existing Partitions Crashes FC8 Install
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-08 10:12 EDT by Bill Gorder
Modified: 2008-05-09 05:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-09 05:46:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The anaconda dump file (73.17 KB, text/plain)
2008-05-08 10:12 EDT, Bill Gorder
no flags Details

  None (edit)
Description Bill Gorder 2008-05-08 10:12:12 EDT
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
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 10:12:12 EDT
Created attachment 304865 [details]
The anaconda dump file
Comment 2 Joel Andres Granados 2008-05-09 05:46:38 EDT
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.

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