Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serial & console connections set TERM to vt220 #9

Closed
subpop opened this issue Dec 18, 2019 · 1 comment
Closed

Serial & console connections set TERM to vt220 #9

subpop opened this issue Dec 18, 2019 · 1 comment
Labels
bug Something isn't working

Comments

@subpop
Copy link
Owner

subpop commented Dec 18, 2019

Is it possible to set the TERM to xterm-256color, or inherit the TERM value from the calling environment?

@subpop subpop added the bug Something isn't working label Dec 18, 2019
@subpop subpop changed the title Serial & console connections set TERM to vt100 Serial & console connections set TERM to vt200 Dec 18, 2019
@subpop subpop changed the title Serial & console connections set TERM to vt200 Serial & console connections set TERM to vt220 May 12, 2020
@subpop
Copy link
Owner Author

subpop commented May 14, 2020

After extensive research, this turns out to be the responsibility of the guest OS, not the connecting terminal [emulator] or virtual serial devices. The TERM value is set by the init system, be it systemd or otherwise. A guest disk image would need to be modified to set the TERM to something appropriate for a terminal emulator (such as xterm256-color).

After a few experimental implementations, including calling libguestfs directly using the cgo FFI, and invoking guestfish as a series of child processes, I have concluded that it should not be the responsibility of vm to modify the guest filesystem to suite its expectations. This obviously applies to modifying the TERM value of serial TTYs, but I also feel it extends to supporting something like cloud-init. While cloud-init is prominently used in the "cloud image" space, it can easily be supported by applying an appropriately constructed read-only disk image using the --disk option of the create subcommand.

Put another way, vm enables the easy creation of domains backed by existing qcow2 disk images. It will also fetch images from provided URLs and convert them to qcow2 if necessary, but it will not modify said image in any way. There are mature tools (guestfish, virt-builder) to aid in the modification and creation of qcow2 images already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant