Bug 1654055 - virt-install --location isn't working with a netinst boot.iso
Summary: virt-install --location isn't working with a netinst boot.iso
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-27 22:54 UTC by Brian Lane
Modified: 2019-02-09 02:13 UTC (History)
5 users (show)

Fixed In Version: virt-manager-2.1.0-1.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-09 02:13:13 UTC


Attachments (Terms of Use)

Description Brian Lane 2018-11-27 22:54:35 UTC
I'm running virt-install --location /path/to/iso after mounting the F29 Everything boot.iso on /path/to/iso and I'm getting an error:

ERROR    Error validating install location: Could not find an installable distribution at '/path/to/iso/'                                                                                                                     

The location must be the root directory of an install tree.
See virt-install man page for various distro examples.


I'm almost 100% sure this used to work. Also tried with the F28 boot.iso with the same results.

Full command, after mounting the iso, is:

sudo virt-install --name composer-f29 --location /path/to/iso/ --initrd-inject=./f29-composer.ks --extra-args "ks=file:/f29-composer.ks" --disk size=10 --memory 4096 --vcpus=2 --rng=/dev/urandom

Using F29 host with:
virt-manager-1.6.0-1.3.git3bc7ff24c.fc29.noarch

Comment 1 Cole Robinson 2018-12-11 21:07:29 UTC
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?

Comment 2 Brian Lane 2018-12-12 19:19:26 UTC
Yeah, it used to. Just tried virt-install-2.0.0-1.fc29.noarch and it is working again, thanks!

Comment 3 Brian Lane 2018-12-12 21:42:30 UTC
(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?

Comment 4 Cole Robinson 2018-12-13 14:15:26 UTC
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?

Comment 5 Brian Lane 2018-12-13 18:34:45 UTC
(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 :)

Comment 6 Cole Robinson 2018-12-13 21:18:48 UTC
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

Comment 7 Dusty Mabe 2018-12-14 04:14:47 UTC
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?

Comment 8 Cole Robinson 2018-12-14 17:24:37 UTC
--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...

Comment 9 Dusty Mabe 2018-12-14 19:48:29 UTC
(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?

Comment 10 Cole Robinson 2018-12-17 13:44:32 UTC
(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

Comment 11 Cole Robinson 2019-02-03 18:06:34 UTC
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

Comment 12 Fedora Update System 2019-02-03 21:54:45 UTC
virt-manager-2.1.0-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c38a307cd5

Comment 13 Fedora Update System 2019-02-05 04:05:28 UTC
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

Comment 14 Fedora Update System 2019-02-09 02:13:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.