ChatGPT As A Helper - A Transcript
53 views
Skip to first unread message
Thomas Passin
Oct 22, 2024, 12:07:54 AM10/22/24
to leo-editor
I've been trying to use ChatGPT to get help on actual problems that I didn't solve by using Internet search, or I wanted a more focused look at some particular issue. I've started to find it to be a real help - sometimes - but you have to set it up right, be patient, and keep shepherding it back to a helpful path.
A few days ago I had a serious problem with one of my Linux virtual machines. I upgraded the VirtualBox software and rebuilt the guest additions, but now I couldn't use the bidirectional clipboard or mount the shared folder. The shared folder is a folder on the host (Windows 10) drive that can be read and written to by the VM. The bidirectional clipboard means that the WIndows' clipboard can be shared by the VM (and any other VMs configured with it). With the clipboard, I could copy code snippets to the VM and insert Leo nodes that O copied form Leos on Windows. Without those two features, the VM is isolated.
With the VB community edition, you have to install the "Guest Additions" on the guest VM to get those features to work. This is routine and I've done it dozens of times. But now they didn't work.
I'm going to share the transcript of my session with ChatGPT that ended up with me solving the problem. I'm only going to show you the first bit of each response because typically it would spit out a lot of steps to follow, but the first step or two wouldn't work. In the end, an update to the guest VM had updated the Linux kernel but somehow the guest additions apparently was trying to install the older version. To confuse matters, the Distro also includes some version of the GA and which one is being updated and installed?
At the beginning I give Chat the ground rules. They are important.
Me
-----
This session is about running a linux virtualbox VM guest on a windows 10 host. I am fairly experienced in creating and running virtualbox VMs. You will respond as an expert in virtualbox operations and you will be concise.
I have a arch-based VM that has been in use for some time. I upgraded Virtualbox to the newest version, 7.1.x, installed the extension pack as an admin, and ran the VM. I installed the guest additions apparently successfully and rebooted the VM. Now each time I log on I get a notification that the VBox kernel client service is not running. Without working guest additions, bidirectional cut and paste do not work and I cannot access shared directories with the host.
What I have tried: reboots, uninstall/reinstall guest additions, and uninstall/reinstall the virtualbox software on the Windows host. Do you have any suggestions for restoring normal operations in the VM?
Chat
----
Yes! This issue often happens due to mismatches or missing kernel modules. Below are steps to restore normal operations in your Arch-based VM.
1. Confirm Kernel Module Compatibility
Ensure that the guest additions kernel modules match your Arch kernel version.
Inside the VM, run:
bash
uname -r
pacman -Qs virtualbox
Check that the installed VirtualBox Guest modules (virtualbox-guest-utils or similar) are compatible with the displayed kernel version.
---- much more omitted ---
Me
----
At step two:
modeprobe: ERROR: could not insert 'vboxsf': Protocol error
Chat
-----
The "Protocol error" indicates a problem with the vboxsf kernel module, usually caused by mismatches between the VirtualBox version, guest additions, or kernel modules. Let's address it step-by-step.
Steps to Resolve the vboxsf Protocol Error
---- more omitted -----
Me
---
Up through step 4, no change. systemctl status vboxservice has two lines that are possibly relevant. The error messages are:
1. VBoxDRMClient: already running, exiting
2. automount failed because it couldn't find the mount point for the shared directory in /media. However, the mount point exists. Its owner and group are root, so I assume we have a permissions problem here. Not that I, the user, are already a member of the vboxsf group.
Chat
---
Thank you for the details! Let’s break down the two issues and solve them:
Issue 1: VBoxDRMClient: already running, exiting
This warning suggests that the DRM client is already active. It’s usually benign and doesn’t affect shared folders, but we can ensure it’s not interfering.
Solution: Restart the vboxservice to ensure everything is clean:
bash
sudo systemctl restart vboxservice
sudo systemctl status vboxservice
If the warning persists but everything else works, it can be safely ignored since it’s not likely related to your shared folder issue.
---- more omitted -----
Me
---
step 2 failed to mount with a message "no such device". ls -id permissions look right: drwxrwx---
Chat
-----
The "no such device" error suggests that the vboxsf kernel module is either not loaded properly or incompatible with your setup. Let’s address this step-by-step.
Steps to Resolve the "No Such Device" Error
1. Verify if vboxsf Module is Loaded
Check if the vboxsf module is present:
bash
lsmod | grep vboxsf
---- more omitted -----
Me
---
sudo modprobe vboxsf returns error:
ERROR: could not insert 'vboxsf': Protocol error
Chat
-----
The "Protocol error" with vboxsf typically points to mismatched kernel modules, guest additions, or permissions issues. Here’s how we can tackle it methodically:
Step-by-Step Resolution
1. Confirm Kernel and Module Versions are Aligned
Check your running kernel version:
bash
uname -r
Confirm virtualbox-guest-utils and linux-headers versions:
bash
pacman -Q | grep -E 'linux|virtualbox'
---- more omitted -----
Me
---
We need you to reduce the number of steps you output. Remember that I cannot copy error messages from the VM since that's part of the problem we are trying to fix. I have to transcribe them by hand.
In the pacman -Q step to check the headers, there appears to be a mismatch. Linux-headers is the right version but linux-api-headers is not.
Chat
-----
Got it! The mismatched linux-api-headers could be causing the issue. Here's a concise way to address it:
Fix Kernel Header Mismatch
Update and Synchronize Packages:
bash
sudo pacman -Syu
Reinstall API Headers to Match:
bash
sudo pacman -S linux-api-headers
Rebuild VirtualBox Guest Modules:
bash
sudo dkms autoinstall
sudo modprobe vboxsf
---- more omitted ----
Me
---
no command 'dkms'
Chat
-----
Arch-based systems don't include dkms by default. Let's try this without dkms:
Fix Mismatch and Rebuild Modules Without DKMS
Ensure All Packages are Up-to-Date:
bash
sudo pacman -Syu
Reinstall VirtualBox Guest Utilities and Headers:
bash
sudo pacman -S virtualbox-guest-utils virtualbox-guest-modules-arch linux-h
---- more omitted ----
Me
---
at step 2: nothing needed to be reinstalled, and:
target not found: virtualbox-guest-modules-arch
Chat
-----
Thanks for your patience! It seems Arch has slightly different ways of handling VirtualBox modules. Let’s proceed with the correct steps:
1. Install Required VirtualBox Modules
Since virtualbox-guest-modules-arch isn’t available, let’s install the appropriate packages:
bash
sudo pacman -S virtualbox-guest-utils linux-headers
---- more omitted -----
Me
----
sudo modprobe vboxsf returned the same "Protocol error" message as before.
Chat
-----
Since the Protocol error persists, the issue likely lies with the vboxsf module itself, possibly due to a version mismatch or incomplete installation. Let's try a few key targeted steps:
--- more omitted ----
Me
---
the dmesg output produced some interesting lines:
vboxguest: loading out-of-tre module taints kernel.
vboxguest: module verification failed: sigmature and/or key misssing - tained module
vboxguest: Successfully loaded version 7.0.20 r163906
The version that was "Successfully" loaded, 7.0.20, corresponds to the previous version of Virtual box, the one that I replaced today with the later one. I don't see how that could still be around to be loaded.
I think you have been flailing around to much, and that we have to find a way to zero in on the key problem. I'm thinking that there is a bug in this new release of VirtualBox, and I'm thinking of trying to downgrade if possible. Note that I have already uninstalled and reinstalled Virtualbox on the Windows host. Comments or suggestions? Let's stay focused on a few simple steps or ideas.
Chat
-----
You're absolutely right—let's focus and zero in on the core issue: mismatched or leftover guest modules from the previous version.
It looks like the old 7.0.20 guest module is still being loaded, which conflicts with the newer host VirtualBox version. This mismatch could explain the errors and Protocol error with vboxsf.
---- [note: this seems to have been the real problem] ----
---- more omitted ---
This should eliminate the version conflict. Let me know how it goes!
Me
---
You said:
Because I can't copy them out of the VM, I could only transcribe a few lines. I will repeat them:
vboxguest: loading out-of-tre module taints kernel.
vboxguest: module verification failed: sigmature and/or key misssing - tained module
vboxguest: Successfully loaded version 7.0.20 r163906
Chat
-----
Thanks for the clarification. Based on those messages, here's the issue:
Out-of-tree module: The old version (7.0.20) is being loaded, which "taints" the kernel (i.e., it's not part of the official kernel tree or its key is missing).
Module verification failed: This suggests that the wrong or outdated VirtualBox guest module (vboxguest) is still present on the VM.
The problem is that leftover 7.0.20 modules are interfering with the proper loading of 7.1.x modules. Let’s focus on fully removing the old version and ensuring only the latest one is loaded.
Focused Fix: Remove Old Modules and Install New Guest Additions
Step 1: Identify and Remove Old VirtualBox Modules
Check for VirtualBox-related modules:
bash
lsmod | grep vbox
---- more omitted ----
Let me know if this resolves the issue or if anything unexpected happens along the way.
Me
---
wait. I don't read it that way. I read it that the new version (7.1.2) is out-of-tree or has an missing signature, and that the old version (7.0.20) somehow gets loaded. Note that the 7.0.20 guest additions worked when Virtualbox was also at version 7.0.20. comment.
Chat
-----
You're absolutely correct—this points to a mismatch between the new guest additions (7.1.x) and the modules that are actually getting loaded (7.0.20). The key is that 7.0.20 modules are being loaded despite the attempt to install 7.1.x additions.
This could happen if:
Old modules were not properly removed when upgrading.
Kernel module paths are not updated.
7.1.x guest additions installation failed silently, leaving the old 7.0.20 modules active.
---- more omitted -----
Me
----
I want you to generate fewer code steps. you have been success-oriented but each step has resulted in failure. In this case, in step 1 modinfo only reported the current version, 7.1.2. the find command reported two hits, one for vboxguest.ko and one for vboxguest.ko.zst. comments, please.
Chat
-----
Good observations! Here’s what this tells us:
modinfo reporting version 7.1.2:
This suggests that the correct guest module is present and recognized, but it's not functioning as expected—possibly due to conflicting remnants or a mismatch between modules and the running kernel.
find reporting vboxguest.ko and vboxguest.ko.zst:
vboxguest.ko: The decompressed module likely in use.
vboxguest.ko.zst: A compressed version of the same module.
This result means that old modules (like 7.0.20) are likely gone, but we still see behavior consistent with a version conflict—which points to:
Kernel taint or signature issues from the dmesg log.
Possible failure during the kernel module build when installing the guest additions.
--- more omitted ----
Me
---
This procedure succeeded. I'm a little puzzled as to why since rcboxadd had been run previously without fixing the problem. I suppose that we had cleaned the system of undesired package fragments in our earlier efforts.
Chat
-----
Exactly! The earlier cleanup steps likely resolved leftover inconsistencies—like outdated modules or configuration mismatches—that were interfering with the rebuild.
When rcvboxadd setup was run this time, it could finally perform a clean build without conflicting artifacts from the previous version (7.0.20). Earlier attempts probably failed silently due to those remnants.
In summary:
Removing old modules and files was critical.
The rebuild command needed a clean slate to work correctly.
Glad to hear it's resolved! Let me know if anything else comes up.
=========== End of transcript ==========
In the future I will know to be sensitive to kernel updates and mismatches if (more likely when) it happens again. Someone who knows a lot more about Linux and these various commands could probably have tracked this down much faster, but I'm not that person.
This session took quite a while and required patience and guidance on my part, but in the end I didn't have to reinstall the OS and reconfigure everything. To me this was a good outcome. I also learned some useful things.
A few days ago I had a serious problem with one of my Linux virtual machines. I upgraded the VirtualBox software and rebuilt the guest additions, but now I couldn't use the bidirectional clipboard or mount the shared folder. The shared folder is a folder on the host (Windows 10) drive that can be read and written to by the VM. The bidirectional clipboard means that the WIndows' clipboard can be shared by the VM (and any other VMs configured with it). With the clipboard, I could copy code snippets to the VM and insert Leo nodes that O copied form Leos on Windows. Without those two features, the VM is isolated.
With the VB community edition, you have to install the "Guest Additions" on the guest VM to get those features to work. This is routine and I've done it dozens of times. But now they didn't work.
I'm going to share the transcript of my session with ChatGPT that ended up with me solving the problem. I'm only going to show you the first bit of each response because typically it would spit out a lot of steps to follow, but the first step or two wouldn't work. In the end, an update to the guest VM had updated the Linux kernel but somehow the guest additions apparently was trying to install the older version. To confuse matters, the Distro also includes some version of the GA and which one is being updated and installed?
At the beginning I give Chat the ground rules. They are important.
Me
-----
This session is about running a linux virtualbox VM guest on a windows 10 host. I am fairly experienced in creating and running virtualbox VMs. You will respond as an expert in virtualbox operations and you will be concise.
I have a arch-based VM that has been in use for some time. I upgraded Virtualbox to the newest version, 7.1.x, installed the extension pack as an admin, and ran the VM. I installed the guest additions apparently successfully and rebooted the VM. Now each time I log on I get a notification that the VBox kernel client service is not running. Without working guest additions, bidirectional cut and paste do not work and I cannot access shared directories with the host.
What I have tried: reboots, uninstall/reinstall guest additions, and uninstall/reinstall the virtualbox software on the Windows host. Do you have any suggestions for restoring normal operations in the VM?
Chat
----
Yes! This issue often happens due to mismatches or missing kernel modules. Below are steps to restore normal operations in your Arch-based VM.
1. Confirm Kernel Module Compatibility
Ensure that the guest additions kernel modules match your Arch kernel version.
Inside the VM, run:
bash
uname -r
pacman -Qs virtualbox
Check that the installed VirtualBox Guest modules (virtualbox-guest-utils or similar) are compatible with the displayed kernel version.
---- much more omitted ---
Me
----
At step two:
modeprobe: ERROR: could not insert 'vboxsf': Protocol error
Chat
-----
The "Protocol error" indicates a problem with the vboxsf kernel module, usually caused by mismatches between the VirtualBox version, guest additions, or kernel modules. Let's address it step-by-step.
Steps to Resolve the vboxsf Protocol Error
---- more omitted -----
Me
---
Up through step 4, no change. systemctl status vboxservice has two lines that are possibly relevant. The error messages are:
1. VBoxDRMClient: already running, exiting
2. automount failed because it couldn't find the mount point for the shared directory in /media. However, the mount point exists. Its owner and group are root, so I assume we have a permissions problem here. Not that I, the user, are already a member of the vboxsf group.
Chat
---
Thank you for the details! Let’s break down the two issues and solve them:
Issue 1: VBoxDRMClient: already running, exiting
This warning suggests that the DRM client is already active. It’s usually benign and doesn’t affect shared folders, but we can ensure it’s not interfering.
Solution: Restart the vboxservice to ensure everything is clean:
bash
sudo systemctl restart vboxservice
sudo systemctl status vboxservice
If the warning persists but everything else works, it can be safely ignored since it’s not likely related to your shared folder issue.
---- more omitted -----
Me
---
step 2 failed to mount with a message "no such device". ls -id permissions look right: drwxrwx---
Chat
-----
The "no such device" error suggests that the vboxsf kernel module is either not loaded properly or incompatible with your setup. Let’s address this step-by-step.
Steps to Resolve the "No Such Device" Error
1. Verify if vboxsf Module is Loaded
Check if the vboxsf module is present:
bash
lsmod | grep vboxsf
---- more omitted -----
Me
---
sudo modprobe vboxsf returns error:
ERROR: could not insert 'vboxsf': Protocol error
Chat
-----
The "Protocol error" with vboxsf typically points to mismatched kernel modules, guest additions, or permissions issues. Here’s how we can tackle it methodically:
Step-by-Step Resolution
1. Confirm Kernel and Module Versions are Aligned
Check your running kernel version:
bash
uname -r
Confirm virtualbox-guest-utils and linux-headers versions:
bash
pacman -Q | grep -E 'linux|virtualbox'
---- more omitted -----
Me
---
We need you to reduce the number of steps you output. Remember that I cannot copy error messages from the VM since that's part of the problem we are trying to fix. I have to transcribe them by hand.
In the pacman -Q step to check the headers, there appears to be a mismatch. Linux-headers is the right version but linux-api-headers is not.
Chat
-----
Got it! The mismatched linux-api-headers could be causing the issue. Here's a concise way to address it:
Fix Kernel Header Mismatch
Update and Synchronize Packages:
bash
sudo pacman -Syu
Reinstall API Headers to Match:
bash
sudo pacman -S linux-api-headers
Rebuild VirtualBox Guest Modules:
bash
sudo dkms autoinstall
sudo modprobe vboxsf
---- more omitted ----
Me
---
no command 'dkms'
Chat
-----
Arch-based systems don't include dkms by default. Let's try this without dkms:
Fix Mismatch and Rebuild Modules Without DKMS
Ensure All Packages are Up-to-Date:
bash
sudo pacman -Syu
Reinstall VirtualBox Guest Utilities and Headers:
bash
sudo pacman -S virtualbox-guest-utils virtualbox-guest-modules-arch linux-h
---- more omitted ----
Me
---
at step 2: nothing needed to be reinstalled, and:
target not found: virtualbox-guest-modules-arch
Chat
-----
Thanks for your patience! It seems Arch has slightly different ways of handling VirtualBox modules. Let’s proceed with the correct steps:
1. Install Required VirtualBox Modules
Since virtualbox-guest-modules-arch isn’t available, let’s install the appropriate packages:
bash
sudo pacman -S virtualbox-guest-utils linux-headers
---- more omitted -----
Me
----
sudo modprobe vboxsf returned the same "Protocol error" message as before.
Chat
-----
Since the Protocol error persists, the issue likely lies with the vboxsf module itself, possibly due to a version mismatch or incomplete installation. Let's try a few key targeted steps:
--- more omitted ----
Me
---
the dmesg output produced some interesting lines:
vboxguest: loading out-of-tre module taints kernel.
vboxguest: module verification failed: sigmature and/or key misssing - tained module
vboxguest: Successfully loaded version 7.0.20 r163906
The version that was "Successfully" loaded, 7.0.20, corresponds to the previous version of Virtual box, the one that I replaced today with the later one. I don't see how that could still be around to be loaded.
I think you have been flailing around to much, and that we have to find a way to zero in on the key problem. I'm thinking that there is a bug in this new release of VirtualBox, and I'm thinking of trying to downgrade if possible. Note that I have already uninstalled and reinstalled Virtualbox on the Windows host. Comments or suggestions? Let's stay focused on a few simple steps or ideas.
Chat
-----
You're absolutely right—let's focus and zero in on the core issue: mismatched or leftover guest modules from the previous version.
It looks like the old 7.0.20 guest module is still being loaded, which conflicts with the newer host VirtualBox version. This mismatch could explain the errors and Protocol error with vboxsf.
---- [note: this seems to have been the real problem] ----
---- more omitted ---
This should eliminate the version conflict. Let me know how it goes!
Me
---
You said:
Because I can't copy them out of the VM, I could only transcribe a few lines. I will repeat them:
vboxguest: loading out-of-tre module taints kernel.
vboxguest: module verification failed: sigmature and/or key misssing - tained module
vboxguest: Successfully loaded version 7.0.20 r163906
Chat
-----
Thanks for the clarification. Based on those messages, here's the issue:
Out-of-tree module: The old version (7.0.20) is being loaded, which "taints" the kernel (i.e., it's not part of the official kernel tree or its key is missing).
Module verification failed: This suggests that the wrong or outdated VirtualBox guest module (vboxguest) is still present on the VM.
The problem is that leftover 7.0.20 modules are interfering with the proper loading of 7.1.x modules. Let’s focus on fully removing the old version and ensuring only the latest one is loaded.
Focused Fix: Remove Old Modules and Install New Guest Additions
Step 1: Identify and Remove Old VirtualBox Modules
Check for VirtualBox-related modules:
bash
lsmod | grep vbox
---- more omitted ----
Let me know if this resolves the issue or if anything unexpected happens along the way.
Me
---
wait. I don't read it that way. I read it that the new version (7.1.2) is out-of-tree or has an missing signature, and that the old version (7.0.20) somehow gets loaded. Note that the 7.0.20 guest additions worked when Virtualbox was also at version 7.0.20. comment.
Chat
-----
You're absolutely correct—this points to a mismatch between the new guest additions (7.1.x) and the modules that are actually getting loaded (7.0.20). The key is that 7.0.20 modules are being loaded despite the attempt to install 7.1.x additions.
This could happen if:
Old modules were not properly removed when upgrading.
Kernel module paths are not updated.
7.1.x guest additions installation failed silently, leaving the old 7.0.20 modules active.
---- more omitted -----
Me
----
I want you to generate fewer code steps. you have been success-oriented but each step has resulted in failure. In this case, in step 1 modinfo only reported the current version, 7.1.2. the find command reported two hits, one for vboxguest.ko and one for vboxguest.ko.zst. comments, please.
Chat
-----
Good observations! Here’s what this tells us:
modinfo reporting version 7.1.2:
This suggests that the correct guest module is present and recognized, but it's not functioning as expected—possibly due to conflicting remnants or a mismatch between modules and the running kernel.
find reporting vboxguest.ko and vboxguest.ko.zst:
vboxguest.ko: The decompressed module likely in use.
vboxguest.ko.zst: A compressed version of the same module.
This result means that old modules (like 7.0.20) are likely gone, but we still see behavior consistent with a version conflict—which points to:
Kernel taint or signature issues from the dmesg log.
Possible failure during the kernel module build when installing the guest additions.
--- more omitted ----
Me
---
This procedure succeeded. I'm a little puzzled as to why since rcboxadd had been run previously without fixing the problem. I suppose that we had cleaned the system of undesired package fragments in our earlier efforts.
Chat
-----
Exactly! The earlier cleanup steps likely resolved leftover inconsistencies—like outdated modules or configuration mismatches—that were interfering with the rebuild.
When rcvboxadd setup was run this time, it could finally perform a clean build without conflicting artifacts from the previous version (7.0.20). Earlier attempts probably failed silently due to those remnants.
In summary:
Removing old modules and files was critical.
The rebuild command needed a clean slate to work correctly.
Glad to hear it's resolved! Let me know if anything else comes up.
=========== End of transcript ==========
In the future I will know to be sensitive to kernel updates and mismatches if (more likely when) it happens again. Someone who knows a lot more about Linux and these various commands could probably have tracked this down much faster, but I'm not that person.
This session took quite a while and required patience and guidance on my part, but in the end I didn't have to reinstall the OS and reconfigure everything. To me this was a good outcome. I also learned some useful things.
Edward K. Ream
Oct 22, 2024, 4:19:07 AM10/22/24
to leo-e...@googlegroups.com
On Mon, Oct 21, 2024 at 11:07 PM Thomas Passin <tbp1...@gmail.com> wrote:
I've been trying to use ChatGPT to get help on actual problems...
Impressive transcript!
Hehe, now can you get back to finishing Leo's layouts?
Edward
Thomas Passin
Oct 22, 2024, 8:28:10 AM10/22/24
to leo-editor
There's a PR waiting to be accepted. Once it's merged there will be another one and then I think we'll be there.
Thomas Passin
Oct 22, 2024, 9:48:32 AM10/22/24
to leo-editor
Hah! I see it's been done. Good!
Edward K. Ream
Oct 22, 2024, 10:00:02 AM10/22/24
to leo-e...@googlegroups.com
On Tue, Oct 22, 2024 at 8:48 AM Thomas Passin <tbp1...@gmail.com> wrote:
Hah! I see it's been done. Good!
Now I'm confused. What has been done? PR #4111 has not been merged, but I'll accept the PR once I'm a bit less confused.
Edward
Thomas Passin
Oct 22, 2024, 10:18:31 AM10/22/24
to leo-editor
I'm confused too. I didn't see mine listed on the GitHub PR tab so I thought it had bee merged. Then I updated with the current version of devel and my PR isn't there. [Later: I must have forgotten its name : ( I see it now.) Yes, that's the one I'm waiting on. After that, I'll create a new PR with the code to collect all the layout docstrings to support a help-for-layouts command, and then we should be good to go for 6.82.
Edward K. Ream
Oct 22, 2024, 11:15:23 AM10/22/24
to leo-e...@googlegroups.com
On Tue, Oct 22, 2024 at 9:18 AM Thomas Passin <tbp1...@gmail.com> wrote:
Yes, [PR #4111] the one I'm waiting on.
After that, I'll create a new PR with the code to collect all the layout docstrings to support a help-for-layouts command, and then we should be good to go for 6.8.2.
I've merged PR #4111, but testing reveals PR3 is active even if PR3 has not been enabled!
Thomas, please drop everything and fix this new issue, today if possible. I'm not happy.
Edward
Edward K. Ream
Oct 22, 2024, 11:28:46 AM10/22/24
to leo-e...@googlegroups.com
On Tue, Oct 22, 2024 at 10:15 AM Edward K. Ream <edre...@gmail.com> wrote:
> I've merged PR #4111, but testing reveals PR3 is active even if PR3 has not been enabled!
> Thomas, please drop everything and fix this new issue, today if possible. I'm not happy.
g.trace(g.callers()) from getVr3 gives this output:
getVr3 doCommand,restoreDefaultLayout,quadrants,restoreFromLayout
The culprit lies in the section << initialize data structures >>
Let me play around with the code and see what I can do. We may have to zoom about this.
Edward
--
-----------------------------------------------------------------
Edward K. Ream: edre...@gmail.com
Leo Editor: https://leo-editor.github.io/leo-editor/
-----------------------------------------------------------------Thomas Passin
Oct 22, 2024, 12:06:43 PM10/22/24
to leo-editor
I had to make sure it was active if a layout needed it (even if not visible) so it would open in the right slot in the layout. I put in a test for whether VR3 had been enabled or not, and changed the layout's slot name it it was/was not. That all worked, but maybe I made a mistake and didn't cover all cases or layouts. I will check right away.
Edward K. Ream
Oct 22, 2024, 12:08:40 PM10/22/24
to leo-e...@googlegroups.com
On Tue, Oct 22, 2024 at 11:06 AM Thomas Passin <tbp1...@gmail.com> wrote:
I had to make sure it was active if a layout needed it (even if not visible) so it would open in the right slot in the layout. I put in a test for whether VR3 had been enabled or not, and changed the layout's slot name it it was/was not. That all worked, but maybe I made a mistake and didn't cover all cases or layouts. I will check right away.
Reply all
Reply to author
Forward
0 new messages