Created attachment 561852 [details]
shot1.png

Created attachment 561853 [details]
shot2.png

Created attachment 561854 [details]
shot3.png

Created attachment 561855 [details]
anaconda.log

Created attachment 561856 [details]
anaconda-yum.conf

Created attachment 561857 [details]
ifcfg.log

Created attachment 561858 [details]
program.log

Created attachment 561859 [details]
storage.log

Created attachment 561860 [details]
syslog

Created attachment 561861 [details]
X.log

Created attachment 561862 [details]
yum.log

This kinda breaks pxeboot and kickstart (unless some repos are manually defined). Hard to say which milestone this should block, proposing as Beta blocker.

from anaconda.log:
10:03:40,019 INFO loader: kernel command line:
10:03:40,019 INFO loader:     method=http://download.englab.brq.redhat.com/pub/fedora/fedora-alt/stage/17-Alpha.TC2/Fedora/i386/os/


10:04:12,745 ERR loader: Error downloading http://download.englab.brq.redhat.com/pub/fedora/fedora-alt/stage/17-Alpha.TC2/Fedora/i386/os//images/product.img: HTTP response code said error
10:04:13,137 INFO loader: Running anaconda script /sbin/anaconda
10:04:13,338 INFO anaconda: /sbin/anaconda 17.7
10:04:13,339 WARN anaconda.stdout: Boot argument 'method' is deprecated. In the future, use 'inst.method'.
10:04:14,767 INFO loader: 1048576 kB (1024 MB) are available
10:04:14,782 INFO anaconda: anaconda called with cmdline = ['/sbin/anaconda', '--graphical', '--selinux', '--lang', 'en_US.UTF-8', '--keymap', 'us', '--repo', 'http://download.englab.brq.redhat.com/pub/fedora/fedora-alt/stage/17-Alpha.TC2/Fedora/i386/os/']

Why do you need "--location=..."? You specify the repo this way.

Moreover this should definitely result in 'repo=' not 'method=' adding crobinso to CC list.

I didn't know that virt-install also adds 'method=' kernel option when used with --location. That's the reason why anaconda is confused.

Reassigning to virt-install. The problem is that --location supposes that the same directory contains both kernel+initrd and yum package repository. But for development composes this is not true, there's just the kernel+initrd pair. And we have to use default online yum repositories for installation.

As far as I understand this, either a change in virt-install behavior is needed (e.g. a new option that will suppress the additional 'method=' argument), or anaconda must be able to intelligently deal with nonexistent repositories (having some boot/kickstart option to suppress these error messages).

(In reply to comment #14)
> I didn't know that virt-install also adds 'method=' kernel option when used
> with --location. That's the reason why anaconda is confused.
> 
> Reassigning to virt-install. The problem is that --location supposes that the
> same directory contains both kernel+initrd and yum package repository. But for
> development composes this is not true, there's just the kernel+initrd pair. And
> we have to use default online yum repositories for installation.
> 
> As far as I understand this, either a change in virt-install behavior is needed
> (e.g. a new option that will suppress the additional 'method=' argument), or
> anaconda must be able to intelligently deal with nonexistent repositories
> (having some boot/kickstart option to suppress these error messages).
Anaconda has no way to determine whether a nonexistent repo was provided by virt-install or by user (in that case the "screenshotted" behaviour is adequate).

Would be nice if we could depend on .treeinfo packagedir= here, but that seems to be empty on at least f16 GA .treeinfo as well so it isn't reliable. Anyone know where to file a bug for that?

And if method= is deprecated, can anyone tell me the earliest that repo= was introduced? RHEL5? RHEL6? Just so I know where to do the cut off.

I am removing Beta blocker, because this most probably influences only development composes. virt-install will work fine with official public composes.

However, we would like to have this solved soon, because our automated installation test is blocked on this.

There appears to be one workaround and that is to re-define the method= option using --extra-args.

(In reply to comment #16)
> Would be nice if we could depend on .treeinfo packagedir= here, but that seems
> to be empty on at least f16 GA .treeinfo as well so it isn't reliable. Anyone
> know where to file a bug for that?
Lorax creates .treeinfo file, but at the time when it has no idea where the packagedir would be located. This info could be provided by tools creating trees like http://download.englab.brq.redhat.com/pub/fedora/fedora-alt/stage/17-Alpha.TC2/Fedora/i386/os/ but as it can be seen from this particular example there could be a tree without any packagedir.
So I think .treeinfo would not be a good source of info. Rather do not automatically provide any 'repo=...' and let the user to set it with an option.

> 
> And if method= is deprecated, can anyone tell me the earliest that repo= was
> introduced? RHEL5? RHEL6? Just so I know where to do the cut off.
RHEL5 uses 'method=' RHEL6 use 'repo='.

1. Can virt-install check whether the package repo is present and add 'repo=' option only when it is?

2. The default behavior (adding 'repo=' option) is fine and desired for most users using final composes, it creates problems just for people trying out development composes. If solution 1) is not possible, why not simply add a new option, that says "just boot from the provided kernel+initrd, but don't do any further magic, like adding further boot options"?

I have found a simple workaround, just use --extra-args "method=". But that's highly implementation specific and may change if anaconda code changes.

Okay, thinking about this some, it's not an easy situation.


To clarify, the reason we specify method= is a convenience for the user: virt-install already knows the URL, pass it to anaconda so the user doesn't need to type it again into anaconda text UI. This is doubly convenient since copy+paste between host guest isn't going to work here. Though this isn't essential functionality so if it regressed it's not the complete end of the world.

Options here are:

- Check .treeinfo, if no packagedir=, don't specify method= to anaconda. Sounds great in theory but as previously mentioned that packagedir field is historically useless, so we would have to conditionalize on fedora versions which sucks. Otherwise this would be the ideal way.

- Poke into the tree, only specify a method= argument if we see the Packages directory. This sucks because if the tree layout ever changes for say a new version of fedora, we have to patch virtinst to handle it, otherwise method= isn't specified when it could be. Those types of things are supposed to be what treeinfo saves us from.

How does anaconda error in this case? If it just throws an error message and then gives an option to continue, specifying actual install media, then it's probably not worth patching around in virt-install.

Cole, you're right. I have to repeat that AFAIK this only concerns Fedora development composes, which are not fully created (package tree is missing). For Final (and official Alpha, Beta) composes this should not be a problem. I don't propose any drastic changes.

After reading the previous comment, I think this use case can be easily solved by anaconda. Currently it's completely adamant that "Installation Repo" (specified by method=) must work. Look at the screenshots. But why? Let's pop up an error message if the URL is not available, why not. But allow user to cancel that dialog. That would move user into package+repo selection screen. The Installation Repo would get disabled. The user would be free to enable other pre-defined repositories (the online ones) or define a custom one.

Current anaconda behavior is too harsh.

If you agree, let's assign back to anaconda.

Agreed, reassigning to anaconda.

In the latest QA meeting Will Woods claimed that anaconda should gracefully continue if the yum repository is not present in the repo= location. That is not the case as this bug documents. We have found another use case for this (apart from using Branched composes), it is described in bug 805166 comment 13 and comment 10.

Note also this bug I filed yesterday:

http://bugzilla.redhat.com/show_bug.cgi?id=807562

anaconda seems to be entirely too insistent that the repository you pass with repo= be a *complete* repository, at present.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Proposing as F17 Final Blocker due to our criteria:

"It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to run."
https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria

Currently people can't run just the installer from PXE and download the packages from online repos. Anaconda insists that a full package repository is mirrored. In F16 and earlier it worked.

Discussed at 2012-04-20 blocker review meeting - http://meetbot.fedoraproject.org/fedora-bugzappers/2012-04-20/fedora-bugzappers.2012-04-20-17.01.log.txt . Agreed this is accepted as a blocker per the criterion cited in comment #26.

Has there been any movement on a fix or a workaround for this? Have we been able to confirm that full release builds won't be affected by this bug?

I think anaconda's current behavior for repo=XXX is reasonable: if you pass repo=XXX, we expect XXX to actually be a repo.

If the user (or virt-install) is sure that XXX is, in fact, a repo, then repo=XXX will make anaconda use that repo as its sole install source. This is the expected behavior - and it works fine for regular, non-mangled release trees. So no fix is necessary there.

If you're only using the URL to get the stage2 image, stage2=XXX is what you want. That does the install using the default repos (or whatever other repos you might set up otherwise). This satisfies the blocker criterion above. So no fix necessary here either.

So: I think the current anaconda behavior is fine as-is, and this can be dropped from the blocker list once someone verifies that using stage2=XXX works as described above.

In the future we might provide a way to specify that the default repos should be used *in addition* to the commandline/kickstart specified ones, but I don't think that exists right now.

The remaining question is what virt-install should do. I'd suggest using .treeinfo to figure out whether the target is a repo or not (as described in comment 21), but if virt-install doesn't want to confirm (or require) that the URL given is actually a complete repo, it should probably be using stage2=XXX instead.

Given that this bug has F17Blocker, and that we are talking about more than just virt-install issues here (PXE is explicitly mentioned several times), just reassigning it at this stage is not helpful. Moving this back to anaconda.

If this shouldn't be a blocker, let's engage QA and get it removed from the tracker. If this is NOTABUG, let's convince QA and then close it.

If this is entirely issues in other components like virtinst, cobbler, etc, let's convince QA, and then file new bugs or reassign this bug.

It certainly sounds like this bug is violating the release criteria mentioned in comment #26... but then again I don't understand the motivation for the release criteria explicitly mentioning incomplete repos, or why test composes need to be incomplete repos, or anaconda's historical behavior here. But I assume the folks that gave blocker+ have better understanding (though the meeting log link is basically empty)

cole: if stage2= works as described, then I agree the criterion is not violated: it _is_ possible to do an install using a 'repo' that contains only a stage2 image. But we should test that. Kamil or Tim, could you do so prior to the blocker meeting?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

stage2 isn't currently working right if there is no .treeinfo, patch sent to list.

(In reply to comment #32)
> stage2 isn't currently working right if there is no .treeinfo, patch sent to
> list.

This will satisfy the criterion when it works, thanks Brian.

But we would still prefer virt-install to work even with incomplete repos (example use case: you want to use newer/custom anaconda build with default online repos). I see three ways:

1. virt-install can distinguish complete and incomplete repositories (e.g. checking for Packages/ directory) and pass either repo= (for complete repository) or stage2= (for incomplete repository) to anaconda.

Will, can you tell us how to distinguish complete and incomplete repositories using .treeinfo? 'packagedir=' seems to be empty in both, I wonder why. Shouldn't there be a relative path if the repository contains Packages/?

2. virt-install can provide an option that will disable passing repo= to anaconda. The user can then specify 'stage2=' manually using --extra-args.

3. virt-install can provide an option to boot from a specific kernel+initrd pair. When looking into its manpage, I see only --location, which tries to be clever and passes repo= afterwards. Then I see --boot, which also modifies post-install boot configuration. But I don't see --kernel FILE and --initrd FILE options. Using that and specifying --extra-args 'stage2=' would also work.

These virt-install changes are not a blocker though (IMHO). We can create a new bug report about it because this one will be probably closed with that stage2= fix.

(In reply to comment #33)
> (In reply to comment #32)
> > stage2 isn't currently working right if there is no .treeinfo, patch sent to
> > list.
> 
> This will satisfy the criterion when it works, thanks Brian.
> 

Thinking more about this - our incomplete repos usually do contain .treeinfo, so this is a nice bonus, but it's probably not fully mandatory. However, wouldn't it be easier to use a direct link to squashfs.img rather then a link to the top directory (i.e. stage2=http://.../squashfs.img)? Do you need some other files from that directory? If not, this behavior would be much easier for those guys who want to set up a PXE with just anaconda and use online repos. They wouldn't have to create a 'fake' directories mirroring current layout (/LiveOS/ etc). They would just download three files (kernel, initrd, squashfs.img) and put that into pxelinux.cfg/default.

anaconda-17.25-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.25-1.fc17

Package anaconda-17.25-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-17.25-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-7353/anaconda-17.25-1.fc17
then log in and leave karma (feedback).

I have created a separate bug 819465 for tracking changes inside virt-install wrt stage2= support. Let's leave this bug solely for stage2= changes inside anaconda.

anaconda-17.25-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.