This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 868468 - installer fails to correctly detect preexisting btrfs subvolumes
installer fails to correctly detect preexisting btrfs subvolumes
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
AcceptedNTH
: Reopened
: 872849 (view as bug list)
Depends On:
Blocks: F18Beta-accepted/F18BetaFreezeExcept
  Show dependency treegraph
 
Reported: 2012-10-19 22:28 EDT by Chris Murphy
Modified: 2012-12-19 18:30 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-08 04:32:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
livecdTC5_18.18.png (26.44 KB, image/png)
2012-10-19 22:29 EDT, Chris Murphy
no flags Details
All *.log and *.state (26.83 KB, application/x-tar)
2012-10-24 19:02 EDT, Chris Murphy
no flags Details

  None (edit)
Description Chris Murphy 2012-10-19 22:28:36 EDT
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:
Comment 1 Chris Murphy 2012-10-19 22:29:45 EDT
Created attachment 630328 [details]
livecdTC5_18.18.png

Shows previous F18 installation under Unknown.
Comment 2 Chris Lumens 2012-10-21 22:12:44 EDT
Did you complete the previous install all the way through, such that a fedora-release package is installed?
Comment 3 Chris Murphy 2012-10-21 22:18:56 EDT
The previous install completed successfully.
Comment 4 Chris Murphy 2012-10-21 22:31:34 EDT
FWIW this is not reproducing with a TC6/anaconda 18.19 based install or reinstall attempt.
Comment 5 Chris Murphy 2012-10-24 19:02:59 EDT
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.
Comment 6 Chris Murphy 2012-10-25 01:16:36 EDT
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.
Comment 7 Adam Williamson 2012-10-25 01:23:57 EDT
If the original case isn't fixed, re-open the bug.
Comment 8 Chris Murphy 2012-10-25 02:25:39 EDT
I don't appear to have that option? I can change status from closed to assigned, that's it.
Comment 9 David Lehman 2012-10-25 17:03:35 EDT
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.
Comment 10 Chris Murphy 2012-10-25 18:20:24 EDT
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?
Comment 11 Josef Bacik 2012-10-26 10:05:08 EDT
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.
Comment 12 David Lehman 2012-10-29 12:19:33 EDT
Proposing as NTH for F18 Beta since it prevents the installer from recognizing existing btrfs setups that include subvols.
Comment 13 Adam Williamson 2012-10-31 14:08:09 EDT
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.
Comment 14 Adam Williamson 2012-10-31 19:07:50 EDT
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.
Comment 15 Fedora Update System 2012-10-31 22:50:39 EDT
anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.22-1.fc18
Comment 16 Fedora Update System 2012-11-01 14:25:58 EDT
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).
Comment 17 Adam Williamson 2012-11-01 17:52:49 EDT
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.
Comment 18 Fedora Update System 2012-11-02 00:04:02 EDT
anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.23-1.fc18
Comment 19 Fedora Update System 2012-11-02 21:03:23 EDT
anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.24-1.fc18
Comment 20 Fedora Update System 2012-11-05 20:38:34 EST
anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.25-1.fc18
Comment 21 David Lehman 2012-11-06 18:01:46 EST
*** Bug 872849 has been marked as a duplicate of this bug. ***
Comment 22 David Lehman 2012-11-06 18:02:51 EST
The proposed/applied fix for this was incomplete. I'll be sending out a corrected version for review soon.
Comment 23 Fedora Update System 2012-11-06 21:08:50 EST
anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.26-1.fc18
Comment 24 Fedora Update System 2012-11-07 13:46:09 EST
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).
Comment 25 Fedora Update System 2012-11-07 22:23:11 EST
anaconda-18.27-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.27-1.fc18
Comment 26 Adam Williamson 2012-11-08 04:32:37 EST
18.26 went stable. Closing. (Bodhi closing of bugs when updates go stable is currently broken).
Comment 27 Clyde E. Kunkel 2012-12-18 12:52:28 EST
Bug still present in TC3.  Did not save logs so can't contribute further.  Will deleted subvol in running system, then reinstall using TC3.
Comment 28 Clyde E. Kunkel 2012-12-18 13:04:16 EST
And, to make matters worse, original installation is now unbootable.
Comment 29 Chris Murphy 2012-12-18 14:59:18 EST
(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.
Comment 30 Clyde E. Kunkel 2012-12-18 20:40:54 EST
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?
Comment 31 Chris Murphy 2012-12-19 00:01:26 EST
(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.
Comment 32 Clyde E. Kunkel 2012-12-19 10:05:58 EST
(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.
Comment 33 Adam Williamson 2012-12-19 18:30:51 EST
If you don't have logs it's impossible for anyone to fix the bug. It's not a question of attitude.

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