"Aborted-info file write error message" while using Guymager

[Tammi Kim]

Hi! I am using BitCurator 1.5.12 on a Mac mini and I ran into an error while I was trying to create a disk image of an external hard drive. The hard drive is 1 TB but only contains about 550 GB of data. I started running Guymager earlier today to create the disk image and noticed just this afternoon that it had stopped with the message "Aborted-info file write error message." Any idea what this means and what I can possibly do so I can use Guymager to create the disk image?

Thanks!

Tammki

[Cal Lee]

You can't write an image of a 1-Terabyte drive onto a virtual drive
that's only 275 Gigabytes. Assuming you have a drive on the host
machine that's big enough, you'll need to increase the storage that
VirtualBox allocates to the virtual drive. However, it's possible that
the Mac Mini (serving as the host) has only 500 GB of storage, in which
case you'll need to write the disk image to a larger drive.

- Cal

> --

[Kari R Smith]

Hi Tammi,

 

Even though there is only 550 of data on the 1TB external hard drive, by definition the disk image will be 1TB large.  It creates an image of the entire disk sectors whether or not they are written to.  So the size you need is greater than 1tb.

 

Kari Smith

--
You received this message because you are subscribed to the Google Groups "BitCurator Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-use...@googlegroups.com.
To post to this group, send email to bitcurat...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/277e4ae1-9fca-4ad7-a559-590f42da11ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tammi Kim]

Thanks everyone for your help! 

--
You received this message because you are subscribed to a topic in the Google Groups "BitCurator Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcurator-users/jyZaLpXv0cE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcurator-use...@googlegroups.com.

To post to this group, send email to bitcurat...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/29F559819ACA9A4FBF208407D4B63ABBD34DB751%40OC11EXPO32.exchange.mit.edu.

For more options, visit https://groups.google.com/d/optout.

--

Tammi Kim

http://www.tammiyk.org/

[jacqueli...@ptsem.edu]

Tammi, Cal, Kari, et al,

I receive the same message when I try to create a disk image of a 32 GB USB drive, when it's plugged into a Tableau T8-R2 write blocker. The same USB drive finishes and verifies just fine when not going through the write blocker. (I'm using expendable test files.) 

I followed mfgr instructions for installing the write blocker. What steps have I missed?

Thanks,
Jackie Rider

[Jarrett Drake]

Hi Jackie,

Please accept my apologies if I misinterpret your question, but we don't use a USB hardware write blocker while imaging* in BitCurator because the system, by default, mounts all connected devices as read-only, so it serves as a software write blocker. Of course, this default behavior can be modified, but I would argue that a hardware write blocker doesn't add anything different than the BC environment already provides.

Sorry that this answer doesn't clarify the issue! Maybe others with a setup similar to yours can weigh in?

Best,

Jarrett

*One of the workstations in our setup is a FRED, which has an internal tableau hardware write blocker. In our use case, though, we rarely (ever?) connect external media we plan to image to the FRED. Our imaging in BitCurator happens on laptops with no hardware write blocker.

--

You received this message because you are subscribed to the Google Groups "BitCurator Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-use...@googlegroups.com.
To post to this group, send email to bitcurat...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/d7f1dc4b-18e3-4e0e-9dbf-3399f5551986%40googlegroups.com.

[jacqueli...@ptsem.edu]

Hi Jarrett,

That clarifies the issue beautifully. An external write blocker is unnecessary with BitCurator. (I had been wondering about seeming redundancies in some workflows I've consulted.)

Thanks,

Jackie

[Matthew Disregardmatthew Farrell]

I suppose I could be mistaken, but I would still use a hardware write-blocker wherever possible (though it sounds like that may not be possible in this situation). My understanding is that they are more reliable than software write-blockers, and that the software blocker in BitCurator was added as an layer in addition, as opposed to outright replacement, to hardware blockers. I don't, unfortunately, have a recent comparison of hardware and software write-blockers at my fingertips so my information may be outdated.

best,

farrell

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/20f96f47-aa38-49cc-8123-0f21230b4a2a%40googlegroups.com.

[Jarrett Drake]

I can't speak to the intent of software write blocker in BC, but to the best of my technological understanding (which is limited), it communicates a set of algorithmic instructions to the computer that all mounted devices are read-only by default. A hardware write blocker, I would imagine, also delivers a similar set of instructions and doesn't do anything in the way of physically preventing data from being written back (which is the case with some floppy disks with the tab). Seen this way, I would imagine the software and hardware write blockers have the same level of reliability, insomuch as they just pass a set of instructions to the computer. I'd be curious to hear from others, though!

Jarrett

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/CAFjbN_sVusOkztyw_rK2dW-_WBA8%2BzZognz8_DB1xW4NsBBAhw%40mail.gmail.com.

[Porter Olsen]

There are actually more technical nuances between hardware and software write blocking, but I'll leave those for Kam to explain. :)

As a practical matter there are two cases I can think of where hardware write blocking is superior to software write blocking. The first is if you are using BitCurator as a virtual machine. When you have the BitCurator virtual machine up and running and connect a USB drive (hard drive, flash drive, whatever) to the computer, the VirtualBox driver intercedes and passes the device directly to the VM, ensuring that nothing gets written to the drive because BitCurator mounts all devices read only by default. However, if you have a USB device connected to BitCurator and the VM crashed for whatever reason, then the host operating system will immediately see the USB device and mount it for you, sans write protection of any kind. You can guard against this by disabling automount in Windows by opening a terminal and entering the command "mountvol /N". However, there is no easy way to disable automount in OS X because, well, because of course there isn't.

The second thing to keep in mind with software write blocking is that it only applies to mounted volumes. It is still possible to write to a connected device as a block device, effectively circumventing the file system all together. This can only be done by applications with root privileges, so it's hard to do by accident. However, Guymager runs as root so there's at least one tool in the BItCurator box that can circumvent software write protection. I had someone at a workshop try to write a disk image to the disk they were imaging by telling Guymager to capture an image of the mounted device and write it to the block device. Obviously it didn't work, but Guymager would have happily written to the block device for as long as we would have let it.

Best,

Porter

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/CAOQCh2vWAHJ4ZUV3%2Bb632ORWMivprhXfx79bGJ-3gvRGD3CGrQ%40mail.gmail.com.

[Cal Lee]

On 12/17/2015 4:45 PM, Porter Olsen wrote:
> There are actually more technical nuances between hardware and software
> write blocking, but I'll leave those for Kam to explain. :)

Hardware-based write-blocking is always more reliable and trustworthy
than software-based writing-blocking.

There are many online sources that explain why. See, for example:

http://mykeytech.com/softwarewriteblocking2-4.pdf

In short, with software approaches, you're assuming that the software
works exactly as expected. Porter points out some scenarios in which
that won't be the case (e.g. virtual machine crashing). Many other
scenarios involve updates to the system (e.g. automatic operating system
updates) that override the settings. By contrast, hardware-based write
blocking physically prevents data from flowing to the storage medium.

The configuration of the BitCurator environment to mount drives as
read-only by default is not true write-blocking. And it's not intended
to replace hardware-based write blocking. It's just a precautionary
measure built into the system (belt and suspenders philosophy).

We recognize, of course, that there can be cases when hardware-based
writing-blocking isn't feasible, but again, it's always much safer when
you can.

- Cal

[jacqueli...@ptsem.edu]

Thanks, everyone for the information/discussion.

If hardware write blocking is more reliable, how do I enable it? 

As I wrote earlier, I followed Tableau's instructions, and the T8-R2 works, but BitCurator stops acquiring the image at exactly the 50% point.

Will this not happen if BitCurator is installed as its own operating system?

Suggestions?

Thanks,

Jackie

[jacqueli...@ptsem.edu]

Also, I don't know if this related, but now on starting BitCurator I get this message: VBoxClient DND: failed to connect to the virtual box kernel service. rc=VERR_ACCESS_DENIED

I haven't found this discussed here. I've been ignoring it but would appreciate some guidance.

Thanks,

Jackie

[Kam Woods]

Jackie,

That error (and other VERR_ACCESS_DENIED warnings you may see) are generally a side effect of running the VM with too few resources. If you increase the number of processors assigned to the BitCurator VM to 2 or more, and the RAM to 4096MB or more, the errors should disappear.

Regards,

Kam

--

You received this message because you are subscribed to the Google Groups "BitCurator Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-use...@googlegroups.com.
To post to this group, send email to bitcurat...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/7bdc7935-eaf2-49db-a33e-dd02016daff3%40googlegroups.com.

[jacqueli...@ptsem.edu]

Ok. Glad to know it's a simple fix. Thanks.