VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1993 - 1995 of 16363)

Ticket Resolution Summary Owner Reporter
#16315 invalid Not working bridging with Intel Corporation Centrino Advanced-N 6205 thisiswhite
Description

VirtualBox any version doesn't support bridging with Intel Corporation Centrino Advanced-N 6205 (Wireless). I have confirmed this on all guest and all hosts. Im install last drivers for

#16314 fixed CentOS 6.x VirtualBox repo metadata does not match checksum esaumell
Description

Same as https://www.virtualbox.org/ticket/15363

Tried on different workstations after adding vbox repo but same result:

cd /etc/yum.repos.d
wget http://download.virtualbox.org/virtualbox/rpm/rhel/virtualbox.repo
yum update
Loaded plugins: fastestmirror, nvidia, refresh-packagekit, security
Setting up Update Process
Loading mirror speeds from cached hostfile
 * base: mirror.datomedia.es
 * elrepo: mirrors.evowise.com
 * epel: mirror.airenetworks.es
 * extras: mirror.airenetworks.es
 * rpmforge: mir01.syntis.net
 * updates: mirror.airenetworks.es
virtualbox/primary                                                                                                  |  16 kB     00:00
http://download.virtualbox.org/virtualbox/rpm/el/6/x86_64/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.xml.gz from virtualbox: [Errno 256] No more mirrors to try.

#16311 fixed VBoxManage modifyhd resize needs better parameter checking to prevent catastrophic data loss mpack
Description

Please see the topic

https://forums.virtualbox.org/viewtopic.php?f=7&t=81093

for an example of the type of problem I'm going to discuss, however somebody makes this dumb mistake several times a year.

Scenario: they want to resize their disk, so they glance at the docs and don't notice that the resize size is in MB, therefore they provide a new size in bytes, often a very large new size. Obviously they don't make a backup either.

VBoxManage will go right ahead and attempt to create a logical drive of the chosen size * 1024*1024. Often this will fail for lack of space. Worse is when they realize their mistake and interrupt the work in mid stream. In some cases the block map alone is so huge that it won't fit on the host partition, but in all cases the most likely scenario is that their VM will not boot, and the disk contents have been scrambled.

It seems to me that VBoxManage should be doing some basic sanity checks on the resize size. This could be fancy but possibly incorrect (disk logical size can't be larger than host partition), or arbitrary - max size for resize cannot be larger than X terabytes, possibly with X depending on guest OS type. I'm sure you could dream up something sensible. But, being that it's an in-place function it definitely needs a filter for user stupidity.

Speaking of which: yeah, telling the user he should have made a backup is always good, but in that case one might wonder what the value of an "in place" method is.

No logs, since it's a design suggestion, not a crash. I set the affected version to 5.1.0, but really it's all versions since 4.0.0 to the latest 5.1.12 release.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy