The BTRFS stuff isn't ready yet, hopefully by beta.

I can't even figure out how to use the new GUI to do something like create an LVM volume group from an old partition that currently contains and ext4 filesystem with an old install on it. It seems very bent on trying to use one of the layouts I currently have to install into. But even then it's not clear exactly what will be installed where.

The old gui was kind of clunky, but quite serviceable for most things. The only thing I couldn't do with it was install into a btrfs subvolume or create an encrypted swap partition that will be reformatted and re-keyed with a random key on boot.

(In reply to comment #2)
> I can't even figure out how to use the new GUI to do something like create
> an LVM volume group from an old partition that currently contains and ext4
> filesystem with an old install on it. 

What you want to do in this case is _remove_ that old partition with the ext4 filesystem on it. Then you can create a new device and, if you like, change its device type LVM.

The new custom partitioning interface defines devices based on what you actually want instead of making you build things up from disk to partition to lvm &c.

If you no longer want a partition/device, remove it by selecting it and clicking the minus button. If you want a new device, click the plus button. It will create a device of the default type, which you can change by clicking Customize and then choosing a new entry from the Device Type list. This is a far cleaner and simpler approach -- it's just going to take some getting used to for some people.


We will add support for using existing devices very soon, but support for creating new devices from existing containers will take a bit longer. If that's your chosen method, sorry -- you have chosen a method that requires some of the most advanced possible functionality from an OS installer. Your use-case was deemed both significantly less likely and significantly more difficult to handle than others.

(In reply to comment #3)
> We will add support for using existing devices very soon, but support for
> creating new devices from existing containers will take a bit longer. If
> that's your chosen method, sorry -- you have chosen a method that requires
> some of the most advanced possible functionality from an OS installer. Your
> use-case was deemed both significantly less likely and significantly more
> difficult to handle than others.

It's how I've set up every RedHat and Fedora system I've installed since LVM was available on the install screen. My modus operandi has been to create new filesystems for the new /, /var, (and sometimes /var/log) partitions from the LVM volume group holding everything, use the existing swap and /tmp partitions (though recently I've taken to greatly increasing the size of swap and using tmpfs for /tmp), and then point at the existing /home partition and specify that it not be formatted.

But, I have no idea how anybody else does it. So it's quite possible that I might be highly unusual in this regard.

And, one last thing, then no more complaining by me in this bug.

I tried this one more time...  There is absolutely no way I can install this with the current state of Anaconda. It won't even use the existing /boot partition if I ask for a new /. I have no downgrade path. Additionally, the GUI doesn't make it clear that nothing else on my disk will be touched. Near as I can tell, if I create a new partition in free space and install into it, it will erase everything else on the disk. At least any hint that it exists completely disappears from the GUI once I ask for a new partition in the free space.

This is really distressing to me. I could just install and hope that the GUI is lying about all the other partitions disappearing. But then in order to get the thing to show the previous revision in the boot menu I have to basically create my own grub config file by hand. And grub2 is so complex I have no clue how to do that anymore. And I'd have to manually move all the stuff back into my careful and deliberate partitioning scheme after I installed, and that's providing the original partitions are left intact, which it looks like they'll all be wiped out.

Perhaps, for someone who's never installed Fedora in their lives, or only installs onto pristine fresh HDs and throws out the one for the old revision, or who blindly (and IMHO stupidly) trusts the upgrade process to not make a mistake, perhaps this current thing is just fine. But it's not for me, and it never will be. I've adapted to a lot of Fedora changes over the years and been generally very pleased, but this I just can't stomach.

It doesn't tell me devices names or partition numbers or anything. I have no clue what it's really doing or why. I feel like I'm going to destroy my whole HD just by touching the wrong button and I won't get any warning that I'm doing it.

This is the exact reason I've refused to use Ubuntu. Every time I try to install it it won't let me do what I want and insists on setting up all the partitions and everything its way. And if I try to adjust things to be my way later nothing works right anymore.

I've chosen my way because it allows me to carefully upgrade my system to new revisions while preserving the ability to boot back into the old one should it prove complex to upgrade software configurations (which I always do by hand because no automated process is going to handle that properly). My way carefully manages risk and always gives me an out should something go wrong somewhere in the process.

I feel blind, deaf, and dumb, like I'm fumbling in the dark with hands wrapped in plaster casts. I have no control. I have no ability to manage risk aside from pulling the HD and putting in a brand new one (which is a tricky proposition when you've always used RAID 1 and have an SSD as well). This is really saddening and upsetting. I don't know which distro I can use or trust anymore.

Hi Eric, thanks for your bug report. Just as a follow-up from our IRC conversation, what you're trying to do (preserve your old partitions, *not* reusing the containers but just not touching them, except for sharing /home with the new install) is ultimately planned to be possible, but as the new ui is currently under heavy development, it's not possible right now in F18 alpha.

So I really hope we'll be able to meet your needs soon when the new development is finished, and really apologize for the current state of things and that you had to miss out on test days. Hopefully using a live USB stick next time will help for doing nouveau testing.

Thanks!!

Patch posted that adds support for managing an LV's VG.

*** Bug 882447 has been marked as a duplicate of this bug. ***

Can we get a Beta2 please?  If I can't literally can't install anything until RC, something is wrong.

I've made an updates image against the beta that enables the use of a preexisting VG. To try it, add the following to your boot commandline:

 updates=http://dlehman.fedorapeople.org/updates/updates-f18b-860677.0.img

It's untested, so let me know if there are issues.

(In reply to comment #10)
> I've made an updates image against the beta that enables the use of a
> preexisting VG. To try it, add the following to your boot commandline:
> 
>  updates=http://dlehman.fedorapeople.org/updates/updates-f18b-860677.0.img
> 
> It's untested, so let me know if there are issues.

My first attempt gave me an immediate traceback.  It's in bug 884861.

(In reply to comment #11)
Also get a traceback for anaconda 18.29-2 and 18.36-1.

The "smoke 4" DVD mentioned in bug 884861 worked for me.

I just confirmed that with Final TC4, you can create new LVs in existing VGs no problem. You can even shrink an existing LV and create a new one in the space that's freed up and install to that and it all works.

Is there any need for this bug to be open any more? Is there still work it's covering, or did it just get lost in the mix? I don't know the status with btrfs, but current LVM status looks decent.

I believe the fix for this was:

https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-November/002199.html

acked by vpodzime on 11-29:

https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-November/002235.html

committed 11-30:

http://git.fedorahosted.org/cgit/anaconda.git/commit/?id=af8703cd6bafc9320429660003d0bd8f9ede07e3

said commit is present on f18-branch, and I just confirmed by testing that it works. So I'm pretty sure we can close this out. The btrfs case probably needs to be handled separately (there's likely already a bug to track it).

So, where can I find the ISO to download and test this for myself?

And the btrfs case is pretty important to me. So if there's a separate bug to track it, I'd like to know what it is please.

https://dl.fedoraproject.org/pub/alt/stage/18-TC4/ . give me a shout on IRC if you need any help with the interface, adamw on freenode (#fedora-qa).

https://bugzilla.redhat.com/show_bug.cgi?id=886691 looks like the bug you want for btrfs.

I think this bug can be closed as everything in the description for LVM and Btrfs was working as described in 18.37.8-1. It's even possible to put /boot in LVM and GRUB2 boots it; and /boot onto a boot subvol and GRUB likewise boots it.

The UI is still very confusing. And can't easily get a picture of which drives have which stuff on them. And my attempt to delete a partition and make a new one in the empty space resulted in it seemingly deleting another critical partition.

I think it decided that if I was deleting the one partition that must mean the other was fair game since the OS installed seemed to need both partitions to boot, which wasn't the case.

I still think Fedora 18 will not be installable for me. And I'm guessing no future revisions of Fedora will be installable. The UI appears to be going in the direction of trying to be very smart instead of be crystal clear and letting you do what you want. And the last thing I want when I'm partitioning drives is something that tries to outsmart me and deletes all of my data.

This is really vexing because I really don't like Ubuntu. Maybe I'll have to switch to CentOS.

I'm impressed by the quality of your crystal ball. I have trouble figuring what's going to happen next week.

Moving out of crazy future prediction territory and back to the land of sanity:

"I think it decided that if I was deleting the one partition that must mean the other was fair game since the OS installed seemed to need both partitions to boot, which wasn't the case."

No, it wouldn't do that. There is a checkbox for 'delete all other partitions that are part of this OS too', to save you time if you're wiping a whole install, but it is not checked by default. Unless you checked it, anaconda would not do that. I cannot tell what was actually going on without screenshots and/or a better description, but it is almost certainly not what you think.

"And can't easily get a picture of which drives have which stuff on them."

Yes, that's the key difference you have to understand with the new layout: it does not base its display around 'what devices are in what physical location on what drive' but around 'what devices are which parts of what existing OS installs'. It's just a different principle. You need to grok that principle and then how it works becomes a lot clearer.

I have seen an unselected mount point (partition) under Unknown vanish when the "delete all others" check box was not checked; but it was a while ago and always was followed by a crash. Version of anaconda? If reproducible with 18.37.[8,9,10] you need to file a bug with the installer logs found in /tmp.

The UI shows mount points, which may be comprised of one or more disks or partitions if the Device Type is LVM, RAID, or Btrfs. It can show true partitions  under "Unknown" if it doesn't have a way to piece together a previous install. But you need to think in terms of mount points first, device type and file system second, capacity third, and on what device these things are located last.

As for UI confusion, I find it's a problem for using existing pooled storage (dmraid, md raid, LVM, Btrfs) expressly because the user must know, and isn't aided in finding, what physical drives make up that pooled storage. 

Anyway, you're better off simply asking how the UI works, or how to do what you want, rather than critiquing because the mooring lines on F18 are being cut. UI feedback is in the realm of Rawhide/F19 now. And I'd ask them on test@ at this point unless you can clearly describe how this bug isn't fixed, because so far I've tested this pretty thoroughly and I'm able to get it to work.

Last, if you want to actively use an experimental file system, you need to use a distribution that's cutting out much newer kernels than Ubuntu does. I'm running 3.7.1-2 at the moment. Very few Btrfs fixes and almost no enhancements are being backported because of how active development is right now.

(In reply to comment #22)
> Yes, that's the key difference you have to understand with the new layout:
> it does not base its display around 'what devices are in what physical
> location on what drive' but around 'what devices are which parts of what
> existing OS installs'. It's just a different principle. You need to grok
> that principle and then how it works becomes a lot clearer.

So I get to forever unplug all the disks, install into a blank disk just for this purpose, then put in the disks back in after the install is finished so I can copy the data to the appropriate places?

Other than that, I can't see how I will be able to install with confidence. It already made an error in identifying systems because I have a partial root partition left over that I never deleted from when I created a special blank partition just to install Fedora 17 into and copy everything back into its proper places last time because btrfs support had gone completely missing from Anaconda.

And since those two partitions were basically the same install of the same OS, it's difficult telling them apart because it's such a pain to see what partition anything is on.

This is my crystal ball. That statement right up there. That way madness lies. You can't ignore the physical layout of your system, or obscure it. You'll just end up deleting things you never intended to because you can't tell where anything is.

Anyway, I'll make the stupid screenshots just to show you what I mean. It'll probably be tomorrow when I do it because I'm really sick and feeling very exhausted this evening. If posting links to them in an IRC channel is the right thing to do because Fedora 18 isn't going to be changing, that's what I'll do.

"So I get to forever unplug all the disks, install into a blank disk just for this purpose, then put in the disks back in after the install is finished so I can copy the data to the appropriate places?"

Um. What? No. That's not what I said at all. You can perfectly adequately modify, delete and/or re-purpose existing devices from the newUI custom part UI. It's just that it uses a different organizational principle for *displaying* them. Instead of thinking 'what disk is the partition I want to delete / reformat / reuse on and which number partition is it on that disk?', think 'what existing OS is the partition I want to delete / reformat / reuse a part of?', and you will find it in the partition group for that OS. You can select it and then perform any kind of operation you like on it - schedule it for removal or reformatting, and/or assign it a mount point within the new install.

"And since those two partitions were basically the same install of the same OS, it's difficult telling them apart because it's such a pain to see what partition anything is on."

That's a pretty unusual case, you've gotta admit. If you have a case that newUI currently doesn't handle terribly well, it's not as if it's terribly difficult to prepare things in parted first. If you can't tell which of two partitions you want to delete in newUI, well, wipe the correct one with parted first, then go ahead with the F18 install.

(In reply to comment #24)
F18 is in the oven already, no changing the batter. Please post details of your layout: number and size of disks, partition info, any md raid or LV info, Btrfs layout, so that it can be reproduced; might be easiest to boot from a Live CD, and 'yum install system-storage-manager', then 'ssm list' and post that. And then describe what your final goal is, and then describe the sequence you're using to arrive at that goal such that its reproducible by another. Your descriptions thus far are incoherent.

The only thing anaconda doesn't let me do with Btrfs volume reuse, is reuse an existing subvolume for Root. That must be created new, is intentional. You can reuse any other subvol for home, boot, usr, or var, although it's confusing because if you click on existing home, as soon as you click on the Mount Point field to type in /home, the previously selected subvol is deselected so it's unclear what you're modifying. So you have to remember what you just clicked on, and type in the proper mount point for each subvol you're reusing, then click Apply Changes (for which there's no feedback that it's had an effect, you have to go to New Fedora Installation to see the assignment has taken effect).

There is a dracut bug 890577 in TC4 and earlier that causes boot failure if /usr is on a usr subvol, with a work around and fix pushed to stable.