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.
Created attachment 304865 [details] The anaconda dump file
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.