Description of problem: I followed https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source . Usually, I clone an incomplete repo (I exclude Packages/) because of my bandwidth, and then use inst.stage2=url. In this case, images/updates.img is automatically detected. However, today I realized I can simply extract DVD image and have a "full" installation (sufficient for a default installation). So I extracted it, placed updates.img into updates/ and used inst.repo=url. However, in this case, updates.img was not detect. When looking into log, anaconda didn't even try to access that file. The documentation says it should work: "If you're doing a CD, hard drive, HTTP, or FTP install you can also put the updates.img in your tree to be picked up by all installs automatically. Put the file in the images/ directory. It must have exactly the name updates.img, even if you received it with a different name. " https://fedoraproject.org/wiki/Anaconda/Updates#Updates_from_the_Tree (it talks about a tree, so I assume that means inst.repo=). This problem can be worked around by using inst.updates=url, that works. Or it can be worked around by using "inst.stage2=url inst.repo=url", where url is the same for both. But the simplest case of just inst.repo=url is broken. This is broken regardless of protocol, it seems. I tried http and nfs, both work with inst.stage2 and none of them work with inst.repo. Version-Release number of selected component (if applicable): F21 RC5 Server x86_64 netinst (booted) + DVD (extracted and used as repo) https://fedorapeople.org/groups/qa/updates/updates-unipony.img as updates.img, taken from this test case: https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_URL (you'll see a pony instead of checkboxes in storage screen) anaconda-21.48.21-1.fc21.x86_64 dracut-038-30.git20140903.fc21.x86_64 How reproducible: always, it seems Steps to Reproduce: 1. extract F21 RC5 Server DVD 2. download the linked updates.img (or use your own) and copy it to images/updates.img (it must be named like this) 3. publish your directory over http or nfs 4. try booting e.g. Server netinst with inst.stage2=url, see that updates.img was applied 5. try booting e.g. Server netinst with inst.repo=url, see that updates.img was not applied Actual results: updates.img is not automatically detected and applied from a tree Expected results: updates.img is automatically detected and applied from a tree
Created attachment 964660 [details] inst.stage2-anaconda.log
Created attachment 964661 [details] inst.stage2-program.log
Created attachment 964662 [details] inst.stage2-journal
Created attachment 964663 [details] inst.repo-anaconda.log
Created attachment 964664 [details] inst.repo-program.log
Created attachment 964665 [details] inst.repo-journal
I think this could be dracut's fault (or it's anaconda plugin, or however that works), because with inst.stage2, I clearly see dracut touching these files over http very yearly in the boot process: 192.168.11.30 - - [04/Dec/2014 14:33:46] "GET //.treeinfo HTTP/1.1" 200 - 192.168.11.30 - - [04/Dec/2014 14:33:46] "GET //LiveOS/squashfs.img HTTP/1.1" 200 - 192.168.11.30 - - [04/Dec/2014 14:33:47] "GET //images/updates.img HTTP/1.1" 200 - 192.168.11.30 - - [04/Dec/2014 14:33:47] "GET //images/product.img HTTP/1.1" 200 - But I don't see anything like that when inst.repo is used. So either dracut should do it and doesn't, or it should be handled by anaconda itself before it fully initializes itself.
This might violate this criterion: "The installer must be able to use an installer update image retrieved from removable media or a remote package source. " https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Update_image But it's surely up to discussion, I'm not sure whether "remote package source" means an installation tree. Please note that I have provided two workarounds in comment 0 for this issue.
Just out of curiosity, I tried the same approach with F20 DVD/netinst (even the same updates.img, it also applies), and the same issue is present there. So this is not a regression.
In comment 0 I have a mistake: "So I extracted it, placed updates.img into updates/ and used inst.repo=url." It should be: "So I extracted it, placed updates.img into images/ and used inst.repo=url."
If this issue was present in Fedora 20, I'm going to vote -1 for Blocker status. (I was already leaning that way, but the fact that it has been there since the last release without anyone noticing cemented it for me).
So, Josef Skládanka found the problem here. I haven't realized that when booting from netinst it already has some stage2 defined. So when I tried it with inst.repo, it was in fact inst.stage2 inst.repo. And when I tried it with inst.stage2 inst.repo, it was in fact inst.stage2 inst.stage2 inst.repo (the latter inst.stage overrode the former one). When I remove the inst.stage2 provided by netinst (looking something like inst.stage2=hd:LABEL=Fedora-S-21-x86_64), and leave only my inst.repo=url in, it actually works. It also works when I use pxeboot. So, to reiterate, the only use case when it doesn't work is inst.repo used together with netinst/DVD without erasing the provided inst.stage2=hd. That's a very tight corner case I think. The documentation doesn't say this shouldn't work (when reading it, I would assume otherwise, that it should work), but maybe this is just a problem of documentation not being crystal clear.
-1 blocker here.
Right, this isn't a bug. The updates.img and product.img are pulled from the same place squashfs.img comes from. If you have a stage2 then that's where it comes from. If you have no stage2 then all of them come from the repo that you point to. The idea is that the updates/product should match the squashfs.img you are booting. Also, FYI, the extraction of product.img, updates.img and any inst.updates happens in the anaconda-dracut module so you'll see that logged by dracut.
Thanks for your explanation, Brian. I think that linked wiki page with documentation [1] should be clarified in this sense, otherwise I (or someone else) will probably find this "bug" again in the next release cycle, and then again and again. I'll definitely clarify our test cases, but I'm wary of adjusting your documentation, it's too easy to be imprecise without proper background knowledge and then you're not happy about it, we have this experience. Can you please adjust it, or should I try? I assume and additional sentence or two in this sense would help: "This updates.img is only retrieved from the location where stage2 image is pulled from. If you use inst.repo boot option to specify your installation tree, but you also use inst.stage2 boot option with a different location, only the inst.stage2 location is going to be searched for the updates.img file, and not the inst.repo location." [1] https://fedoraproject.org/wiki/Anaconda/Updates#Updates_from_the_Tree
Adjusted wiki: https://fedoraproject.org/w/index.php?title=Anaconda%2FUpdates&diff=397720&oldid=294684 Please revert or adjust if you don't like it.