Virtual Box SAS storage controller allows faster IO than SATA one:
SAS is to SCSI what SATA is to IDE: it allows for more reliable and faster connections.
from https://www.virtualbox.org/manual/ch05.html
By default new VM is created with hard disk attached to SATA controller (at least for Windows VMs). In order to make IO operations faster in guest system, one might want to move a hard drive to SAS controller.
How to do that for Windows guest OS without breaking anything?
Here is my own solution which seem to work.
Prepare (this is required to make Windows install drivers for new controller, without them Windows will fail to boot).
Add SAS controller.
Attach new hard drive to the new SAS controller.
Boot your system, wait while drivers are installed/updated. Reboot. Power Off.
Now we are ready to relocate existing hard drive:
Attach existing hard drive to SAS controller.
Detach it from old controller.
Make sure that Solid-state drive checkbox is in the same state as it was before.
Again: boot your system, wait while drivers are installed/updated. Reboot.
NB: Don't forget to backup your important files before trying this.
You might want to enable Use Host IO Cache on SAS controller.
Related
For forensic imaging of drives and/or segments with a native Mac application, I'm booting from external device (usb, hdd, etc.) into BaseSystem. I want to keep the internal drives and/or segments unmounted during the boot process (there is no way of knowing drive/segment volume names and/or UUID before booting). Later will disable disk arbitration, mount these drives/segments and image them.
I've created a deamon (System/Library/LaunchDeamons) for mount blocking (on external boot device), but it only blocks newly attached devices, not internal ones.
Note 1: I've created boot image from BaseSystem.dmg of Sierra (10.12.1), and modified the contents.
Note 2: Since there is no way of knowing drive/segment volume names and/or UUID before booting, it is not possible to use fstab.
I need a direction to follow, any comment may help. Thanks.
Nobody, even commented. I found the solution from a clue keyword from a friend: autodiskmount
I work on-the-side doing computer repair. Standard operating procedure is to pop out the HDD/SSD, mount it to a backup machine, and pull the client's data (i.e., in case the drive fails/something goes horribly wrong, their data is protected). More and more often, my office is seeing SSDs soldered directly to the motherboard, making this technique impossible.
I was wondering if any of you knew of a some method that would allow direct disk access without drive removal. An analogue would be mounting a phone in Mass Storage Device mode, I suppose. This may be possible already by doing something with a Linux LiveUSB, but I'm not sure how. Booting from a LiveUSB and transferring files over the network is unacceptably slow given the volume of computers we see and amount of data involved.
On Apple computers, this is simple--plug in a Thunderbolt/Firewire connector and use Target Disk Mode to pull directly from the drive.
tl;dr: making a backup of a Windows computer without opening them: how do?
Boot a live Linux from a large USB3 HDD, and use the same disk to copy the client's data to with about USB3 speed.
I am creating an operating system, and am able to create a simple multitasking kernel (though the code has been lost) and an IDE/ATA PIO driver without BIOS interrupts. I wish to create a boot loader that puts the system into Protected Mode, disables paging, creates a flat memory model, and then does a long jump to the 0x0 offset of a file named OS.SYS in the root directory of a FAT32 formatted hard drive. I know how do do everything except for one thing: change the boot sector of the disk. I know how to format a hard drive as FAT32 to get the correct BPB and such at the beginning of the file, but I do not know how to copy over the code so that the BPB is not corrupted. Even in Linux when DD was available, I was unable to overcome this hurdle - I always used a custom file system. I am now seeing the disadvantages to this, though, such as not being able to use simple tools like file managers to move files around for testing.
Basically, to sum it up, I'm asking how to change the boot sector code on an already working FAT32 file system without messing up the BPB.
Note: I am using Windows 10 and NASM, and intend to use virtual hard disks with QEMU or Virtualbox.
I am developing an OSX application that among other things shows mounted volumes as they appear/disappear. I do that using the disk arbitration framework. When I connect my computer to a network drive that I have configured as my time machine backup then a volume appears with the name "timemachine", i.e. the CFDictionary of the appearing device is this:
{DAVolumeMountable=true, DAVolumeNetwork=true, DAVolumeName=timemachine, DAVolumePath=file://localhost/Volumes/timemachine/, DAVolumeKind=afpfs}
I don't want this volume to appear in my application's UI. What criterion can I use to know it is really a time machine volume to exclude it? Just using the name or path seems weird. Wouldn't a drive formatted to have the name "timemachine" theoretically be mounted under the same name/path?
Any advice appreciated.
I don't find an API that identifies Time Machine volumes. You could call out to the tmutil program with the destinationinfo verb. I also see files such as ".com.apple.timemachine.donotpresent" on my Time Machine volume, although that's relying on undocumented implementation details.
By the way, a Time Machine volume can still be used as normal by the user. At least a local one can. They can browse into it and put other files on it besides their backup. Obviously, they shouldn't put anything there that they would be sorry to lose if a drive fails.
If you only want to show the same volumes as are present in the Finder, I would recommend using NSWorkspace and its NSWorkspaceDidMountNotification and NSWorkspaceWillUnmountNotification notifications to learn when volumes are mounted and unmounted. Use -[NSFileManager mountedVolumeURLsIncludingResourceValuesForKeys:options:] with NSVolumeEnumerationSkipHiddenVolumes. You might want to use -getResourceValue:forKey:error: with NSURLVolumeIsBrowsableKey, too, since I'm not sure that non-browsable is synonymous with hidden.
I need to modify the MBR of Windows, and I would really like to do this from Windows.
Here are my questions. I know that I can get a handle on a physical device with a call to CreateFile. Will the MBR always be on \\.\PHYSICALDRIVE0? Also, I'm still learning the Windows API to read directly from the disk. Is readabsolutesectors and writeabsolutesectdors the two functions I'm going to need to use to read/write to the disk sectors which contain the MBR?
Edit from from what I've learned on my own.
The MBR will not always be on \\.\PHYSICALDRIVE0. Also, you can write to the bootsector (at least as Administrator on XP) by call CreateFile with the device name of the drive that contains the MBR. Also, you can write to this drive by simply calling WriteFile and passing the handle of the device created by calling CreateFile.
Edit to address Joel Coehoorn.
I need to edit the MBR because I'm working on a project that needs to modify hardware registers after POST in BIOS, but before Windows will be allowed to boot. Our plan is to make these changes by modifying the bootloader to execute our code before Windows boots up.
Edit for Cd-MaN.
Thanks for the info. There isn't anything in your answer, though, that I didn't know and your answer doesn't address my question. The registry in particular absolutely will not do what we need for multiple reasons. The big reason being that Windows is the highest layer among multiple software layers that will be running with our product. These changes need to occur even before the lower levels run, and so the registry won't work.
P.S. for Cd-MaN.
As I understand it, the information you give isn't quite correct. For Vista, I think you can write to a volume if the sectors being written to are boot sectors. See http://support.microsoft.com/kb/942448
Once the OS is started the MBR is typically protected for virus reasons - this is one of the oldest virus tricks in the books - goes back to passing viruses from floppy to floppy.
Even if it wasn't restricted, you have to write low level code - it isn't part of the file system, but exists on a specific location on the hard drive.
Due to that, you pretty much are restricted to writing low level (most programs implement this in assembly) or C code targeting 16 bit DOS.
Most of these programs use the BIOS interface (13h, I believe) to access the sectors of the disk directly. You can access these in C using some inline assembly, or compiler provided interfaces. You will generally not get access to BIOS without the cooperation of the OS, though, so your program, again, will be restricted to DOS. If you can access these you're almost home free - the nice thing about BIOS is you don't have to worry about what type of HD is in the system - even RAID cards often insert themselves into the BIOS routines so they can be accessed without knowing where in memory the ATA or SATA controller is, and executing commands on that low level.
If you absolutely must access it within an OS, though, you pretty much have to write a device driver to access the BIOS or the memory space where the HD controllers exist. I wouldn't recommend it, though, as this is very tricky to deal with - modern computers put the HD controllers in different spots in memory, with different IRQs, and each chipset has become a little more esoteric because they can provide a minimum interface to bios for bootup, and then a specific driver for Windows. They skip all the other interface niceties that would be considered compatible with other controllers because it's more expensive to be compatible.
You may find that at the driver level inside windows you'll have methods for accessing the drive sectors directly (or pseudo directly), but again, they are likely very well protected due to the aforementioned virus issues.
Good luck!
Modifying the bootloader is bad, bad idea. Here are just a few of the possible gotcha's:
it will potentially kill full disk encryption products (Truecrypt, PGP, Vista's BitLocker, etc)
it will potentially trip up AV products (scaring users)
it will potentially kill complicated booting scenarios (chained boot loaders, etc)
it will kill off the chain of trust when using the TPM module (because it checks the MBR for change before executing it)
direct disk access is not allowed starting from Vista (only using drivers)
Alternatives (like modifying the hardware register during the Windows bootup via a driver which is set to load at boot time or after Windows has booted) should really be considered. If the modification is as simple as writing to a port, ie:
OUT AX, BL
then drivers exists for all versions of Window which can do this (reading/writing a value from/to a certain port) which can be called from user mode.
Maybe a PXE boot scenario could help you? Simply boot on your crafted PXE image which modify the hardware registers you need to modify, and then return the control to the Master Boot Record or to the active partition's boot record.
This way you don't have to modify the boot records.