After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763219 - Allow setting a box name in creation assistant
Allow setting a box name in creation assistant
Status: RESOLVED OBSOLETE
Product: gnome-boxes
Classification: Applications
Component: general
3.19.x
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-03-07 11:52 UTC by Allan Day
Modified: 2018-01-11 10:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allan Day 2016-03-07 11:52:54 UTC
I mainly use Boxes to test GNOME continuous images, which means that most of my VMs have very similar names after creation. The only way for me to tell them apart is to give them different names, and I often have a name in mind for a VM when I create it. Unfortunately, I am unable to set this name when I create the Box, though, and have to go into the properties after it has been created in order to set the name.

It would be more convenient to be able to set the name as a part of the creation workflow.
Comment 1 Federico Bruni 2016-04-08 15:53:52 UTC
Another related issue is that a VM created in Boxes appears as boxes-unknown (boxes-unknown-1, etc.) to virsh.
This does not happen if the VM is created with virt-install.
Comment 2 Zeeshan Ali 2016-04-08 16:29:29 UTC
(In reply to Federico Bruni from comment #1)
> Another related issue is that a VM created in Boxes appears as boxes-unknown
> (boxes-unknown-1, etc.) to virsh.

That's not an issue and if it is, it's unrelated to this one. :)

> This does not happen if the VM is created with virt-install.

That is because it leaves the naming to you?
Comment 3 Zeeshan Ali 2016-04-08 16:31:14 UTC
(In reply to Zeeshan Ali (Khattak) from comment #2)
> (In reply to Federico Bruni from comment #1)
> > Another related issue is that a VM created in Boxes appears as boxes-unknown
> > (boxes-unknown-1, etc.) to virsh.
> 
> That's not an issue and if it is, it's unrelated to this one. :)

Usually boxes are named automatically based on the operating system and if operating system is unknown, 'boxes-unknown' is used. Feel free to suggest a better naming scheme for such cases but please file a separate bug for that then.
Comment 4 Michael Catanzaro 2016-12-06 22:45:41 UTC
(In reply to Allan Day from comment #0)
> I mainly use Boxes to test GNOME continuous images, which means that most of
> my VMs have very similar names after creation. The only way for me to tell
> them apart is to give them different names, and I often have a name in mind
> for a VM when I create it. Unfortunately, I am unable to set this name when
> I create the Box, though, and have to go into the properties after it has
> been created in order to set the name.
> 
> It would be more convenient to be able to set the name as a part of the
> creation workflow.

I almost never like the name that Boxes picks for my VM. I want to name it "Ubuntu 16.10", not "ubuntu-16". Currently I have to change it from the properties dialog after the VM is created, which works but isn't fun.
Comment 5 Zeeshan Ali 2016-12-12 17:33:19 UTC
(In reply to Michael Catanzaro from comment #4)
> (In reply to Allan Day from comment #0)
> > I mainly use Boxes to test GNOME continuous images, which means that most of
> > my VMs have very similar names after creation. The only way for me to tell
> > them apart is to give them different names, and I often have a name in mind
> > for a VM when I create it. Unfortunately, I am unable to set this name when
> > I create the Box, though, and have to go into the properties after it has
> > been created in order to set the name.
> > 
> > It would be more convenient to be able to set the name as a part of the
> > creation workflow.
> 
> I almost never like the name that Boxes picks for my VM. I want to name it
> "Ubuntu 16.10", not "ubuntu-16". Currently I have to change it from the
> properties dialog after the VM is created, which works but isn't fun.

Actually "Ubuntu 16.10" will be picked up by Boxes if osinfo-db (if you have it) has info on this OS. :) The main reason to provide osinfo-db snapshots was exactly so that distros can get latest data w/o having to upgrade libosinfo (or any software).
Comment 6 Federico Bruni 2017-10-31 17:18:13 UTC
Zeeshan, with regard to comment #3, how it happens that a system is unknown?
I'm installing a Debian testing (netinst) iso file. I'd like to report this problem to Debian developers, but I need to understand what Boxes looks for and what Debian is missing.

Thanks
Comment 7 Michael Catanzaro 2017-10-31 17:36:47 UTC
I think osinfo-db should only be used to autofill a default name. It almost always suggests a terrible name in practice. Best let the user set one in the creation assistant, IMO.
Comment 8 Felipe Borges 2017-11-02 10:10:11 UTC
(In reply to Federico Bruni from comment #6)
> Zeeshan, with regard to comment #3, how it happens that a system is unknown?
> I'm installing a Debian testing (netinst) iso file. I'd like to report this
> problem to Debian developers, but I need to understand what Boxes looks for
> and what Debian is missing.

Could you run $ osinfo-detect <iso_file> to see whether libosinfo can identify the given image file?
Comment 9 Federico Bruni 2017-11-02 11:37:44 UTC
Here's what I get with the current testing netinst:

$ osinfo-detect debian-testing-amd64-netinst.iso 
Media is bootable.

$ osinfo-detect --format=env debian-testing-amd64-netinst.iso 
OSINFO_BOOTABLE=1


And here's what I get with debian 9 (stretch) netinst iso file:

$ osinfo-detect debian-9.2.1-amd64-netinst.iso 
Media is bootable.
Media is an installer for OS 'Debian 9'


So it seems that the problem is testing, which is a rolling release.

As I build custom images, I'd be interested to know what osinfo-detect looks for in the iso file to guess the OS version.
Comment 10 GNOME Infrastructure Team 2018-01-11 10:41:29 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/89.