Description of problem: Version-Release number of selected component (if applicable): anaconda 18.18-1 anaconda 18.19-1 Fedora-18-Beta-TC5-x86_64-Live-Desktop.iso How reproducible: Steps to Reproduce: 1. Install F18TC: root, boot, home all BTRFS reboot. 2. Boot from same livecd installer (tried both 18.18 and 18.19) 3. Installation Destination 4. "don't need help...customize disk partitioning" Actual results: 1. Only "New Fedora 18 Installation" and "Unknown" appear. 2. The previous F18TC5 installation appears under Unknown. Expected results: It should be recognized and appear in a known/labeled heading, not as Unknown. Additional info:
Created attachment 630328 [details] livecdTC5_18.18.png Shows previous F18 installation under Unknown.
Did you complete the previous install all the way through, such that a fedora-release package is installed?
The previous install completed successfully.
FWIW this is not reproducing with a TC6/anaconda 18.19 based install or reinstall attempt.
Created attachment 633080 [details] All *.log and *.state Reproduced in TC6/anaconda-18.19-1 with a successful prior installation to a 2-disk (raid0) btfs installation. Attaching logs at the point where I'm in Manual Partitioning looking at the previous installation listed under Unknown. Possibly what's hanging this up (?) is if it's looking for /etc/fedora-release on an unmounted filesystem. On btrfs anaconda places rootfs on a subvol named root. When not mounted, the root subvol is like a folder called root, so the location from this perspective is /root/etc/fedora-release, UNLESS the btrfs file system is mounted and using subvol=root in which case the file is /etc/fedora-release.
Reproduced again in TC6/anaconda-18.19-1 attempting to install over a successful prior installation to a 1 disk btrfs installation. I think this is a btrfs subvol issue honestly, and should be reopened whether fixed for F18 or not. Eventually it will need to be fixed a btrfs installs become more common. Comment 4: when I use the default installation (ext4), and then attempt to install over that, the problem is not reproducible.
If the original case isn't fixed, re-open the bug.
I don't appear to have that option? I can change status from closed to assigned, that's it.
It looks like btrfs has changed the format of the subvolume list, which of course breaks our code that tried to parse it. This game never gets old.
I think there are more issues about how to present btrfs volumes: How will anaconda behave if the user, or some future feature of Gnome packagekit, were to create snapshots of root before each weekly Fedora update? Will anaconda find 52 identical copies of fedora-release? And then what? The btrfs subvol is like GPT's 128 partition entries, except that no one comes close to using very many GPT entries, whereas it's entirely plausible a single btrfs volume will contain dozens, hundreds or thousands of subvols. I could take a snapshot every hour, and after 24 hours delete only 23 of them, in effect having a snapshot every hour for the past day. And a snapshot per day for a month. And a snaphot per week for a year. Totally valid. But how will anaconda react to this many subvolumes? And also if Ubuntu or some other distribution installs within its own subvolume? And also is snapshotting itself?
Probably should either call the ioctls directly from anaconda to keep this sort of problem from happening again or add a python interface to btrfs-progs so you can always get what you need.
Proposing as NTH for F18 Beta since it prevents the installer from recognizing existing btrfs setups that include subvols.
Discussed at 2012-10-31 NTH review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-31/f18beta-blocker-review-6.2012-10-31-16.00.log.txt . We agreed that existing installs with btrfs subvols are just too uncommon for this to rank as NTH, especially as it's an inconvenience not a showstopper, and it wasn't possible to do a btrfs install interactively with F17 (or F16, I think). This really isn't serious enough to merit a freeze break, considered properly.
David says he'd like this discussed again, as he identified some consequences that we were not aware of during the discussion. <dlehman> well, it means we just plain can't detect existing subvols so if you have btrfs your option is to leave it or remove the whole thing, which may not be the end of the world more seriously: <dlehman> adamw: another consequence of that patch being reverted: it's impossible to remove the existing btrfs via anaconda because anaconda thinks there are subvols but the names are wrong so btrfs errors when you try to remove them. Re-proposing. We have the follow-up meeting tomorrow, where we can discuss this again.
anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.22-1.fc18
Package anaconda-18.22-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.22-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17432/anaconda-18.22-1.fc18 then log in and leave karma (feedback).
Discussed at 2012-11-01 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-11-01/f18beta-blocker-review-6.5.2012-11-01-17.49.log.txt . Accepted as NTH with the new information that this means anaconda actually cannot delete btrfs subvol setups, not just that they're not properly detected as existing installs.
anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.23-1.fc18
anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.24-1.fc18
anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.25-1.fc18
*** Bug 872849 has been marked as a duplicate of this bug. ***
The proposed/applied fix for this was incomplete. I'll be sending out a corrected version for review soon.
anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.26-1.fc18
Package anaconda-18.26-1.fc18, lorax-18.22-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.26-1.fc18 lorax-18.22-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17714/lorax-18.22-1.fc18,anaconda-18.26-1.fc18 then log in and leave karma (feedback).
anaconda-18.27-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.27-1.fc18
18.26 went stable. Closing. (Bodhi closing of bugs when updates go stable is currently broken).
Bug still present in TC3. Did not save logs so can't contribute further. Will deleted subvol in running system, then reinstall using TC3.
And, to make matters worse, original installation is now unbootable.
(In reply to comment #27) > Bug still present in TC3. Did not save logs so can't contribute further. > Will deleted subvol in running system, then reinstall using TC3. I cannot reproduce, Manual Partition sees the subvols but I can't use them for anything other than home. This is undesirable behavior but expected. (In reply to comment #28) > And, to make matters worse, original installation is now unbootable. Please file a new bug with clear step by step and includes logs and cc me on it.
Useless to file bug now since I did not keep the logs and used a live CD to delete all of the original TC2 partitions and then reinstalled with TC3. As I recall, one of the install attempts went far enough to reformat original /boot such that all I got on boot attempt was grub2 complaining something about missing UUID. Bottom line: if a user takes a default btrfs install on new hardware and then screws it up to the point that all they can do is reinstall, they won't be able to as long as the partitioner cannot remove old btrfs partitions. Screwing up a btrfs installation is much more likely that a LVM or standard partition installation. Tell you what, when TC4 comes out, if it comes out, I will try to reinstall over the existing installation and will keep logs somewhere I can get to them. BTW, shouldn't this bz be re-opened?
(In reply to comment #30) > Useless to file bug now since I did not keep the logs and used a live CD I think it's useless to experience catastrophic install failure resulting in a non bootable system, and not keep logs and file a bug. >Bottom line: if a user takes a default btrfs install on new hardware and then >screws it up to the point that all they can do is reinstall, they won't be able >to as long as the partitioner cannot remove old btrfs partitions. This is not detailed enough. I cannot reproduce this behavior. >BTW, shouldn't this bz be re-opened? No the bug as reported and described is fixed. I just tested it again with TC3 + anaconda 18.37.4-1 and this bug isn't triggered. a.) Manual Partition sees btrfs subvols, b.) they appear correctly under "Fedora Linux 18 for x86_64" rather than under "Unknown" as stated in the bug description. So whatever you've found, which you haven't described well enough for someone else to even reproduce, nor do you have logs for, needs a new bug.
(In reply to comment #31) > (In reply to comment #30) > <snip> > I think it's useless to experience catastrophic install failure resulting in > a non bootable system, and not keep logs and file a bug. > If I had known the system wasn't going to boot, then I would have kept the logs. The bz reporter said that my problem was a duplicate and it should have kept the logs to attach to the original reporters bz. Why don't you fix that? <snip>> > So whatever you've found, which you haven't described well enough for > someone else to even reproduce, nor do you have logs for, needs a new bug. Very motivating, you can be sure that if I find this again, I probably will not report it. Your attitude is one that is creeping in more and more in the Fedora community and it is a real turn off.
If you don't have logs it's impossible for anyone to fix the bug. It's not a question of attitude.