starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Easy creation of WSLv1 variant of WSLv2 profiles (easy management of WSL versions) #17225

New Issue
Closed
opened 2026-01-31 05:35:56 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 05:35:56 +00:00
Owner
Copy Link

Originally created by @vadimkantorov on GitHub (Apr 11, 2022).

Currently there are no such options in Ubuntu profile settings.

I have WSLv2 installed, but I'd also like to use WSLv1 sometimes because (I hope) it might consume less memory. I found this documentation https://docs.microsoft.com/en-us/windows/wsl/install on changing WSL version for a given distro. It would be nice if Terminal helped with cloning a distro and toggling WSL version and so on. It could be placed into Ubuntu profile settings, but it'd be a useful feature.

Main scenario: bash+ssh+some light python script debugging. For now I'm just running a bash (without even a ssh session) , and it consumes full 700Mb of RAM (in Vmmem process) which seems an overkill.

Originally created by @vadimkantorov on GitHub (Apr 11, 2022). Currently there are no such options in Ubuntu profile settings. I have WSLv2 installed, but I'd also like to use WSLv1 sometimes because (I hope) it might consume less memory. I found this documentation https://docs.microsoft.com/en-us/windows/wsl/install on changing WSL version for a given distro. It would be nice if Terminal helped with cloning a distro and toggling WSL version and so on. It could be placed into Ubuntu profile settings, but it'd be a useful feature. Main scenario: bash+ssh+some light python script debugging. For now I'm just running a bash (without even a ssh session) , and it consumes full 700Mb of RAM (in Vmmem process) which seems an overkill.
claunia added the Issue-FeatureProduct-WSLNeeds-TriageArea-Extensibility labels 2026-01-31 05:35:56 +00:00
claunia commented 2026-01-31 05:35:58 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 11, 2022):

I'm gonna tap in @craigloewen-msft for thoughts on this one. It's not a bad idea, but it's a lot of tight coupling with WSL that I'm not sure we'd be able to adequately maintain. Maybe better suited as an extension idea. That would raise a LOT of potential scenarios - modifying fragments, but also adding custom UI to the settings UI for certain types of profiles.

@zadjii-msft commented on GitHub (Apr 11, 2022): I'm gonna tap in @craigloewen-msft for thoughts on this one. It's not a bad idea, but it's a lot of tight coupling with WSL that I'm not sure we'd be able to adequately maintain. Maybe better suited as an extension idea. That would raise a LOT of potential scenarios - modifying fragments, but also adding custom UI to the settings UI for certain types of profiles.
claunia commented 2026-01-31 05:35:58 +00:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (Apr 11, 2022):

Given that Terminal is very often used with WSLv1/v2 and is aspiring to drive the Terminal / Linux experience on Win, it might be good to have some strategy about this.

I'm not even sure if you must have two separate distros (two Ubuntus of the same versions differing only by wsl version) and if it's possible. The easiest would be if it just required padding an extra flag to wsl.exe

@vadimkantorov commented on GitHub (Apr 11, 2022): Given that Terminal is very often used with WSLv1/v2 and is aspiring to drive the Terminal / Linux experience on Win, it might be good to have some strategy about this. I'm not even sure if you must have two separate distros (two Ubuntus of the same versions differing only by wsl version) and if it's possible. The easiest would be if it just required padding an extra flag to wsl.exe
claunia commented 2026-01-31 05:35:58 +00:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (Apr 13, 2022):

It might be good if tab tooltip or profile name specified which WSL version it's using

@vadimkantorov commented on GitHub (Apr 13, 2022): It might be good if tab tooltip or profile name specified which WSL version it's using
claunia commented 2026-01-31 05:35:59 +00:00
Author
Owner
Copy Link

@craigloewen-msft commented on GitHub (Apr 20, 2022):

@vadimkantorov are you switching between distros often? Is this more of a need to take some of the WSL commands and settings and put them into some form of GUI?

@craigloewen-msft commented on GitHub (Apr 20, 2022): @vadimkantorov are you switching between distros often? Is this more of a need to take some of the WSL commands and settings and put them into some form of GUI?
claunia commented 2026-01-31 05:35:59 +00:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (Apr 20, 2022):

I mostly use WSLv1 bash/vim/ssh for basic work as it doesn't allocate a big VM RAM process upfront and sometimes I need WSLv2 (I'm not sure that RAM is actually committed, but to be sure I prefer to do without it).

So for me, I'm using same Ubuntu20.04 for both WSLv1 and WSLv2. Unfortunately, right now even creating a WSLv1 profile/distro starting from WSLv2 profile/distro requires following a few manual, somewhat tricky steps described in https://stackoverflow.com/questions/66065419/how-to-run-multiple-wsl2-instances-on-windows .

I now think the real problem of duplicating the distro as both WSLv1 and WSLv2 should be tackled both by WSL and Terminal together: discussed in https://github.com/microsoft/WSL/issues/8271. Questions to be decided: 1) instantiating a distro from a pristine version without figuring out the obscure paths and export/import; 2) can a Linux partition file be shared between WSLv1 and WSLv2? If not, how to manage the both partitions so that UX / command line arguments to wsl.exe in a convenient way; 3) setting non-priveleged user as default for WSLv1 distro

Right now Terminal could display somewhere in UI (tab tooltip? tab color?) which version of WSL is the profile/distro running.

@vadimkantorov commented on GitHub (Apr 20, 2022): I mostly use WSLv1 bash/vim/ssh for basic work as it doesn't allocate a big VM RAM process upfront and sometimes I need WSLv2 (I'm not sure that RAM is actually committed, but to be sure I prefer to do without it). So for me, I'm using same Ubuntu20.04 for both WSLv1 and WSLv2. Unfortunately, right now even creating a WSLv1 profile/distro starting from WSLv2 profile/distro requires following a few manual, somewhat tricky steps described in https://stackoverflow.com/questions/66065419/how-to-run-multiple-wsl2-instances-on-windows . I now think the real problem of duplicating the distro as both WSLv1 and WSLv2 should be tackled both by WSL and Terminal together: discussed in https://github.com/microsoft/WSL/issues/8271. Questions to be decided: 1) instantiating a distro from a pristine version without figuring out the obscure paths and export/import; 2) can a Linux partition file be shared between WSLv1 and WSLv2? If not, how to manage the both partitions so that UX / command line arguments to wsl.exe in a convenient way; 3) setting non-priveleged user as default for WSLv1 distro Right now Terminal could display somewhere in UI (tab tooltip? tab color?) which version of WSL is the profile/distro running.
claunia commented 2026-01-31 05:36:00 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 3, 2022):

So, I'm going to have to reject this feature request (and some of its sub-requests). Here's why:

  • (As you've identified,) right now, WSL 1 versus 2 is a per-distribution-install preference, and toggling it requires WSL booting up the utility VM and moving a bunch of files around/into or out of the ext4 volume. It's an I/O-heavy operation that's supposed to be done a small number of times. I know there's an ask to make it toggleable at launch time, or offer a quick way to copy-and-convert, but ...
  • ... it doesn't look like the WSL team has plans to continue investing in WSLv1, and I don't think that they'll be spending time on improving the migration tools, and ...
  • ... while we're good friends with the WSL team, we're trying to avoid putting WSL into Terminal. I feel like that's really what this boils down to: us coupling WSL and Terminal enough to give Terminal control over how and when WSL distributions are installed. I'm willing to take on that coupling as an extension, but doing it in-box just to support transforming a distro from v1 to v2 and back is just too niche of a use case to justify investing in.[1]

[1] Power users already have a way to do this, even if it is not ergonomic. Importing and exporting is well-documented and somebody could certainly write a UI around it. Non-power-users, on the other hand, likely have no need of this and would not benefit from a UI anyway. Even displaying the version somewhere[2] benefits only the folks who would have otherwise already known.

[2] That having been said, allowing generated profiles to control some display-related information (software version, origin, type, etc.) would be broadly useful outside of WSL, and I am not against it. We would need to make sure we surface it in a way users will actually care about.

@DHowett commented on GitHub (May 3, 2022): So, I'm going to have to reject this feature request (and some of its sub-requests). Here's why: * (As you've identified,) right now, WSL 1 versus 2 is a per-distribution-install preference, and toggling it requires WSL booting up the utility VM and moving a bunch of files around/into or out of the ext4 volume. It's an I/O-heavy operation that's supposed to be done a small number of times. I know there's an ask to make it toggleable at launch time, or offer a quick way to copy-and-convert, but ... * ... it doesn't look like the WSL team has plans to continue investing in WSLv1, and I don't think that they'll be spending time on improving the migration tools, and ... * ... while we're good friends with the WSL team, we're trying to avoid _putting WSL into Terminal_. I feel like that's really what this boils down to: us coupling WSL and Terminal enough to give Terminal control over how and when WSL distributions are installed. I'm willing to take on that coupling as an extension, but doing it in-box just to support transforming a distro from v1 to v2 and back is just too niche of a use case to justify investing in.[1] [1] Power users _already_ have a way to do this, even if it is not ergonomic. Importing and exporting is well-documented and somebody could certainly write a UI around it. _Non-power-users,_ on the other hand, likely have no need of this and would not benefit from a UI anyway. Even displaying the version somewhere[2] benefits only the folks who would have otherwise already known. [2] That having been said, allowing generated profiles to control some display-related information (software version, origin, type, etc.) would be broadly useful outside of WSL, and I am not against it. We would need to make sure we surface it in a way users will actually care about.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Extensibility Issue-Feature Needs-Triage Product-WSL
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17225
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?