Bug 1654055

Thanks for the report. Can you try virt-install 2.0.0 from updates-testing?
Did this previously work, or is this your first time trying it?

Yeah, it used to. Just tried virt-install-2.0.0-1.fc29.noarch and it is working again, thanks!

(In reply to Brian Lane from comment #2)
> Yeah, it used to. Just tried virt-install-2.0.0-1.fc29.noarch and it is
> working again, thanks!

I just realized I tried it pointing to my mirror of the tree, which works thanks to .treeinfo

But it still fails when I point it to a mounted boot.iso
I'm fairly confident that used to work, I think it was using the pxeboot files which are under images/pxeboot

commit 5aedc0aff7ca453747a101a07283745271abaf20 looks like it might be related?

Okay that makes sense. Previously we had some fallback detection code that would probe directly for kernel/initrd paths if treeinfo wasn't present. That was dropped in virt-manager 2.0.0. I would prefer to keep it that way.

TBH I never considered the location+boot.iso case, but if we want and expect that work, we should add a treeinfo file to the media that describes the kernel/initrd location so apps don't have to poke around for it. Is that feasible?

(In reply to Cole Robinson from comment #4)
> Okay that makes sense. Previously we had some fallback detection code that
> would probe directly for kernel/initrd paths if treeinfo wasn't present.
> That was dropped in virt-manager 2.0.0. I would prefer to keep it that way.
> 
> TBH I never considered the location+boot.iso case, but if we want and expect
> that work, we should add a treeinfo file to the media that describes the
> kernel/initrd location so apps don't have to poke around for it. Is that
> feasible?

I don't think so. .treeinfo is really meant for full trees, and IIRC Anaconda uses its presence to detect boot.iso vs. DVD

I suppose it's not too hard to copy the iso contents over and dummy up a .treeinfo, but it was super convenient to just be able to mount it and run virt-install against it :)

I see... though maybe anaconda could key off specific info in .treeinfo to determine boot.iso vs full media. treeinfo may always presently describe trees but it also has useful fields for boot.iso too, like kernel/initrd paths, architecture, name/family etc. Separate discussion though

In virt-install land I'm trying to move past the whole 'blindly check for media paths to determine who/what the iso is' and dropping the fallback code was part of that, so I'm not really interested in bringing it back. Sorry for the inconvenience

Hey Cole. How much of a PITA would it be to add some of this code back? I think you are going to be fighting bug reports for quite some time about this functionality going missing and there will be plenty of people that will argue with you about whether it should be added back or not. 

For example, the man page still states that `--location foo.iso` is something you should be able to do: 
    - https://github.com/virt-manager/virt-manager/blame/b91393e6c35b0e2903dbb50bb57a64464a7a3802/man/virt-install.pod#L383
    - https://github.com/virt-manager/virt-manager/blame/b91393e6c35b0e2903dbb50bb57a64464a7a3802/man/virt-install.pod#L405-L407


Also the man page still has `--cdrom` in it but I tried to switch the code to use --cdrom foo.iso` and it errored and said: `virt-install: error: the following arguments are required: --location`.

What do you feel is the best path forward?

--location foo.iso still works, for full tree ISOs. --location for a full tree ISO is more compelling because it allows fully offline installs.

I didn't realize using boot.iso here was something people were doing. --location boot.iso is a bit odd IMO: installing off of boot.iso requires network access, and if you have network access you can do --location $URL, so generally there should be a workaround. The URL case would be better too, because with .treeinfo in the URL you will get proper OS detection meaning we will set up the optimal VM defaults. If you point at a boot.iso with --location I don't think it would detect the OS correctly and you'd get slow non-virtio defaults, unless explicit --os-variant is passed

Adding the code back is not hard but it's a step backwards IMO. If we want tools to be able to programmatically fetch kernel/initrd from a boot.iso tree then boot.iso should have a .treeinfo or something similar, so tools don't need to hardcode these paths. Another option may be moving kernel/initrd path checking to libosinfo which is more sophisticated here but I will need to investigate that more to know if it makes sense. Something like .treeinfo though is IMO better long term so that media can easily self describe kernel locations, archs, OS name, etc.

If I'm wrong about any of the above I'm happy to revisit this...

(In reply to Cole Robinson from comment #8)
> --location foo.iso still works, for full tree ISOs. --location for a full
> tree ISO is more compelling because it allows fully offline installs.

ok that is an interesting datapoint

> 
> I didn't realize using boot.iso here was something people were doing.
> --location boot.iso is a bit odd IMO: installing off of boot.iso requires
> network access, and if you have network access you can do --location $URL,
> so generally there should be a workaround. 

I think the use case here (at least for me) is that at least a good part of
what you need to download to do the install (kernel + anaconda environment, 
i.e. the size of the boot.iso) don't have to get downloaded every time you 
run a test install.

Also, in the case of testing a local OSTree compose install via anaconda
we can just use the boot.iso and pull from local network.

> 
> Adding the code back is not hard but it's a step backwards IMO. If we want
> tools to be able to programmatically fetch kernel/initrd from a boot.iso
> tree then boot.iso should have a .treeinfo or something similar, so tools
> don't need to hardcode these paths. 

putting a .treeinfo inside a boot.iso seems reasonable to me. Any drawbacks
to doing this?

(In reply to Dusty Mabe from comment #9)
> 
> > 
> > I didn't realize using boot.iso here was something people were doing.
> > --location boot.iso is a bit odd IMO: installing off of boot.iso requires
> > network access, and if you have network access you can do --location $URL,
> > so generally there should be a workaround. 
> 
> I think the use case here (at least for me) is that at least a good part of
> what you need to download to do the install (kernel + anaconda environment, 
> i.e. the size of the boot.iso) don't have to get downloaded every time you 
> run a test install.
> 
> Also, in the case of testing a local OSTree compose install via anaconda
> we can just use the boot.iso and pull from local network.
> 

I'll reopen this bug to track looking into if libosinfo fits here, it already
has some tracking of kernel locations on non-treeinfo media but I need to dig
into it more. Not likely to happen in the short term either...

> > 
> > Adding the code back is not hard but it's a step backwards IMO. If we want
> > tools to be able to programmatically fetch kernel/initrd from a boot.iso
> > tree then boot.iso should have a .treeinfo or something similar, so tools
> > don't need to hardcode these paths. 
> 
> putting a .treeinfo inside a boot.iso seems reasonable to me. Any drawbacks
> to doing this?

Upthread discussion sounds like anaconda would need changes to handle it. Also
it doesn't solve the problem for old boot media. But IMO it's worth considering
as a way forward. I think anaconda or lorax bug is where the discussion should
go

Upstream will now ask libosinfo for help identifying iso kernel/initrd locations. It uses a different database and can recognize many boot.iso style media, like fedora in my testing, and also has the added benefit that virt-install doesn't require an explicit --os-variant which is easy to miss and without it you'll get crap non-virtio defaults.

Additionally I added some CLI support for manually pointing at kernel/initrd paths in an ISO if virt-install fails to detect it, so there's a bit of a workaround. Say foo.iso isn't detected by libosinfo/virt-install, but it has a kernel at images/vmlinuz and initrd at images/initrd.gz, you can do

virt-install --location foo.iso,kernel=images/vmlinuz,initrd=images/initrd.gz

So there's at least a workaround. But if you find media that libosinfo/virt-install doesn't detect, please file a libosinfo bug.

I'll be doing a release and build shortly

virt-manager-2.1.0-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c38a307cd5

virt-manager-2.1.0-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c38a307cd5

virt-manager-2.1.0-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.