Description of problem:
When installing Fedora Workstation from a netinstall, the default selected environment is "Web Server". The only other environment that can be selected is "minimal". The default should of course be "Fedora Workstation".
Version-Release number of selected component (if applicable):
Fedora 21 Workstation Alpha TC4
Steps to Reproduce:
1. Point a network install (I used virt-manager) at http://dl.fedoraproject.org/pub/alt/stage/21-Alpha-TC4/Workstation/x86_64/os/
2. Proceed to the main hub of anaconda
Proposed as a Blocker for 21-alpha by Fedora user sgallagh using the blocker tracking app because:
"When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
Discussed at 2014-08-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-08-27/f21-blocker-review.2014-08-27-15.59.log.txt . This is clearly technically a blocker as the criteria are written, but it is equally obvious that the criterion in question is written to the Fedora.last (pre-F21) world and we have not actually considered whether it makes any sense in the Fedora.next world.
The current Workstation product design envisages only a single official/supported media type - the live images. Network install images were explicitly not to be official/offered:
"We will produce a live .iso image. The primary target for this image will be USB sticks, but the ability to burn the image to a DVD should be preserved (since we are still getting regular requests for such media). There is no pressing reason to restrict the image to the current 1GB size target. Persistence is not an important feature of the live media, whose primary focus should be to install the system."
With that design, it would make sense to revise the criteria to no longer require network installation of Workstation (at least, and possibly also KDE) to work, and reject this bug as a blocker. However, since that document was written, the Workstation WG has come around to some degree to the importance of network installation in certain contexts, and the text may no longer fully represent their plan for F21.
We conclude therefore that the status of network installation for the Workstation product is not clear at this point in time, and therefore we cannot safely reword the criterion (release criteria should always *reflect* the intents of the project, not *define* them). Evaluation of the blocker status of this bug is delayed until there is a clear consensus as to the status of the Workstation network install image, and the criterion can be appropriately revised to reflect that.
We will ask the Workstation group (and other interested stakeholders) to come to a clear decision here.
This should now work with the comps from today's compose and latest spin-kickstarts. Looks like it unfortunately missed the TC5 that dgilmore is doing right now though.
"error setting up base repo"
changed source to: http://dl.fedoraproject.org/pub/fedora/linux/development/21/x86_64/os/ chose Workstation from list;
Installation aborted with error:
"error populating transaction after 10 retries: Insufficient space in download directory /tmp/yum.cache/anaconda/headers"
(In reply to satellit from comment #5)
> In VirtualBox
> "error setting up base repo"
> changed source to:
> chose Workstation from list;
> Installation aborted with error:
> "error populating transaction after 10 retries: Insufficient space in
> download directory /tmp/yum.cache/anaconda/headers"
boosted memory in VM to 1408 and chose sugar-desktop from software list and it installs.
(In reply to satellit from comment #6)
> boosted memory in VM to 1408 and chose sugar-desktop from software list and
> it installs.
Well, this is not Workstation, it's the Sugar spin ...
To test Workstation netinstall, use http://dl.fedoraproject.org/pub/alt/stage/21-Alpha-TC5/Workstation/x86_64/os/ as the source URL.
(In reply to Kalev Lember from comment #7)
> (In reply to satellit from comment #6)
> > boosted memory in VM to 1408 and chose sugar-desktop from software list and
> > it installs.
> Well, this is not Workstation, it's the Sugar spin ...
> To test Workstation netinstall, use
> as the source URL.
Tested and works in install to bare metal from CD
"According to releng, the netinstall currently tries to use a repo from
an URL that doesn't exist yet since Alpha isn't released. After Alpha
gets released, it should start working properly and shouldn't require
manual URL changes, AFAIK." (in e-mail from Kalev Lember)
well, we can't just let it slide until release. it needs to be fixed somehow for testing.
I suspect that just the Fedora repo is enabled and it will never work right without manual intervention. we may need to add some extra repos to fedora-repos and tweak them in pungi/lorax to enable the right one for the product.
Discussed in 2014-09-03 Blocker Review Meeting. Voted an Accepted Blocker as it violates the Alpha Criteria: "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set."
So we kind of have a back story here.
TC/RC and pre-release (Alpha, Beta) milestone network install images have never used the corresponding install trees as their default install repos. They have always simply used the full 'generic' mirror tree. That is, the default repo would be from (mirror)/pub/fedora/linux/development/21/ , not from https://dl.fedoraproject.org/pub/alt/stage/(Milestone)-(compose) .
Whether this was 'entirely as intended' or not isn't necessarily clear, but it's kind of moot, because it becomes more important for F21.
The pub/fedora/linux/development/21/ is generic, it's not Product-ized, it doesn't have separate per-Product trees with comps customization/filtering/whatever. So if netinsts use that as their default repo, they will (we expect) be generic: they'll offer all available package groups. Given that we want Product-ized network install images for F21, it becomes more clear that they ought to be using default repos that come from a Product-ized tree.
I'm not clear yet on exactly what level/component this needs fixing in; it may involve one or more of at least anaconda and mirrormanager (and maybe others I'm not aware of). But I believe the requirement should be that - without manual tweaking at image generation time, or anything like that - a TC/RC netinst build will use by default a repository from a Product-ized install tree, and hence offer only the appropriate package groups for that Product.
I'm gonna set this back to ASSIGNED for now as it seems clear from dgilmore that just fixing bugs in kickstart and comps is not going to be sufficient to fix this.
Well, even when installing from the generic tree, as long as the user chooses "Fedora Server" or "Fedora Workstation" from the installable environments, they *will* get a Product-ized installation.
(Under the hood, this really means that they get the set of packages that defines the Product as well as the equivalent Product-specific default configuration).
For F21, I think it may make sense for the netinstall images to all be the same and point to the converged tree (and therefore not publish/mirror the per-Product install trees we generate to create the install media images).
This would mean postponing the proposals for different default filesystems based on a particular Product, but I think that may be a small price to pay in order to gain ourselves six months to work out the mirroring needs.
"Well, even when installing from the generic tree, as long as the user chooses "Fedora Server" or "Fedora Workstation" from the installable environments, they *will* get a Product-ized installation."
Yes, that's true, but the issue is the installer environment itself. Workstation at least seems to strongly want their network installer to only offer the Workstation environment in its default configuration, they do not want it to offer all the other environments. This bug is about that.
We could talk about the 'generic network install' thing again, I guess. Maybe Workstation wouldn't mind having a 'generic network install' image that behaves in this way, as opposed to a 'Workstation network install' image. releng IIRC keeps saying we can't do generic network install images, but I'm still not entirely sure why, especially if at present we're making them by accident...could you give us the run-down on that again, dgilmore?
(In reply to Adam Williamson (Red Hat) from comment #14)
> We could talk about the 'generic network install' thing again, I guess.
> Maybe Workstation wouldn't mind having a 'generic network install' image
> that behaves in this way, as opposed to a 'Workstation network install'
Especially as network install aims on advanced users, it could pass.
So we discussed this between anaconda, releng, Server/Workstation WGs, project management (jreznik) and QA today. The consensus that emerged, as I understand it (corrections welcome!) is basically this:
We will use Product-ized install trees and network install images.
To unpack, that means:
* anaconda will not try to 'genericize' the product name when requesting repositories, it will query MirrorManager for a product-ized release name - that is, anaconda will say "hey, MirrorManger, I want repositories for Fedora Workstation 21 Alpha TC6", or "Fedora Workstation 21 Alpha", or "Fedora Workstation 21". This involves reverting the "fix: for https://bugzilla.redhat.com/show_bug.cgi?id=1128474
* releng will produce Product-ized install trees for the installable products at all compose points. For TCs and RCs, these trees will live in staging: https://dl.fedoraproject.org/pub/alt/stage/21_Alpha_TC6/Server/ and https://dl.fedoraproject.org/pub/alt/stage/21_Alpha_TC6/Workstation/ , for instance. This already happens.
* when an Alpha or Beta release is declared Go, releng will place the signed-off Product-ized trees into the fedora/linux/releases/test/(release)-(milestone) directory on the official master mirror
* when a Final release is declared Go, releng will place the signed-off Product-ized trees into the fedora/linux/releases/(release) directory on the official master mirror
* MirrorManager will do the necessary translations. We can consider three 'modes' for MirrorManager:
1. It is asked for the main repository for a Product for a pre-release milestone that has not yet been released: this is basically Alpha TC3, Beta RC2 or whatever, *before that milestone is released*
Result: MM will point to the Product-ized tree for that particular compose on the staging server
2. It is asked for the main repository for a Product for a pre-release milestone that has been released: this is Alpha or Beta after they have been released
Result: MM will point to the appropriate Product-ized tree under fedora/linux/releases/test/(release)-(milestone) on the main mirrors
3. It is asked for the main repository for a Product for a release that has been shipped
Result: MM will point to the appropriate Product-ized tree under fedora/linux/releases/(release)
I had some thoughts about refining the proposed setup for the TC/RC phase.
I propose we have a /current dir under https://dl.fedoraproject.org/pub/alt/stage/ , which is a symlink pointing to the most recent TC/RC build.
Then we wouldn't bother constantly updating MM with new pointers for new TCs / RCs. For a given milestone, it'd only ever point to stage/current , releases/test/(releasever)-(milestone) , or releases/(release) .
Say you ask for "Fedora 21 Beta TC2". If Beta is still in TC/RC phase - there's no final Beta release - MM would be pointing to stage/current. If TC2 was the most recent compose, current/ would be a symlink to TC2, and you'd get a tree that matches your image; if TC2 was now old stuff current would be a symlink to TC4 or RC1 or whatever and you wouldn't get a matching tree (but that's really no big deal, we don't expect to be able to test old TCs/RCs with matching trees without manual intervention).
If Beta had since been signed off, MM would point to releases/test/21-Beta . Again, doesn't match the image you used, but isn't really bad behaviour.
I think that'd reduce the burden rather a bit? In fact, if we simplify to that extent, we don't really have to worry about actual compose numbers, we only have to worry about release and milestone, and update the MM redirects occasionally and the current/ symlink regularly.
bcl notes in https://bugzilla.redhat.com/show_bug.cgi?id=1128474#c18:
'This means that when making a compose the composer has to be sure they include a package installing a repo to /etc/yum.repos.d/ that has an id matching the lower-case version of the product name (eg. fedora-server or fedora-workstation). Without this the closest mirror option will not work because anaconda doesn't know the name of the repo to use.'
i.e. we either need fedora-repos to grow fedora-workstation.repo , fedora-server.repo and fedora-cloud.repo , or we need product-ized sub-packages of fedora-repos . These should point to an appropriate MirrorManager URL that can be directed to the appropriate mirror location depending on the phase of the release cycle.
Now I look at how these bits plug together, it looks like it'd be difficult to get too clever with the versioning. The current system expects the MM URL for a given release never to change; I think it'd be good to keep that, so what mirror you get for a given release (not even a given milestone) depends solely on the point in the release cycle. If you ask for "Fedora 21" while we're in a TC/RC cycle you get the repos for the current TC/RC from stage/, if you ask for "Fedora 21" mirrors while we're still in pre-release but between TC/RC cycles you get the last milestone (Alpha or Beta) from releases/test/, and if you ask post-release you get the release repo, of course. That's probably the easiest way to go. The only 'regression' compared to current state is maybe you want the frozen Beta tree when you install Beta netinst right after Final TC1 comes out, not Final TC1, but meh, it's a pre-release, you'd best be flexible.
fedora-repos-21-0.6 has been submitted as an update for Fedora 21.
I believe I spotted another necessary change here, and I have a patch in with anaconda for review:
anaconda takes the Version from the .buildstamp file inserted into the image by releng to figure out $releasever for the stock repos (I believe). It splits the string with - as the separator, the intent being that for a Version like "20-Beta-TC5" $releasever will be "20". Unfortunately, since Alpha TC6, the Version string is "20_Alpha_TC6" and it doesn't split right. The patch fixes that.
Without the patch, the MirrorManager URLs anaconda tries will be something like:
when what we want is:
there was initially some discussion about whether we actually *want* anaconda to use a sub-versioned $releasever like that in order to figure out what frozen tree it should be pointed at for pre-release builds, but after some discussion I think we agree that it should always use the bare release version as $releasever and it should be MirrorManager's job to redirect it to a different location depending on the current point in that release's life cycle (as I outlined in c#18).
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fedora-repos-21-0.6'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
fedora-repos-21-0.6 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
This failed QA for Alpha TC7 - we did the wrong thing in trying to include the repo files in anaconda's runtime environment. We added them to comps @anaconda-tools , but that's for stuff anaconda needs available as packages to potentially install into the installed system, not things that have to be in anaconda's runtime environment.
So Alpha TC7 images don't have the product-ized repos in anaconda's environment. I'll send a patch to pull fedora-repos-anaconda into the anaconda runtime via lorax (adding it as an anaconda package dep would cause it to show up in installed systems, which we don't really want).
Mo' products, mo' problems.
So we spent this morning poking through anaconda repo code, and it gets quite complicated, but it boils down to this:
If both fedora.repo and fedora-(product).repo are present on an image (and enabled), both will be used by anaconda.
This would effectively make the product network installs act as generic network installs, which is not what we want.
anaconda could possibly do things to change this, but they don't believe that would be correct. Their position is that installer images which want to use variant repos must include the repos they want to use, and *only* those repos.
This means the Product installer images would need to include fedora-(product).repo and *not* include fedora.repo .
This gives us a problem. fedora.repo is part of fedora-repos. fedora-release requires fedora-repos(21). You can't really construct a Fedora environment without it including fedora.repo .
Now, obviously we can change that, but it gets tricky. There's also a question to answer: do we want Product-installed systems to have access to the full range of packages (i.e. fedora.repo installed) out of the box or not?
Either way we answer that question, I can see a few minefields in ensuring the correct behaviour in all cases, we'll probably have to have some virtual Provides: and some fairly careful logic to cover all Product and non-Product cases.
An alternative I suggested was to just have the Products include both fedora.repo and fedora-(product).repo in all cases, and have lorax conditionally strip fedora.repo if product.variant matches a Product, but bcl didn't seem to like that.
So...discuss among yourselves? I'm not sure what the best approach is.
(I guess I could also note that I had a blue-sky idea of adding some kind of comps field which denotes whether a group is association with a Product, and have Product installers only show groups that are associated with that Product in comps, which would avoid the need for all this product-specific installer tree malarkey in the first place. But I don't know if that's viable.)
Excellent time for IRC to go down!
So I found a way to play about with this. You can ninja /etc/anaconda.repos.d from ctrl-alt-f2, then fiddle about in Software Sources to force anaconda to refresh the repo list (changing to http://foo , leaving the spoke, then going back in and changing back to Closest Mirror does the job).
So you can create a fedora-server.repo which points directly to https://dl.fedoraproject.org/pub/alt/stage/21_Alpha_TC7/Server/$basearch/os , then play around with the effects of the other repos in conjunction with that.
I found out two things by doing this:
1) bcl's reading is right: if both fedora-server.repo and fedora.repo are present and enabled, both will be used, which is not what we want for a Product installer, apparently.
2) there's another wrinkle: updates-testing has comps data - https://dl.fedoraproject.org/pub/fedora/linux/updates/testing/21/x86_64/repodata/ed30df7574fba0e4452e88ed0d993aa70edab4f21898221e69449b3dc5f3aeb6-comps-f21.xml (that link will go stale soon, but you get the point). Even if you delete fedora.repo , you *still* get the full list of groups from updates-testing's comps data. The only way to get the 'clean' Server group list is to create a valid fedora-server.repo and then remove or disable both fedora.repo and fedora-updates-testing.repo .
Post-release, I expect this problem would also apply to fedora-updates.repo (it only doesn't, at present, because that repo is empty).
I still don't have a great solution for this, and the issue with updates-testing makes it even harder, because presumably we *want* people to be able to pull updates from updates/updates-testing during a netinstall, if they want to. If we want a 'clean' group list for Product netinstalls, we need some way to not display the groups from the updates repos, or we need to rethink our approach here. :(
fedora-repos-21-0.7 has been submitted as an update for Fedora 21.
Alpha RC1 includes the .repo files for each product and seems to hit the correct MM URL when handling them. It still doesn't actually work, as MM isn't correctly implementing the URLs yet, but it looks like anaconda is DTRT at this point, to me. I'll hold off setting VERIFIED until we can test with a fixed MM and know for sure, but it seems like progress to me.
Discussed in the 2014-09-18 Go/No-go meeting. Fesco decided to not block Alpha with non-productized netinst images. Currently the issue is with MirrorManager and not the netinstallation images themselves - so no criteria is broken and it's blocker status has been addressed.
fedora-repos-21-0.7 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
So we need to come up with a plan for this going forward, folks. If Product-ized netinsts are still the goal, there's gotta be a design to make it work. The issues in c#24 and c#25 need to be handled somehow.
Setting back to ASSIGNED as we are aware there are issues here which are not yet handled.
(In reply to Adam Williamson (Red Hat) from comment #24)
> (I guess I could also note that I had a blue-sky idea of adding some kind of
> comps field which denotes whether a group is association with a Product, and
> have Product installers only show groups that are associated with that
> Product in comps, which would avoid the need for all this product-specific
> installer tree malarkey in the first place. But I don't know if that's
I like this idea and think we should explore it more. It's less kludgy than anything else I can think of, and solves the issue with the updates repositories too.
*** Bug 1145250 has been marked as a duplicate of this bug. ***
As per c#28 we considered this to no longer block Alpha once the netinst images *worked*. At present my understanding is we would also not consider this to block Beta in a QA sense - again, as long as the netinsts deploy *something* without you having to manually configure a mirror, no criteria are violated.
It's up to FESCo and the WGs, really, to decide whether we hard require Product-y network installs at Beta, and if so to come up with a plan for achieving it. This is still a major point of incoherence for the whole Product effort, and Dennis and I have tried to flag it up for attention, but it just doesn't seem to happen :/
(In reply to Adam Williamson (Red Hat) from comment #34)
> It's up to FESCo and the WGs, really, to decide whether we hard require
> Product-y network installs at Beta, and if so to come up with a plan for
> achieving it.
I'm pretty strongly on the side of not slipping for this.
> This is still a major point of incoherence for the whole
> Product effort, and Dennis and I have tried to flag it up for attention, but
> it just doesn't seem to happen :/
Yeah, I can take some of the blame... with the Cloud WG hat on, this is a non-issue, and then Workstation said they were doing live images only, and so I kind of filed it under "okay, server WG will deal with this". *shoves Stephen Gallagher _right_ under the bus*
Actually, Workstation has come out explicitly on the side of "Network installs are important and should be available", so it's more than just Server.
That being said, I've lost track of where we are on this. Last I heard, we were expecting to solve this in mirror-manager. Am I mistaken?
Yes, you were. We discussed this today, but to summarize for the bug:
What we fixed in mirrormanager was letting the netinsts work OOTB *at all*. The state of play at Alpha, and now, is that they work, but they act as universal images. Right now they have their product repos, the 'fedora' repo, and the 'updates-testing' and 'updates' repos (a stable release would use only 'updates' by default). The product repos have restricted comps data listing only the Product environment group, but fedora and updates-testing repos have full comps data, so as long as either of those is available, the Software Selection spoke will show *all* environment groups.
We discussed this issue on IRC this morning and came up with some potential approaches. I believe the state of play is that a ticket will be filed (with FESCo?) to discuss the desired outcome and we'll move on from there.
It sounded like the preferred outcomes In An Ideal World would be either Product network install images which *default* to the appropriate environment group but offer all the others (we have a possibly-viable way to achieve this which involves tweaking the comps data in the Product repos, specifically changing the value of the <display_order> setting for the Product's env group), or a single non-branded universal network install image. The latter isn't trivial to achieve, but we're fairly sure it's at least possible. We have an idea about the former, but it would require testing out to see if it actually works.
For the record, the approaches are being discussed on FESCo ticket: https://fedorahosted.org/fesco/ticket/1358
*** Bug 1146306 has been marked as a duplicate of this bug. ***
Further for the record, for Beta we agreed (AIUI) that Server would be the only 'official' netinst image, and it would default to the Server env group but offer all other env groups. Workstation netinst was dropped. We still built a Cloud netinst, but I think this was an oversight, not intentional.
Beta shipped with this behaviour, but behind the scenes it's still doing unnecessary stuff with useless Product-specific repositories. I've resurrected:
to try and deal with that.