F14 Alpha: Laughably terrible

[destinatus]

Originally Posted by smr54

Ok, just tried again with vmplayer, and DEFINITELY chose to not use autoinstall.

Same issue, won't get past a black screen at Anaconda. <insert more snide comments about crippling text mode and breaking a once working GUI mode>

Seriously, I do wonder about priorities--don't know who gets paid and who does it for free, but rather than improve an installer that works, put the energy into hardware support for all the stuff that doesn't work.

Is this with the Alpha or the Beta (RC3)? I had this a couple of times on one of my systems with Beta RC3 (gold), but after a handful of tries, Anaconda did actually kick in here. This is on real hardware, mind, though it does sound slightly similar...

I wonder if the latest RHEL is this crippled. I'm guessing not, considering the amount of time and money Red Hat are putting into virtualisation.

[smr54]

This is with the RC3, the one that's been declared good to go.

RHEL has crippled text install--my pet peeve about it is that they've put a spin on it that reminds me of the one who thought of the name Windows Genuine Advantage

According to their docs, RH 6 has "streamlined and simplified" text install.

I only give it one or two tries, especially on what's a preliminary machine.
I only tested the i386 net install and disc 1 of the CD set. Checksums matched. For all I know the problem doesn't exist on x86_64 but I figured the i386 was more likely to be well tested. I've only tried on one machine, and don't have time--or inclination this time, as I'm in a curmudgeonly mood--to investigate if it merits a bug report.

[destinatus]

Originally Posted by smr54

This is with the RC3, the one that's been declared good to go.

RHEL has crippled text install--my pet peeve about it is that they've put a spin on it that reminds me of the one who thought of the name Windows Genuine Advantage

According to their docs, RH 6 has "streamlined and simplified" text install.

I only give it one or two tries, especially on what's a preliminary machine.
I only tested the i386 net install and disc 1 of the CD set. Checksums matched. For all I know the problem doesn't exist on x86_64 but I figured the i386 was more likely to be well tested. I've only tried on one machine, and don't have time--or inclination this time, as I'm in a curmudgeonly mood--to investigate if it merits a bug report.

Interesting. FWIW, it was the x86_64 DVD Beta RC3 that was hanging on me... bit of a poor show that the i386 media isn't working for you.

I've got a few install-media bugs I need to try and reproduce now that I've finally managed to get F14 Beta installed, which can't really be done on this system now it's actually working, so I'll give VirtualBox a shot. I'll post here if I have any luck.

[smr54]

Ah, glad I didn't download it then. Thanks for telling me. Again, I know they've been testing this in various ways, but it is aggravating. I do wonder what improvements have been made in Anaconda, aside from being able to handle newer filesystems such as ext4 and btfs.

Aside from that, all I've seen are regressions, the killing of the text install, setting up a network disappearing--though that's back in the later versions I think, though with the NM gui interface, which I find a pain to use, seemingly less support for various video cards (and VMs), setting grub to 0 timeout....

Of course, as I type, I have to laugh and say, that for all I know, there were several common machines that couldn't install and they've fixed it--I tend to doubt it though, seems they just like to tinker with something that worked reasonably well, even for newcomers, and make it worse, perhaps because it's more fun than documenting Gnome for instance, or working on support for some tricky wireless cards or printers.

[AdamW]

it really doesn't work that way. The people who work on anaconda are good at working on anaconda. They aren't hardware hackers. Most of them wouldn't know which end of a wireless network driver to start with. Specialization is really pretty standard in software development. And if you really want to know what's being changed in anaconda and why, read the changelogs and git commit messages instead of pontificating: it's open source for a reason.

http://git.fedorahosted.org/git/?p=a...ads/f14-branch is the changelog for the F14 branch of Anaconda.

We did extensive testing of F14 Beta - see https://fedoraproject.org/wiki/Test_...ta_RC3_Install - and didn't hit any of the problems you describe (except possibly for problems with VirtualBox, which are kind of known but which are mostly on the VBox side; Fedora mostly worries about issues with the Fedora virt stack rather than anyone else's, too). We did multiple installs in KVM VMs and did not have any kinds of problems as you describe.

In future, it would help if you could test this stuff before the beta is declared gold, and contribute results to -test list and the test matrices (like that page I just linked), because that's where the actual validation process happens. I try to check this forum when I can but it's definitely far below either of those in priority and I simply didn't have time to check it much during the validation process for this release.

[smr54]

A few posts ago, I did have the statement beginning with, "To be fair.." where I freely concede that it was heavily tested--as I mentioned on the testing list, I've only had time to try on one machine, so really don't know if this is a just me and a few others thing or not.

Looking through the Anaconda changes, though, I think it would just become a bikeshed argument, but that's a whole different thread.

Thanks as always for comments--you're quite right about the ideal case (testing before it goes gold and so on) but unfortunately, real life frequently gets in the way and I usually don't even start trying it till it goes beta.

[robert-e]

Adam, Scott, et al,
Firstly Adam, you have brought a lot of improvements to the Fedora project, and I commend all your efforts. My daughter's job is head of software development and she tells me that coordinating and scheduling of programmer's work is quite difficult, even with administrative control of the process. I imagine that your job is that much more difficult give that Fedora's programmers are either volunteers, or in the case of Redhad employees, you are on a peer level with them. You must be an extraordinary personality that you get the results that you have had. Your situation would be my version of a "private hell"...lol.

I would say that the description of Scott "pontificating" is a bit on the strong side. If users do not make note of their concerns (not perhaps bugs) with Fedora, then there is virtually no chance that the developers (when did we stop calling them programmers?) might know that something is problematic? I have always found that Scott's posts to be polite, and well thought out. He was of great help to me during my problems with Atheros wireless chips. He and others like him helped me during my attempts to get serious about Linux, and do keep me coming back to this forum, at a time when my use of Fedora has declined to the point that I have only one hard drive with a Fedora (12) system currently installed. I do not want to get into details now why, but it has to do with PackageKit, PulseAudio, and the general attitude of "you have to do it our way...because WE know what is good for you...read here..root login issues, LVM defaults..and such.

Now I will get out of here, ducking the flying horse apples and Texas bullets.

My best regards to both of you.

Bob

[smr54]

@Robert--firstly, many thanks for the extremely kind words.

I don't think Adam meant his remarks in a very cutting way--I think he knows (I hope he does anyway, I've said it frequently both here and on the testing list), that he has my utmost respect, and is one of the Fedora people who is on the side of the users.

I was venting a bit--I think that both Adam and Rahul, who also has my utmost respect and also hopefully knows it--sometimes feel it is a good thing to put my rants into their proper perspective, and think it's good to point out, for the sake of others reading too, that the only way things will get done is when bugs are filed. In this case, I don't feel too guilty, I think Adam missed my earlier post, where I did make an effort (well, sort of) to point out that it had been tested and there was a chance that I was unlucky.

Again, I very much appreciate your words, and it is good to know that I help some folks here, (though probably nowhere near as many as Adam helps), but in this case, I don't think he was really attacking--if he was, well, I've been married for awhile, so criticism just rolls right off me anyway.

[AdamW]

What I described as 'pontificating' was the discussion about anaconda changes (like "seems they just like to tinker with something that worked reasonably well, even for newcomers, and make it worse, perhaps because it's more fun than documenting Gnome for instance, or working on support for some tricky wireless cards or printers."); it just seemed a bit absurd to suggest that the Anaconda developers would spend their time changing stuff for no good reason. I mean, if Red Hat considered that a good way of spending developer salaries, I doubt we'd be around any more. =) No, really, changes to anaconda do happen for really good reasons, and it's not at all hard to find out what these are, hence the git link.

I did see your earlier post, Scott, I just wanted to reinforce the point; whatever bug you're hitting, we (both RH and community Fedora QA) did test this thing quite a lot and didn't hit it.

Network configuration in installation has changed to use nm-c-e, yes. The reason for this is pretty obvious: maintaining two different network configuration interfaces (well, actually, about four, but hey, we're working on it where we can...) is a silly way to spend resources, and just leads to unnecessary work and the situation where you fix a bug in one but not in the other. nm-c-e should be the canonical network configuration interface, hence we integrate it in the installer and get rid of the installer's home-grown network configuration interface.

The text installer was simplified in Fedora 13; the main reasoning is that it actually requires a lot of duplication of work to maintain the text installation UI (it shares very little code with the graphical one) and that was tying up a bunch of resources for an install method which is pretty rarely used. Streamlining the text install interface allows us to keep it around for the cases where it's necessary but not use up a whole lot of resources on it. Ideally, every machine should be capable of using the graphical installer; cases where this doesn't work usually aren't actually Anaconda bugs, but bugs in X, and it definitely helps to report them. It's always a good idea to try 'basic graphics mode' if you have trouble with the default.