Fedora 19 Beta Released With Lots Of New Work

[Vim_User]

Yes I except of course bugs in betas, I even except bugs in stable releases... but not in the installer, the whole point is to be able to test the distro to find bugs. if nobody is able to install the distro nobody will find bugs in the distro.

How do you expect the installer to be bug-free if nobody tests it? Why should an alpha or beta of a distro (which always includes the installer) be bug-free before the alpha or beta?

Ok maybe its here a special case because of this anaconda switch, maybe I am here pampered by debian or ubuntu, becuase (if you want lvm stuff you need the alternate installer in ubuntu which is the debian installer) always everything works ever even in each alpha.

That comment only shows that you never tested the daily builds of Debian, they have the same problems with the installer, sometimes for days, until somebody reported it, so it can get fixed. See the pattern?

Like I said if somebody took that personal I am sorry but please stop insulting me just because I said maybe something bad about your distro.

I can't see why pointing out flaws in your expectations (it is a beta, it has bugs) and in your behavior (it is a beta, so report the fucking bugs, especially when it is a show-stopper, that is what a beta is for) is insulting you. Also, I am not a Fedora user.

I am a developer

I then can only hope for you that the users of your software are more willing to file bug-reports than you.

[gilboa]

While I agree with minimal use of Anaconda, there (apparently) were reasons for dumping the old one and starting from scratch. Those I can think of are improved graphics and multi-threading. So I'm wondering if it will be possible in some future iteration to just launch gparted and system-config-lvm directly from Anaconda, thus maintaining some semblance of consistency between the install tools and the installed. (Pure speculation dept. One additional quirk is such tools require fairly complete online documentation. Gparted is good as-is, its manual is accessed from its Help menu. Somebody (yeah yeah, I know) would have to convert the lvm man page to html appropriate for the system-config-lvm gui. Then there's mdadm, which hasn't yet a gui at all. (Actually... Hmmmm. Am I [I]that[/] desperate for another time sync?)

Actually, being a developer myself, I can certainly understand the reasons for rewriting anaconda: code decay.
I would imagine that the old anaconda reached the point that bolting in new features was a complete nightmare (let alone supporting new hardware).
However, in my view the anaconda team made one crucial mistake: They decided to target Joe-six-pack users at the expense of power users. (especially given Fedora's role as a test ground for the next RHEL...)

Hopefully by F22 anaconda will be regain most of the lost power user options.

As for using s-c-l (system-config-lvm) and gparted within anaconda - I very much doubt that it'll happen. I would imagine that RedHat will rewrite s-c-l (adding btrfs advanced options support) and make it a part of anaconda.

- Gilboa

[pipe13]

Actually, being a developer myself... as for using s-c-l (system-config-lvm) and gparted within anaconda - I very much doubt that it'll happen. I would imagine that RedHat will rewrite s-c-l (adding btrfs advanced options support) and make it a part of anaconda.

- Gilboa

Well, from both a development and project mismanagement viewpoint, it makes absolutely no sense whatsoever to write two identical very demanding GUIs - installed standalone and within anaconda -- when one will be much easier to maintain to the level of robustness demanded by sys admins of their tools. But it is Fedora, so we shall see.

[RahulSundaram]

Actually, being a developer myself, I can certainly understand the reasons for rewriting anaconda: code decay.
I would imagine that the old anaconda reached the point that bolting in new features was a complete nightmare (let alone supporting new hardware).
However, in my view the anaconda team made one crucial mistake: They decided to target Joe-six-pack users at the expense of power users. (especially given Fedora's role as a test ground for the next RHEL...)

Hopefully by F22 anaconda will be regain most of the lost power user options.

As for using s-c-l (system-config-lvm) and gparted within anaconda - I very much doubt that it'll happen. I would imagine that RedHat will rewrite s-c-l (adding btrfs advanced options support) and make it a part of anaconda.

- Gilboa

The installer redesign was never focused purely on just non technical users and it simply cannot be since the RHEL installer is just the same with some additional modules for handling subscriptions etc. If you look at the design mockups posted a long time back, you can see that all of the advanced functionality is part of the design.

https://fedoraproject.org/wiki/Anaconda/UX_Redesign

If any important advanced feature is missing at this point, it is just a matter of not having the resources to finish it all in one cycle and you should consider it a bug.

Anaconda uses the parted library (Anaconda developer is upstream maintainer as well) and you really need to be able to handle errors etc which you can't do by sticking gparted into Anaconda not to mention that the design needs to be cohensive and gparted doesn't cover much of the functionality Anaconda needs anyway but what is important here is that Anaconda team is increasingly depending on native OS components instead of their custom rolled up functionality (dependency resolving is handled by yum, networking is handled by networkmanager, they use bash instead of busybox etc) so the path forward is likely to have a single utility within the installer and outside it.

[gilboa]

The installer redesign was never focused purely on just non technical users and it simply cannot be since the RHEL installer is just the same with some additional modules for handling subscriptions etc. If you look at the design mockups posted a long time back, you can see that all of the advanced functionality is part of the design.

https://fedoraproject.org/wiki/Anaconda/UX_Redesign

If any important advanced feature is missing at this point, it is just a matter of not having the resources to finish it all in one cycle and you should consider it a bug.

I may have misrepresented my POV.
The anaconda team's resources are finite and limited - no doubt about it.
But IMHO, the decision -where- to place these resources first (read: Getting the "advanced" features first or getting the "default-and-easy" code first) was misguided - especially given Fedora's (and RH) target user-base.
Seems to me (feel free to correct me) that a -lot- of effort was spent on automating and stupid-proofing the LVM and RAID creation - at the expense of more-or-less-zero manual management (E.g. reserve empty space inside an LVM partition).

Anaconda uses the parted library (Anaconda developer is upstream maintainer as well) and you really need to be able to handle errors etc which you can't do by sticking gparted into Anaconda not to mention that the design needs to be cohensive and gparted doesn't cover much of the functionality Anaconda needs anyway but what is important here is that Anaconda team is increasingly depending on native OS components instead of their custom rolled up functionality (dependency resolving is handled by yum, networking is handled by networkmanager, they use bash instead of busybox etc) so the path forward is likely to have a single utility within the installer and outside it.

/+1 for s-c-l gaining MD raid management features

- Gilboa

[RahulSundaram]

But IMHO, the decision -where- to place these resources first (read: Getting the "advanced" features first or getting the "default-and-easy" code first) was misguided - especially given Fedora's (and RH) target user-base.
Seems to me (feel free to correct me) that a -lot- of effort was spent on automating and stupid-proofing the LVM and RAID creation - at the expense of more-or-less-zero manual management (E.g. reserve empty space inside an LVM partition).

- Gilboa

If you don't do the simpler features first, in some cases, you can't build advanced functionality on top and won't get enough feedback to make the base dependandable. Part of the design focus was streamlining some of the advanced functionality. I don't think that focus was misguided at all. It certainly reduces the support cost considerably (read: misfiled bugs, less support tickets, easier guides etc). Increasingly, the expectation that it is ok for enterprise software to be clunky is going away and that is a good thing.

[blackiwid]

So I thought I know the conditions when the bug happens... but on another machine the same happens.

It doesnt matter what language I select, I can add the lvm in anaconda or from the console. Lol I even pluged in a android phone because I did that on this pc where I could install it. Maybe its a timing problem or something because when I made all the screenshots the process took longer time.

But it says "no prepared harddisc" or something like that.

So I think you can cause this bug just by having any pc, try to install in a existing volume group maybe it matters that I have a volume with the name root where ubuntu is on it. So maybe fedora wants this name or something.

But other than that this pcs have nothing in common.

If somebody post me a good link to the right categorie url where I can post this bug I do it.

So I could easily reproduce this bug on 3 pcs till now. I had even 15gb on this pc for root btw.

[pipe13]

So I thought I know the conditions when the bug happens... but on another machine the same happens.

It doesnt matter what language I select, I can add the lvm in anaconda or from the console. Lol I even pluged in a android phone because I did that on this pc where I could install it. Maybe its a timing problem or something because when I made all the screenshots the process took longer time.

But it says "no prepared harddisc" or something like that.

So I think you can cause this bug just by having any pc, try to install in a existing volume group maybe it matters that I have a volume with the name root where ubuntu is on it. So maybe fedora wants this name or something.

But other than that this pcs have nothing in common.

If somebody post me a good link to the right categorie url where I can post this bug I do it.

So I could easily reproduce this bug on 3 pcs till now. I had even 15gb on this pc for root btw.

Try https://bugzilla.fedora.com/. The index you seek is on the upper left side. Please search the DB for similar problem reports before submitting a new one. (Tedious, I know). Have you tried a basic installation on a non-lvm disk? Read the Installation Guide (http://docs.fedoraproject.org/en-US/...ide/index.html)? Asked around at http://fedoraforum.org/? (You'll frequently get quicker, more productive response to a not-a-bug there than from Bugzilla/) Thanks for your help and perseverence!

[RahulSundaram]

Try https://bugzilla.fedora.com

There is no such thing. You meant https://bugzilla.redhat.com although http://bugz.fedoraproject.org/anaconda is a easier shortcut in this case.

[gilboa]

If you don't do the simpler features first, in some cases, you can't build advanced functionality on top and won't get enough feedback to make the base dependandable. Part of the design focus was streamlining some of the advanced functionality. I don't think that focus was misguided at all. It certainly reduces the support cost considerably (read: misfiled bugs, less support tickets, easier guides etc). Increasingly, the expectation that it is ok for enterprise software to be clunky is going away and that is a good thing.

I must admit that even though I'm 0/2 when trying to install F19* on a VM with multiple drives, the F19 storage manager has improved considerably compared to F18, and with the help of Reartes Guillermo [1], I even managed to create my favorite MD RAID + LVM setup, though the steps to achieve it were, err, somewhat overly complex.

- Gilboa
* And having problems reporting meaningful BZ as the send bug report dialog simply hangs.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=969771