Custom Query (16363 matches)
Results (67 - 69 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #19130 | obsolete | screen resolution not restored at boot | ||
| Description |
Not sure if this is a vbox bug or artix bug, but maybe this can help determine which. After setting the screen resolution and rebooting, the screen comes up looking like
You can see the screen resolution really is set correctly:
The Guest Additions are up-to-date:
The firefox browser can be viewed by dragging it around into the viewable area, and you can see that I was able to snapshot the monitor configuration program as well as a terminal, so the system seems to be working correctly outside of the graphics.
Please note that I disabled 3D thinking that might help, but it didn't. Video has the full 128MB. There is enough memory I think: I admit this could be an issue with the particular configuration of this distro, which is artix, an arch-based distro without systemd. This is a recent issue that has only started NOTICING since the last GAs and/or the last repo updates -- I really don't know which might be contributing because I generally leave my VMs running for weeks at a time, unless there is some reason to restart them. I know I did not see this problem prior to this. Other VMs have experienced problems in the same period, but they are of a different nature. In one case, I had to switch display managers from slim to lightdm because slim was experiencing long delays; again, that could well be a different issue. Host is Devuan Ascii, with the latest updates applied. Thank you for your POLITE responses. Please let me know if you need more information. I also realize that a maintenance update will probably be along in the next few weeks or so. Perhaps those will clear up my current issue. |
|||
| #18724 | fixed | VBox 5.2.x: VBoxManage copyto --target-directory now requires an ending slash for guests => fixed in 5.2.x x>32 | ||
| Description |
The "VBoxManage copyto" destination directory given to "--target-directory" for a Windows guest now requires an ending slash. I assume this is not an intentional change. The error message when leaving out the ending slash in the destination "C:/tmp" is VBoxManage: error: File copy failed VBoxManage: error: Copying file "/tmp/foo" to guest failed: VERR_ACCESS_DENIED VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component GuestSessionWrap, interface IGuestSession VBoxManage: error: Context: "int gctlCopyFileToDest(COPYCONTEXT*, const char*, const char*, gctlCopyFlags)" at line 2176 of file VBoxManageGuestCtrl.cpp VBoxManage: error: Copying file "/tmp/foo" to guest failed: VERR_ACCESS_DENIED. VBoxManage: error: Error processing "/tmp/foo", rc=VERR_GENERAL_FAILURE |
|||
| #18737 | fixed | Linux guests: open(filename, O_CREAT|..., mode) fails inside shared folder => fixed in SVN/6.0.x x>10 | ||
| Description |
The following C code produces a simple executable which will attempt to create and open a read only test file in a single operation. Expected behaviour when run:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
int main() {
int fd = open("test.txt", O_CREAT | O_EXCL | O_RDWR, 0444);
if (fd < 0) {
perror("Could not create file: ");
return -fd;
}
return 0;
}
When run on other file systems this works correctly but when run on a virtualbox shared folder the file is created correctly but the program exits with the error message: Could not create file: : Permission denied This can be bypassed by running the command with sudo, in which case it succeeds normally. This is not a purely hypothetical problem, since the same error occurs when attempting to use any programme that makes this system call, such as a git clone. |
|||

