Created attachment 621302 [details] custom partitioning Description of problem: anaconda, in custom partitioning puts 'the other os' partitions in a category called 'unknown'. If one click the + to expand the list, it works. if one then click the -, it just vanishes.... Version-Release number of selected component (if applicable): anaconda 18.11 How reproducible: always Steps to Reproduce: 1. enter custom partitioning 2. click + in 'unknown' (a really inspired denomination...) 3. then click the -, the whole 'unknown' tree goes to the tartarus Actual results: might confuse or interfere with the partitioning of the disk. Expected results: nothing should vanish by just clicking in the - Additional info: F18b TC1
Created attachment 621303 [details] custom partitioning, clicking the + on the 'unknown'
Created attachment 621304 [details] custom partitioning, this is the result of clicking the - on the 'unknown' please note that 'unknown' is not there
We are unable to reproduce this. Can you attach /tmp/anaconda.log, /tmp/storage.log, and /tmp/syslog to this bug report? Thanks.
I will need to restore (reinstall) the guest, since anaconda wiped the ntfs (the other os) partition. After the 'unknown' tree disappeared i used the previous 'root' and 'swap' and installed to those. No errors were displayed. I did not use both the previous /boot neither the nfst (which had disappeared previously). These 2 partitions should have been kept untouched by anaconda. The ntfs partition got transformed into ext4 (and it is empty, just lost+found). The small 500mb old /boot remained intact. It seems whatever 'disappears' is in danger if one continues installing, even to another partition. If i can reproduce it, i will attach the logs.
Created attachment 621811 [details] reproduced, anaconda.log 15:48:15,382 DEBUG anaconda: [2] Destroy Format ntfs filesystem on partition sda1 (id 1) 15:48:15,382 DEBUG anaconda: [3] Create Format ext4 filesystem on partition sda1 (id 1) 15:48:15,383 DEBUG anaconda: duplicating action '[2] Destroy Format ntfs filesystem on partition sda1 (id 1)' 15:48:15,390 DEBUG anaconda: duplicating action '[3] Create Format ext4 filesystem on partition sda1 (id 1)
Created attachment 621812 [details] reproduced, syslog
Created attachment 621813 [details] reproduced, storage.log
I reproduced the issue, and installing when affected with the issue causes anaconda to wipe the 'other os' instance.
Created attachment 621842 [details] F18b TC2, snapshot before the ntfs partition dissapeared I tried with F18b TC2, to reproduce the issue try these methods: method #1: * Enter Installation Destination, select a disk (1 disk in this case) * select 'i dont need help [...]' * click the ntfs partition The ntfs partition disappears. (the small 500mb ext4 partition remains, so 'Unknown' tree remains) method #2: * Enter Installation Destination, select a disk (1 disk in this case) * select 'i dont need help [...]' * click the ext4 partition The ntfs partition disappears. (the small 500mb ext4 partition remains, so 'Unknown' tree remains) method #3: (the reported one) * Enter Installation Destination, select a disk (1 disk in this case) * select 'i dont need help [...]' * click the - to collapse the 'Unknown' tree The ntfs partition disappears. (the small 500mb ext4 partition remains, so 'Unknown' tree remains)
This is specific to filesystem types that the installer can recognize but cannot create. The only example of such a filesystem I can think of is ntfs. Anyway, we're working on a fix.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. 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.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.