Custom Query (16363 matches)
Results (1507 - 1509 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #11344 | fixed | Extending VDI size destroys XFS filesystem => fixed in svn | ||
| Description |
Hello, after resizing a VDI image, while the VM was offline, from 1TB to 1.3TB, the XFS filesystem inside has been destroyed. I talked to Eric Sandeen, from the XFS people, and we ran some tests and in the end the filesystem will always be destroyed. We're testing on 4.2.4 and 4.2.6 on Linux (amd64) and OS X (10.8.x) hosts with this procedure:
So far we can't say if it is a Virtualbox or an XFS issue or a result of the combination of the two. We tested with different image sizes and always got a destroyed filesystem in the end. Eric will look into this and keep me updated on it. So far just the warning: DO NOT RESIZE the Virtualbox VDI image if you have XFS inside it. Happy new year! KR, Grimeton |
|||
| #11481 | duplicate | Weird behaviour | ||
| Description |
Hello, I know the topic isn't very clear, but that's what this whole thing is: Sometimes processes in the guest are producing segfaults or exit without any reasons and fail. I can see this on Linux and on OS X hosts. Windows XP (guest) is sometimes affected, Windows 7 (guest) doesn't make it past the Windows Update installs without having the update service killed multiple times. It sometimes even produces a blue screen when you activate the guest (Windows license activation). The main reason I didn't report the problem earlier was that I am unable to reproduce it. A few days ago someone else reported similar behaviour of his VMs on a Windows 7 Host, which could be solved by the same procedure I'm going to write about later, so I decided to file a bug report. What happens is that the processes inside the guests fail. If you power the guest down and start it again (no reboot, new instance of Virtualbox), you still get the same error inside the guest. The only way around it, ist to power down the "broken" guest, start another VM, so that it allocates memory on the host, and then start the guest again (while the other VM is still running). After doing this, the guest starts to work properly again, as it now uses a different part of the host's memory (afaik). In Windows 7 the update service fails, or .NET assemblies stop working from one second to another. On Linux guest you get all kinds of segfaults in all processes. Interesting is that you don't get a kernel core dump, all processes reside in user land. It's also independent of the memory the guest can use. I see it from machines with less than 256mb of Memory and up to 8GB and more of Memory. The memory on my machines has been checked and everything is fine. I'm sorry that I don't have any further information. If you have questions feel free to contact me. Attachements: IRC log of #vbox KR, Oliver |
|||
| #12779 | worksforme | BLKCACHE_IOERR on Fedora Linux F20 3.13.5-200.fc20.x86_64 | ||
| Description |
Dear sirs, after upgrading to 3.13.5-200.fc20.x86_64 i ran into problems with my USP3 mounted SSD drive. This did not happened before, so it should be a problem with the recent kernel update. [configuration]: Host: Fedora Linux F20 VM: Windows 7 with
Before you ask: why this configuration: The portable ssd device contains my development environment, that i share between home and my office. It worked good before the recent kernel update. After some time, i'll get a:
There is enough disk space on all devives (approx 16 to 30% usage). |
|||

