Fedora 18 TC1 images are out!

[Dutchy]

Originally Posted by Demz3

im sure someone said on one of the lists that the old Customization during install will not be returning in this new Anaconda.

It better looks very, very, extremely nice then!

[AdamW]

so, it's important to understand one of the driving forces behind the anaconda UI re-design: the existing UI is over-complex. not from the point of view that it contains features that are entirely useless, but rather, it has more functionality than the anaconda team can maintain properly. Of course it sucks to lose a feature you like, but the people who have to maintain the code feel like it's so complex they can't actually do that properly. so as well as modernizing the design of the installer, it's a conscious goal to simplify it - not because the developers think users are idiots who don't 'understand', no-one thinks anyone's cutting their finger on the package customization screen, purely because it's just too much stuff to take care of. Every release, lately, we've wound up running across bits of code in the installer that literally no-one actually understands. That's not a very sustainable situation. Whenever we've had to make significant changes to anaconda in recent releases - for the grub2 migration, for the GPT experiment, for UEFI support, for noloader - the devs have basically had to resort to an approach of 'write the new code, throw it in there, then see what breaks and firefight as required'. the oldUI codebase is so complex that they couldn't really properly _plan_ the major changes - they were never entirely sure, ahead of time, which of the zillion other bits of functionality in anaconda were going to break when they poked the bootloader code or the init stuff or whatever. so yeah: it sucks to lose some functions, but there's a sensible reason for it, and it's not 'we think you're too dumb to handle it'. There will be genuine benefits from simplification of the UI - at least we hope so: once newUI gets stabilized, anaconda should be generally more reliable in future releases, and it should be possible to do major changes with less unexpected and unpredictable breakage and crazy firefighting.

edit - the 'crippled text install' that smr54 mentions is a good example here, actually. It wasn't 'this next step towards making it nice for the masses' as you suggested - there's not much point in dumbing down a *text* mode for the masses, after all. Nope, it was just what I wrote above: maintenance headache. The full-fat text installer was neat, but for the maintainers, it meant they had two implementations of every damn screen in the installer to maintain - one in GTK+, one in curses (or something, I forget what text UI library it used). It's a lot of work. Doing that work swallows resources that could otherwise be used to improve anaconda in other ways. The team got to the point where they just didn't think it was a good idea to devote substantial resources to maintaining a mode that was only used by a few people, and usually either for kickstart deployments or for very minimal installs (a system that can't run the graphical installer is usually a system that's going to have a very minimal install on it). So it kinda made sense to simplify the text installer, not because they actually thought the simplified interface was a *better* interface exactly, but because it was sufficient to the needs of most of the few people who use the text interface while requiring far less work to maintain. It _is_ a tradeoff, we recognize that, but the tradeoffs have to be made _somewhere_.

One thing to keep in mind is the kickstart function of anaconda - https://fedoraproject.org/wiki/Anaconda/Kickstart . To an extent I think it's a bit underused. Where there are things newUI doesn't allow interactively which oldUI did, it's often the case that you can still do it via a kickstart: again, package customization is a good example. You can't customize individual package selection interactively in the UI any more, but you *can* still do it with a kickstart. Just think of it as an anaconda config file.

[AdamW]

some notes on various specific issues:

TC1 is utterly DOA. Won't work, can't work. Fuhgeddaboutit.

TC2 cannot start graphical anaconda at all, only the text mode. Use TC3.

TC3 can get into graphical anaconda and do an install of KDE, LXDE or Xfce. GNOME won't work because of dependency issues, at least at present, this will change when we push updates that fix the dep issues through the freeze.

Live images are missing because the idea was to use a new tool called livemedia-creator to build them for F18, instead of the old livecd-creator, but honestly it's not entirely ready yet. There's some, er, mild dissent between the dev and releng teams there so I won't say too much in case I misrepresent anyone, but suffice to say the current state of lmc really doesn't fit in too well with the established procedures rel-eng has for spinning live images. Most likely we'll go back to spinning the lives with livecd-creator _at least_ for Alpha. That may happen as soon as TC4. We do know that livecd-creator basically still works, so we aren't entirely screwed.

TC3 will not boot when written to a USB stick (in any way) - it may be possible to work around this, but we haven't bothered to figure out a workaround, the key thing is to fix the bug.

TC3 will have issues booting in most common KVM configurations, because there are showstopper bugs with both the cirrus and qxl drivers for the two most commonly used virtual graphics adapters in KVMs. qxl is utterly screwed; the only way to get into X with the 'qxl' card is to use the vesa mode. a 'cirrus' card will boot if you pass 'nomodeset' as a kernel parameter. Or you can simply use the 'vga' card in KVM. The bugs here are https://bugzilla.redhat.com/show_bug.cgi?id=848930 and https://bugzilla.redhat.com/show_bug.cgi?id=844463 . The cirrus one should be fixed in TC4, qxl we don't have a fix right now.

Custom partitioning in general is pretty fragile, the code is very new and probably riddled with bugs. Do report any you find, but don't nominate them as Alpha blockers, custom partitioning doesn't block Alpha. Do check if the bug you're filing has already been reported, I think the one about 500MB sizes is already filed for instance, but I don't have a comprehensive list handy.

Note that the 'review and modify partition layout' checkbox in newUI doesn't do the same as in oldUI. In oldUI, it let you pick one of the automatic partitioning methods but check the results: anaconda would figure out the automatic layout, then put you into 'custom partitioning' mode where you could adjust the result if you wanted. In newUI, it really just puts you straight into custom partitioning mode - it doesn't come up with a working automatic layout for you to review and modify, it just goes _straight_ to custom partitioning, for you to create your own layout. It doesn't give you an expected-to-work layout to modify, if you hit that checkbox, you _will_ have to create the whole layout manually. We recognize this is bad UI as it goes against user expectations, it'll be adjusted somehow.

There's a major issue with user accounts. newUI doesn't currently make the root account accessible, and firstboot is broken. So after install you won't actually be able to login without some manual faffing. Easiest thing to do is probably to boot to single-user mode to set a root password, then boot to runlevel 3 and create a user account with adduser, then finally you can boot as normal login with the regular user account. Obviously this isn't how it's intended to work =) we'll try and get firstboot fixed up for TC4. There's still a problem with non-graphical installs, where there's no firstboot to create a regular user account; this wasn't properly considered when the newUI design was being done. We have a bug open on it now and it'll be addressed somehow before Alpha release.

The DVD doesn't actually use the packages from the DVD, it uses online repositories. AFAIK there's no workaround for this. It should be fixed for TC4.

Entering the network configuration screen is death - anaconda _will_ crash later if you do so. So if your network doesn't work out of the box, you're in trouble. Sorry...we're working on it.

grub doesn't _need_ a png file, exactly - the problem is that we accidentally shipped it with a configuration that mentions a png file, by the wrong name. It looks for fireworks.png, the file is actually called background.png. D'oh. By default you'll get a themed graphical grub (once we fix that bug...) for F18, but you can certainly change it to a boring non-themed config if you like. The error isn't fatal, when you see it just press enter and boot continues, it doesn't stop you booting.

smr54 said something about the default package set - honestly we haven't worried about that at all yet, and comps is being revised quite heavily as part of the https://fedoraproject.org/wiki/Featu...kPackageGroups feature. I wouldn't be at all surprised if some bug in there somewhere results in a bigger default install, but it's not an Evil Conspiracy, just a cock-up. I'll take a quick look at that if I find time. It may simply be the effect of the DVD install using the remote repos not the packages on the DVD - a 'default' install from online repos has always been bigger than a 'default' install using only the packages on the DVD, because of the stuff that's left off the DVD to make it fit.

demz3: yeah, that (only being able to pick one DE) is a...contentious design decision. It has indeed been debated on the test@ list at least once already. I don't know if there's any plan to change it.

added by edit: upgrade functionality is entirely missing from newUI at present. You cannot do an anaconda-based upgrade from F17. Don't try, it will only result in breakage. If you want to upgrade from F17, for the present, use yum. It more or less works, but you'll need to do 'setenforce Permissive' first, or do 'yum reinstall polkit' after the upgrade is done and you reboot, or else policykit will be broken - https://bugzilla.redhat.com/show_bug.cgi?id=841451 .

added by edit: live installation is currently also entirely broken. This doesn't matter much as lives haven't been built for the first three TCs, but if you build your own live image or something, be aware you will not be able to install from it, it's just not going to work. This kinda ought to be fixed prior to Alpha release, so I'm hoping the anaconda team get their skates on =)

Hope that covers a few points =) As always, if you're following along with the TC/RC process, it's always a good idea to follow the validation matrices where validation test results are filed - principally https://fedoraproject.org/wiki/Test_...tallation_Test - and the blocker bug list, which has now moved to http://qa.fedoraproject.org/blockerbugs/current . Most of the above issues are in that blocker bug list. And please remember, TCs and RCs are *test images* for us to do validation on. The whole point of their existence is basically to find the really big problems ahead of the official pre-releases. TCs and RCs are not official releases or even official pre-releases, are not guaranteed to work in any way and may well set your house on fire. The way you do a release of software is to start by just building it and seeing what's busted and what needs fixing: RCs and especially TCs *are* those 'let's see what's busted' builds.

tl;dr summary: TC1 and TC2 are utterly busted, TC3 can be made to work but is very fragile and needs manual intervention. Honestly, if you just want a Fedora 18 system to play with, you're probably going to have more luck yum updating from F17 right now. If you insist on getting TC3 working, refer to the blocker list for help.

[kkshethin]

Downloaded Fedora-18-Alpha-TC2-i386-netinst.iso and tried to install in virtualbox. First try failed.
Then following suggestions by marco765, able to install. Text login, Tried to install group Gnome Desktop Environment & X Window System.
Many dependency problem. --skip-broken, Have to downgrade some, try, retry. Finally text login and then startx sucessfully.
Following not working,
A lock screen which do not reveal login screen, first time it showed then disappeared.
User settings, not unlocking
mounting of guest additions.
user account settings shows username one time and next time does not show username as if user disappeared.
Further i did not like new nautilus at all. No status-bar. Computer bookmark showing file system instead.
I have apprehension (May be premature) that Fedora17 will be my last dear distro.

[DBelton]

So, it appears that I will have to do a "windows" type install now.

For example, I no longer use Gnome 3 shell, but since there is no customization and only one choice of DE, I will be forced into installing it, and then going back later and removing it after installing the DE I wish to use? Or will there be a way for me to just install the DE I wish from the DVD and not install Gnome? Even if I can't install the DE I wish from the DVD, is there a way for me to not install Gnome, but still do a graphical install?

Sorry, but Gnome shell is out on my system here. I gave it over a year to mature enough so that it's usable for me, but it just didn't happen, so it doesn't even get installed on my machines here anymore. I sure hope that anaconda isn't going to try and force it upon me, either. I'll drop it and go elsewhere if it even tries.

[Dan]

Originally Posted by AdamW

some notes on various specific issues:

TC1 is utterly DOA. Won't work, can't work. Fuhgeddaboutit.

TC2 cannot start graphical anaconda at all, only the text mode. Use TC3.

TC3 can get into graphical anaconda and do an install of KDE, LXDE or Xfce. GNOME won't work because of dependency issues, at least at present, this will change when we push updates that fix the dep issues through the freeze.

Live images are missing because the idea was to use a new tool called livemedia-creator to build them for F18, instead of the old livecd-creator, but honestly it's not entirely ready yet. There's some, er, mild dissent between the dev and releng teams there so I won't say too much in case I misrepresent anyone, but suffice to say the current state of lmc really doesn't fit in too well with the established procedures rel-eng has for spinning live images. Most likely we'll go back to spinning the lives with livecd-creator _at least_ for Alpha. That may happen as soon as TC4. We do know that livecd-creator basically still works, so we aren't entirely screwed.

TC3 will not boot when written to a USB stick (in any way) - it may be possible to work around this, but we haven't bothered to figure out a workaround, the key thing is to fix the bug.

TC3 will have issues booting in most common KVM configurations, because there are showstopper bugs with both the cirrus and qxl drivers for the two most commonly used virtual graphics adapters in KVMs. qxl is utterly screwed; the only way to get into X with the 'qxl' card is to use the vesa mode. a 'cirrus' card will boot if you pass 'nomodeset' as a kernel parameter. Or you can simply use the 'vga' card in KVM. The bugs here are https://bugzilla.redhat.com/show_bug.cgi?id=848930 and https://bugzilla.redhat.com/show_bug.cgi?id=844463 . The cirrus one should be fixed in TC4, qxl we don't have a fix right now.

Custom partitioning in general is pretty fragile, the code is very new and probably riddled with bugs. Do report any you find, but don't nominate them as Alpha blockers, custom partitioning doesn't block Alpha. Do check if the bug you're filing has already been reported, I think the one about 500MB sizes is already filed for instance, but I don't have a comprehensive list handy.

Note that the 'review and modify partition layout' checkbox in newUI doesn't do the same as in oldUI. In oldUI, it let you pick one of the automatic partitioning methods but check the results: anaconda would figure out the automatic layout, then put you into 'custom partitioning' mode where you could adjust the result if you wanted. In newUI, it really just puts you straight into custom partitioning mode - it doesn't come up with a working automatic layout for you to review and modify, it just goes _straight_ to custom partitioning, for you to create your own layout. It doesn't give you an expected-to-work layout to modify, if you hit that checkbox, you _will_ have to create the whole layout manually. We recognize this is bad UI as it goes against user expectations, it'll be adjusted somehow.

There's a major issue with user accounts. newUI doesn't currently make the root account accessible, and firstboot is broken. So after install you won't actually be able to login without some manual faffing. Easiest thing to do is probably to boot to single-user mode to set a root password, then boot to runlevel 3 and create a user account with adduser, then finally you can boot as normal login with the regular user account. Obviously this isn't how it's intended to work =) we'll try and get firstboot fixed up for TC4. There's still a problem with non-graphical installs, where there's no firstboot to create a regular user account; this wasn't properly considered when the newUI design was being done. We have a bug open on it now and it'll be addressed somehow before Alpha release.

The DVD doesn't actually use the packages from the DVD, it uses online repositories. AFAIK there's no workaround for this. It should be fixed for TC4.

Entering the network configuration screen is death - anaconda _will_ crash later if you do so. So if your network doesn't work out of the box, you're in trouble. Sorry...we're working on it.

grub doesn't _need_ a png file, exactly - the problem is that we accidentally shipped it with a configuration that mentions a png file, by the wrong name. It looks for fireworks.png, the file is actually called background.png. D'oh. By default you'll get a themed graphical grub (once we fix that bug...) for F18, but you can certainly change it to a boring non-themed config if you like. The error isn't fatal, when you see it just press enter and boot continues, it doesn't stop you booting.

smr54 said something about the default package set - honestly we haven't worried about that at all yet, and comps is being revised quite heavily as part of the https://fedoraproject.org/wiki/Featu...kPackageGroups feature. I wouldn't be at all surprised if some bug in there somewhere results in a bigger default install, but it's not an Evil Conspiracy, just a cock-up. I'll take a quick look at that if I find time. It may simply be the effect of the DVD install using the remote repos not the packages on the DVD - a 'default' install from online repos has always been bigger than a 'default' install using only the packages on the DVD, because of the stuff that's left off the DVD to make it fit.

demz3: yeah, that (only being able to pick one DE) is a...contentious design decision. It has indeed been debated on the test@ list at least once already. I don't know if there's any plan to change it.

added by edit: upgrade functionality is entirely missing from newUI at present. You cannot do an anaconda-based upgrade from F17. Don't try, it will only result in breakage. If you want to upgrade from F17, for the present, use yum. It more or less works, but you'll need to do 'setenforce Permissive' first, or do 'yum reinstall polkit' after the upgrade is done and you reboot, or else policykit will be broken - https://bugzilla.redhat.com/show_bug.cgi?id=841451 .

added by edit: live installation is currently also entirely broken. This doesn't matter much as lives haven't been built for the first three TCs, but if you build your own live image or something, be aware you will not be able to install from it, it's just not going to work. This kinda ought to be fixed prior to Alpha release, so I'm hoping the anaconda team get their skates on =)

Hope that covers a few points =) As always, if you're following along with the TC/RC process, it's always a good idea to follow the validation matrices where validation test results are filed - principally https://fedoraproject.org/wiki/Test_...tallation_Test - and the blocker bug list, which has now moved to http://qa.fedoraproject.org/blockerbugs/current . Most of the above issues are in that blocker bug list. And please remember, TCs and RCs are *test images* for us to do validation on. The whole point of their existence is basically to find the really big problems ahead of the official pre-releases. TCs and RCs are not official releases or even official pre-releases, are not guaranteed to work in any way and may well set your house on fire. The way you do a release of software is to start by just building it and seeing what's busted and what needs fixing: RCs and especially TCs *are* those 'let's see what's busted' builds.

tl;dr summary: TC1 and TC2 are utterly busted, TC3 can be made to work but is very fragile and needs manual intervention. Honestly, if you just want a Fedora 18 system to play with, you're probably going to have more luck yum updating from F17 right now. If you insist on getting TC3 working, refer to the blocker list for help.

Ahhh! Gotcha. Well awright! Adam ... thank you for a refreshing breath of solid info. Seriously, this kind of scuttlebutt squashing helps a lot more than it hurts IMHO. Although ... it also gives a metric ton of ammunition to the conspiracy theory crowd ... me included thence. <....>

So, with that in mind, my semi-psychotic take away from all that is:

• Common (read: any project) growth symptoms = abundance of ambition>mission creep>over-reach, which then eventually leads to changes>breakage>attrition>downsizing>product shrink>re-build/re-stabilize, then the cycle starts all over again. Sometimes in the same project ... sometimes in the next generation of evolution if the original doesn't survive the adaptation process, but usually accompanied with personnel churn.
• Due to the above trend, you've got a buggy/dysfunctional code minefield at this point, which means ... simplify to troubleshoot = choice/complication removal. In short, the alphas and probably the betas will be any color you like ... as long as it's black. Even shorter, "We'll fix it first, decorate it later (maybe)."
• The Gnome/Adwaita contingent/Borg are still very much alive and well.

  " ... You will be assimilated. Resistance is futile ... <....> "

  ( <....> )

Please feel free to skewer any of the above wild-arsed speculation with the clean cold steel of reality. <....>

[jpollard]

too bad the other developers don't have the same thought.

Making things too complicated is exactly what is wrong with gnome and systemd.

They try to do too many things in one application, which means they end up doing none of them well.

[nonamedotc]

Originally Posted by DBelton

So, it appears that I will have to do a "windows" type install now.

For example, I no longer use Gnome 3 shell, but since there is no customization and only one choice of DE, I will be forced into installing it, and then going back later and removing it after installing the DE I wish to use?

Or will there be a way for me to just install the DE I wish from the DVD and not install Gnome? Even if I can't install the DE I wish from the DVD, is there a way for me to not install Gnome, but still do a graphical install?

Sorry, but Gnome shell is out on my system here. I gave it over a year to mature enough so that it's usable for me, but it just didn't happen, so it doesn't even get installed on my machines here anymore. I sure hope that anaconda isn't going to try and force it upon me, either. I'll drop it and go elsewhere if it even tries.

Yes. It is possible to install the DE of your choice without installing GNOME. The key is - you can install ONE DE of your choice. Dbelton, in your case, you would be able to install XFCE during install. Just not anything else along with it. In fact, in my case, I was able to get F18 installed on Virtualbox with XFCE.

[DBelton]

Ahhh.. Thanks for the explanation, nonamedotc

Well, it's still a problem, since I pretty much use Xfce for most of my stuff, but have KDE installed for a few things I need to do for work. I also have some Gnome applications that I use, so need just a few parts of Gnome as well.

I usually install them from the installer since it's a pain in the butt to go back and install them later on since a group install later on pulls in a lot more packages than it does from the install DVD.

I use the DVD rather than the LiveCD spins so I can get the customization I want, but if I can't get that any more, may as well go over to Arch where I can at least get the custom system I need.

[nonamedotc]

Originally Posted by DBelton

Ahhh.. Thanks for the explanation, nonamedotc

Well, it's still a problem, since I pretty much use Xfce for most of my stuff, but have KDE installed for a few things I need to do for work. I also have some Gnome applications that I use, so need just a few parts of Gnome as well.

I usually install them from the installer since it's a pain in the butt to go back and install them later on since a group install later on pulls in a lot more packages than it does from the install DVD.

I use the DVD rather than the LiveCD spins so I can get the customization I want, but if I can't get that any more, may as well go over to Arch where I can at least get the custom system I need.

That's what I do too. Rhythmbox and evolution come with a Live CD install

But, as you say, that's no longer going to be the case. I suspect that a minimal installation would be in order!

P.S. By the way, I am sure you are aware that Arch took out that Arch Installation Framework and put, in its place, a set of installation scripts right? I have the iso downloaded but not tried that yet!

[DBelton]

eeew... Rhythmbox and Evolution are 2 packages that I ALWAYS uncheck from the install since they are pure garbage.

I haven't even looked at Arch in quite awhile now, since I have been pretty happy with Fedora. Fedora has in the past given me the flexibility that I needed and has been a good fairly stable distro. If that changes, (as it appears to be doing) then I am not against looking elsewhere, but I hope I don't need to.

I just hope that anaconda will continue to give me the customization I need, which is the entire reason I download the DVD instead of the LiveCD images. If I wanted to be limited to just one DE, then I would be downloading the LiveCD's.

[hadrons123]

Am I the only one who thinks that all the explanation given by Adam is right?

[Dan]

Uhm ... no.

[AdamW]

Dan: that's broadly correct, but we're talking about a longer timespan than 'Alpha vs. Final' here. I don't want to mislead you into thinking that stuff like the package customization screen is going to come back in Final, that's not what I meant. The simplification is for the long term, to give the anaconda team a manageable code base they can make really solid and usable.

The cycle you describe is broadly the pattern anaconda has fit into over time though, yeah, and I've seen it happen to other projects. In a way it's one of the few drawbacks of the 'F/OSS way' - when you're trying to demonstrate your openness to community contributions it's very difficult to say 'no' to someone who offers you a patch that implements some cool new feature, but the people who write and contribute the new feature code aren't always volunteering to stick around and help you maintain it over the long term. So you can wind up with a very small group of core maintainers trying to maintain code that was drive-by-dumped by a much larger group of people: for a few years they're like 'hey, this is awesome, we're getting all these features for free!', then one day they wake up and realize they're sitting on a mountain of code that's just too big for the three of them (or however many it is) to maintain. I don't think it's often a cycle, though, in my experience once a project goes through it one time, they usually get much stricter about keeping the codebase manageable in future.

dbelton: It's different for everyone, I guess, but I stopped using package customization years ago, before I switched to Fedora, even - I just decided it wasn't really giving me much benefit. I find it works out fine for me just to pick 'minimal' and add on what I need with yum for servers, or to pick the desktop I want and add on anything else I need with yum for desktops. I probably have quite a few packages installed that I just never use, but it really doesn't bother me much. If they're really big I'll get around to yum removing them at some point to save on update bandwidth, but eh. It's not like they're getting in my way, or something. They just sit there not being used. To me post-install package set tweaking is just as good as doing it during install, really.

[DBelton]

Well, another bad thing here is that you are pretty much "stuck" with what someone else decides you should install.

For example, When I installed F17, I installed Gnome, BUT I went into the customize option and removed Evolution, Tracker, and telepathy (and others as well) because I did not want that crap on my machine, and you can't easily remove it once it is installed without removing just about all of Gnome. It's not a case here of install it but don't use it. I don't want it installed at all.

The customize option is very important to me, and without it, I am not going to even bother with install Fedora. I want MY system to have installed on it what I want. Not what someone else decides they want to install along with the desktop I choose.

So, in F18, install from the full DVD, how do I install Gnome, but not install Evolution, Tracker, and Telepathy? Can I do that, or will I have to go with another distro to do it?