Custom Query (16363 matches)
Results (769 - 771 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1310 | fixed | Support running systems with "hardware" clock on UTC => Fixed in SVN | ||
| Description |
As you probably know, linux mostly runs on systems with the hardware clock set to UTC; the timezone setting will correct that time to the correct local time. VirtualBox currently always takes the local time of the host system as its hardware clock, which means that when I use VirtualBox for my Debian linux installation tests, I always end up with the clock set wrong as the Debian installer sets the system clock to UTC during the installation if no other operating systems such as Windows are detected. However, when the virtual machine is restarted, it gets set back to local time. It would be great to have a per-machine config setting that lets the user choose between having the "hardware" clock of the virtual system in local time or in UTC (based on the host system's local time + its timezone setting). TIA, Frans Pop |
|||
| #1311 | fixed | Shared folders: Strange behaviour | ||
| Description |
Hello, I'm using a Fedora 7 as Host and a WinXP as Guest-system. I've defined 3 different shared folders (WORK, PRIVATE, GENERAL), which I want to access in XP as network drives. It should look like this: X: => WORK Y: => PRIVATE Z: => GENERAL All the virtual drives have now the same name (WORK), and I cannot change it inside Windows. Inside the command-prompt from windows they all have the same drive serial number. I still can access the different folders correctly, but they all have the same name... So that's a little bit confusing. suiyuan |
|||
| #1312 | fixed | kmk fails on zfs | ||
| Description |
You cannot build virtualbox on solaris in a zfs filesystem because kmk will fail attempting to create directories with its builtin mkdir. Apparently, kmk's logic for directory existence is... less than optimal - it seems to try creating directories from /, whether or not they exist (unlike mkdir which tries to create the leaf dir and fails upward). The problem happens when it reaches a ZFS mountpoint, where mkdir(2) will return ENOSYS, instead of its expect EEXIST, causing kmk to bail out. Only workaround is to build on a ufs filesystem, as kmk will do mkdirs whether or not the target exists. |
|||

