Issues with getting Ubuntu 1.7.40 onto new FRED

[lda...@wcs.org]

Hi all, 

We've just gotten a new FRED with Windows 10, and I'm trying to get it to dual-boot the BitCurator 1.7.40 environment.  

Each time I try (re)installing Ubuntu/BitCurator, I'm able to get it to load exactly once into the full GUI.  After that first time, attempting to load Ubuntu/BC goes to a black screen if the normal/default grub option is chosen, and to a command line login prompt if I try to start in recovery mode.  It's similar to this thread from last summer: https://groups.google.com/forum/#!searchin/bitcurator-users/login%7Csort:relevance/bitcurator-users/IhUK4w9sGC8/Q99blLZPBgAJ in that I can login to the command line version of BC fine, but trying ctrl-alt-f7 to get to the GUI doesn't do anything, and sudo restart lightdm returns a 'failed to connect to Upstart: failed to connect to socket [...] connection refused' error.   

I don't do anything in Ubuntu during those first (and singular) successful post-install loads, so I don't think it's a problem with some update breaking the BitCurator modifications.   

An earlier thread (https://groups.google.com/forum/#!topic/bitcurator-users/12DNCYIWD6c) mentions that FREDs were finicky with Windows/BC dual boots and required certain finessing to get everything to work right (at least, they did as of February 2015).   The instructions Kam posted in that thread are gone now; does anyone know of a current fix?  I'm attempting to install BC/Ubuntu onto the same SSD as Windows (sdb), but at this point would be happy with anything if it allowed a true dual-boot and didn't require going the VM-route. 

 Thanks much,

-Leilani Dawson.

- -

Processing Archivist

Wildlife Conservation Society Library & Archives

[Matthew Peters]

We've run into the same issue. Windows 10/Bitcurator on the same SSD with a separate drive for storage. The problem usually arises after the first reboot, but sometimes the second or third. We've tried with both 1.7.4 as well as the latest image (1.7.74)

From what I can tell, at some point the fstab is being rewritten and it's not preserving the entries with a UUID (namely, the system drives, but also our entry for the second storage drive which is how I discovered the fstab was getting rewritten in the first place). Sometimes it will create new entries without the UUID for said system drives, and in these instances the system will come back up with the drives read only (and the gui will not launch). In other cases no entries will be created for the system drives and the system will not come up at all, you'll just get a black screen.

To test this, I installed Windows as normal, shrunk the partition, then installed Bitcurator, upon the first boot into the system after the install completes I created a backup of the fstab (for testing I didn't edit the fstab to add the storage drive, this is just the one that exists after install):

sudo cp /etc/fstab /etc/fstab.orig

Then I reboot, if the system comes up, I'll check the contents of the fstab, sometimes it has been rewritten, but sometimes it hasn't. I've gotten, at most, three reboots before failure. When the reboot fails, I'll boot from a live disk image, mount the system drive and check the contents of the fstab, every time the fstab has been rewritten, and the system drive entry is either completely missing or is set to read only (though the swap is often correctly set to rw). If I copy my backup of the fstab over the current one, the system will boot correctly, but it's only a matter of time before it rewrites and fails to boot again.

I don't know if this is a symptom of another problem or if the problem lives in the rbfstab script itself.

-Matt
Electronic Resources & Digital Projects Coordinator
Special Collections & Archives, UC San Diego Library

[Andrew Berger]

Hi,

That fstab/reboot as read-only behavior sounds very similar to what we've experienced testing 1.7.4, except we're running BitCurator on a desktop machine that we've assembled ourselves, not a FRED. We do have two partitions: one for the OS and then a larger one specifically for storing large amounts of data. So the issue may be related to having multiple partitions in general, not specific to using a FRED.

We did eventually get the system to be stable on reboots (though testing continues). I don't know the details, but can check with our IT.

Andrew
Computer History Museum

--
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/a0a27f02-4daf-408a-a2c8-01fb4b476451%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Erin Faulder]

All, 

We have also been struggling to keep BitCurator 1.7.84 stable on our forensics machine that has two partitions for two operating systems and a second large hard drive for our data. We'll be able to reboot between the operating systems 3 or 4 times (or fewer) before it boots into a Ubuntu terminal window as read only and the only solution is to reinstall. 

Erin Faulder

Cornell University Library 
Division of Rare and Manuscript Collections

[Sam Meister]

Hello all, 

Just wanted to report here that the issue you all are encountering is being worked on and some fixes are being testing for inclusion in an upcoming release of BitCurator. Don't have a timeline for that right now, but will follow up with more info as it becomes available.

Thanks, 

Sam

[Kam Woods]

All,

Some additional context for the recent changes. Up to an including release 1.7.40, we had been using a distro respin tool that had not been properly updated for Ubuntu 16.04 (and was subsequently abandoned by its author). The 1.7.40 release was confirmed buggy (would not even reboot once on single-OS installs on some systems). So if you were using that release, the problem was with the bootloader. We now use a new UEFI-compliant repsin tool that was supposed to have addressed the issue. The testing procedure for this included a 20-cycle boot sequence on a 2014 FRED DX with a Samsung 850 Pro SSD containing a fresh Windows 10 install (shrunk to approximately half the size of the disk) and subsequently installed with BitCurator (these tests were carried out successfully with1.7.84).

Matt, a couple of notes: the rbfstab script does not write out UUIDs for secondary (non-boot) drives (which should all be mounted read-only by default). This is the normal behavior. The rbfstab script should *never touch* the system and swap partitions for the boot drive (it should see them when the system is installed - these are the fstab entries with UUIDs).

The behavior you're describing sounds as if something has gone wrong with recognizing the system partitions during installation of the bootloader rather than rbfstab itself (though I could be wrong), causing rbfstab to write and rewrite entries for partitions that should be left alone. It would be useful if you could send me a full partition listing for your system so I can try to replicate the setup and the behavior.

Kam

To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/66404e52-2535-48df-a0a0-c3ffd74e01f5%40googlegroups.com.

[Matthew Peters]

Hi Kam,

I had recently wiped the machine to test a pure BitCurator install on it (it was behaving nicely last I checked). I tried to replicate the original setup and reinstalled everything, starting with Windows 10, shrunk the partition, and then installed BitCurator alongside. Here's the partition listing from fdisk:

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x31dba29a

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048   1026047   1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2         1026048 490051583 489025536 233.2G  7 HPFS/NTFS/exFAT
/dev/sda3       490053630 976771071 486717442 232.1G  5 Extended
/dev/sda5       490053632 960120831 470067200 224.1G 83 Linux
/dev/sda6       960122880 976771071  16648192     8G 82 Linux swap / Solaris


Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x723fa62d

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1        2048 976769023 976766976 465.8G  7 HPFS/NTFS/exFAT

Here is the original fstab on first boot:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda5 during installation
UUID=33383642-9864-40c6-a779-c5c0c50c2ada /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda6 during installation
UUID=fa4422a7-8701-42ce-b7da-070f14738dec none            swap    sw              0       0
/dev/sda1       /media/sda1     ntfs-3g  ro,loop,noauto,noexec,nodev,noatime,umask=000,show_sys_files,streams_interface=windows,allow_other 0 0 # by rbfstab
/dev/sda2       /media/sda2     ntfs-3g  ro,loop,noauto,noexec,nodev,noatime,umask=000,show_sys_files,streams_interface=windows,allow_other 0 0 # by rbfstab
/dev/sdb1       /media/sdb1     exfat    ro,loop,noauto,noexec,nodev,noatime 0 0 # by rbfstab
/dev/sdc1       /media/sdc1     vfat     ro,loop,noauto,noexec,nodev,noatime,umask=000,shortname=mixed,quiet 0 0 # by rbfstab

sdc1 is the usb drive BitCurator was installed from. I tested removing and replugging the drive to confirm that entries are getting written properly when adding removing devices.

Here is the fstab as it was when the system finally failed to boot correctly:

/dev/sda1       /media/sda1     ntfs-3g  ro,loop,noauto,noexec,nodev,noatime,umask=000,show_sys_files,streams_interface=windows,allow_other 0 0 # by rbfstab
/dev/sda2       /media/sda2     ntfs-3g  ro,loop,noauto,noexec,nodev,noatime,umask=000,show_sys_files,streams_interface=windows,allow_other 0 0 # by rbfstab
/dev/sdb1       /media/sdb1     exfat    ro,loop,noauto,noexec,nodev,noatime 0 0 # by rbfstab
/dev/sdc1       /media/sdc1     vfat     ro,loop,noauto,noexec,nodev,noatime,umask=000,shortname=mixed,quiet 0 0 # by rbfstab

I did nothing on the system beyond opening a terminal window after each reboot and checking the contents of the fstab. There is a boot where system comes up fine, but the fstab has changed to something like what I have above (the entries are different, in the one above the linux partitions aren't there, sometimes they are, but set to ro). The reboot after that will always fail.

-Matt

[Kam Woods]

Thanks, Matt, that's helpful. I'm am continuing to dig in to the problem, but it may take a little time.

Kam

To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/e231188b-681a-4e04-8192-1a5e0b7b710b%40googlegroups.com.

[Kam Woods]

Matt,

I discovered a syntax error in two of the udev rules used to trigger the fstab rebuild (specifically, the rules used to handle SATA, PATA, and SCSI block devices). They've been fixed in the latest release, 1.7.90. You may wish to try this release and see if it resolves your issue.

Kam

[Matthew Peters]

Hi Kam,

I'm sad to report that the issue still persists. It failed after the first reboot this time. I checked the fstab on the first boot after install and it had been changed so that all the UUID entries were gone and the bitcurator partitions were set to ro (but it did boot properly so the fstab had to be changed after boot). On reboot all I got was the command line and of course the notice that the system had been set to read only.

-Matt

[Kam Woods]

Matt,

I'm afraid I'm still unable to replicate your issue on either of our FRED machines. I'm able to cycle both of them through 10 or 20 boots without issue with a "clean" Win10/BC 1.7.90 install, a "dirty" Win10/BC 1.7.90 install (installing over an existing copy of BC 1.7.84 by manually setting the partitions).

This might indicate you (and others) running into the issue share some bit of hardware or some software configuration that I don't have. There could be many different causes of this. You might want to dig around in /var/log to try and identify the issue.

I've attached my own (unedited) fstab entries for the successful tests on one of my FREDs here, with a bit of explanation of my test procedure.

https://docs.google.com/document/d/17i2ubUzQJ0nunf50XwgiFsS3reTfVdYE3bUElr_zm84/edit?usp=sharing

Kam

To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/f0542b86-61c0-4a4e-991e-ffd72e07f463%40googlegroups.com.

[Matthew Peters]

Hi Kam,

I've done a bit more investigating. I modified rbfstab so it leaves a few footprints behind. I set it to copy the tmp file it creates instead of moving it. I also added a line right after the initial grep -v (line 144) to remove existing rbfstab entries and this is what I've found: I have not one but three fstab tmp files all with the same timestamp, they aren't all alike but they are all missing the UUID entries. Two of them contain info for the linux partitions and one doesn't, so that could explain the rather inconsistent changing of the fstab. Strangely I only have one tmp file created by my copy of the initial grep data and it is completely empty which explains the UUID info disappearing.

I haven't found anything in the log files as of yet.

-Matt

[Kam Woods]

Matt,

I'm not clear on what you mean by "I also added a line right after the initial grep -v (line 144) to remove existing rbfstab entries" - grep -v is an inverted match: it is *already* copying to $TMP only those entries that were *not* added by rbfstab.

As for multiple temp files, that is the expected behavior. The original rbfstab in CAINE actually hit every device, and filtered out the block devices - so you'd often get dozens (or hundreds) of temp files. That (not the temp files but the triggering of the rules) messed with the operation of VirtualBox extensions, so we cleaned it up for only those common devices: /dev/sd* (PATA, SATA, USB block devices, etc), /dev/sg* (SCSI devices), and floppies. The triggers (as you've probably already seen) are in /etc/udev/rules.d/fstab.rules - though they're removed when you disable read-only mounts.

Kam

To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/4a4b2c90-00c8-4887-a64a-1a55f3fd4b09%40googlegroups.com.

[Matthew Peters]

Hi Kam,

Sorry for the confusion, I didn't add the line after the grep to remove the existing fstab entries, I added a line after the line that removes the existing fstab entries. Basically the line I added just copies the results in $TMP of that initial grep to a separate file from the tmp file so I could see what it was grabbing from the fstab (answer: nothing) before the rest of rbfstab runs (call it compartmentalizing results for analysis).

From what I can tell after 100s of reboots, rbfstab runs fine most of the time on our test machine. Just every once in a while that grep call returns nothing so the resulting fstab brings the system down. Now why the grep of the fstab fails to return anything is the question.

-Matt

[Kam Woods]

Matt,

Ah, ok. I could certainly be wrong, but this sounds like a timing issue with how the udev rules are being triggered. There are two simple experiments you can try to determine if this might be the case (read the whole message before trying these):

Experiment the First

***********************

Manually restore the correct entries to /etc/fstab and disable rbfstab, and do a series of reboots. As you probably know you can disable rbfstab simply by clicking on the green disk icon in the top write and selecting "Writeable". This removes the fstab.rules files in /etc/udev/rules.d/fstab.rules (or you can remove that file directly and reboot or restart udev) - either way rbfstab will never be triggered.

Expected outcome: system boots and continues to boot successfully, fstab entries are the same assuming you do not connect or disconnect any other devices (and new devices appear writeable if you do)

Bad outcome: system continues to exhibit weird behavior, in which case rbfstab is either not at fault or not completely at fault.

Experiment the Second

***************************

Explicitly assign an execution priority to the rules that are triggered and run rbfstab. This is pretty simple. Select "Writeable" to remove the existing /etc/udev/rules.d/fstab.rules. Make sure your fstab is valid (restore as necessary). Now, edit the following line in /usr/sbin/rbfsab:

RULE=/etc/udev/rules.d/fstab.rules

so that it reads:

RULE=/etc/udev/rules.d/10-fstab.rules

the re-enable read-only, reboot, and wash/rinse/repeat. 

(If the above instructions are unclear, you the following is equivalent: simply move the fstab.rules files to 10-fstab.rules with "sudo mv fstab.rules 10-fstab.rules" and edit rbfstab as above. Either way the goal is to have 10-fstab.rules be the name of the file that gets written/rewritten when the write-blocking is enabled/disabled).

Additional notes

******************

You can see a list of all the udev rules that are triggered in /lib/udev/rules.d. Naming the user-specified rule in /etc/udev/rules.d "10-fstab.rules" should force the system to perform the appropriate action *first* on detected devices using rbfstab, before other rules are encountered.

Please let me know how this goes, or if any of that doesn't make sense. I will see if I can find a different machine to test this out on, myself.

One more thought

*********************

You don't really *need* software write protection on a FRED, since you are presumably using an UltraBay and write-block capable floppy hardware. If Experiment the First works, and we're unable to resolve the rbfstab behavior in a timely fashion, you could simply disable it immediately after install, and run BitCurator that way for the time being.

Kam

To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/fae99a19-c0e9-4904-9924-636665893c0a%40googlegroups.com.

[Kam Woods]

Matt,

Apologies, but I forgot that the path for "fstab.rules" is hard-coded in several places in bc_policyapp.py (that app that runs on startup and provides you with the green/red disk icon in the top right). You will also need to edit the appropriate lines (there are several) in /usr/local/bin/bc_policyapp.py to read "10-fstab.rules" rather than "fstab.rules" in order for those previous instructions to work.

Kam

[Kam Woods]

Matt,

I've prepared a (not yet fully tested) release that incorporates the suggested modifications referred to in my previous messages. Not posted directly on the wiki at this time, but you should be able to download the installation ISO at

https://wiki.bitcurator.net/downloads/BitCurator-1.7.92.iso

for further investigation.

Kam

[Matthew Peters]

Kam,

I agree, it does seem like a timing issue. I only had a little bit of time today to do some testing but I was able to do the first experiment and disable rbfstab. The system went through 20+ reboots without ever having an issue so it seems likely to be the source of the problem.

All of our capture goes through hardware write blockers so the software block isn't technically necessary, just gave a little more piece of mind that nothing was getting written to the source. I will either try the new ISO or manually edit files when I get a chance and do some more testing.

-Matt

[Margaret Peachy]

Hi, All -

I wanted to circle back to Leilani's original email, as I'm also running into the same problem. Kam, would the instructions that you had posted (referenced in Leilani's email) still be helpful today in installing the BitCurator environment alongside Windows on the FRED? If so, do you still have them, since the original link is broken.

Thanks,
Margaret

[Kam Woods]

Margaret,

I'm afraid I don't have them any more. They were quite specific to a particular FRED setup (pre-UEFI, a particular RAID configuration, and dual-boot on separate drives with Windows 7), and would in any case not apply to Leilani's situation. Per Matthew's last reply (until someone is able to give me additional feedback on 1.7.92), the simplest thing to do in the meantime would be to immediately disable the read-only mounting on install.

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-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/e28b9224-b64e-472a-8dcf-05fd02d13176%40googlegroups.com.

[Dawson, Leilani]

Hi all,

 

I’m glad this has sparked so much discussion—it’s a relief to know the problem is not just ours and that Matthew, Kam, et al. are working on it. 

 

As an update, we’ve currently decided to go the VM route.  We’re looking forward to going back to direct install at some point, but for now it seems that using the VM on FRED’s pre-installed Windows is the most straightforward solution.  (It also vastly simplifies access to our interim storage area.)

 

Best,

-Leilani.

 

From: bitcurat...@googlegroups.com [mailto:bitcurat...@googlegroups.com] On Behalf Of Kam Woods
Sent: Thursday, December 01, 2016 2:07 PM
To: bitcurat...@googlegroups.com
Subject: Re: Issues with getting Ubuntu 1.7.40 onto new FRED

 

Margaret,

 

I'm afraid I don't have them any more. They were quite specific to a particular FRED setup (pre-UEFI, a particular RAID configuration, and dual-boot on separate drives with Windows 7), and would in any case not apply to Leilani's situation. Per Matthew's last reply (until someone is able to give me additional feedback on 1.7.92), the simplest thing to do in the meantime would be to immediately disable the read-only mounting on install.

 

Kam

On Thu, Dec 1, 2016 at 10:14 AM, Margaret Peachy <mpe...@gmail.com> wrote:

Hi, All -

I wanted to circle back to Leilani's original email, as I'm also running into the same problem. Kam, would the instructions that you had posted (referenced in Leilani's email) still be helpful today in installing the BitCurator environment alongside Windows on the FRED? If so, do you still have them, since the original link is broken.

Thanks,
Margaret

--
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/e28b9224-b64e-472a-8dcf-05fd02d13176%40googlegroups.com.

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

 

--

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/CAAOjFxDmYwBdjYUHDn%3DVQzNy8bxsOzEhb_PNObA2g_btZJBydA%40mail.gmail.com.

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

Click here to report this email as spam.

[Matthew Peters]

Kam,

I almost thought 1.7.92 fixed it. I went ~20 reboots without a problem, and then it hit again. I don't know if it was a fluke that I went that many reboots without a problem or if the updates minimized the chance of it cropping up, but it's still there. We have a couple plans in the works here that will let us work around it (turn off rbfstab since we are using physical write blockers and/or move Windows needs to another box since this seems to be a dual boot only problem from what we can tell).

Just as an FYI I did a clean install, completely wiping the drive again, installing Win10 and then 1.7.92 after shrinking the partition.

-Matt

[Kam Woods]

Thanks Matt, I appreciate all of the hard testing work. So by moving fstab.rules to 10-fstab.rules, I basically forced the device management daemon to execute the rbfstab script *first* for devices before doing anything else; the fact that this made the problem appear less frequently (but didn't fix it) means this may be a multiprocess issue where several instances of rbfstab are competing to read/write fstab and very occasionally hitting it in a 'bad' order.

The solution may be a locking mechanism, but implementing this correctly may take some time. I will have to investigate further.

Kam

To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/86bdb88d-f6b1-43de-8e25-c5e867a279bc%40googlegroups.com.

[Kam Woods]

Matt,

I have a reimplementation of the script that corrects what I believe was a time-of-check-time-of-use race condition in the original. I've only done preliminary testing, so far, but if you're interested in trying it out you can find it at:

http://wiki.bitcurator.net/downloads/rbfstab

You will need to download this file and copy it to /usr/sbin/rbfstab (or copy the text into a new text file, and copy that file to /usr/sbin/rbfstab with "sudo cp /path/to/your/rbfstab /usr/sbin/rbfstab") in order to test it. Or you can wait for the next release. If you're able to test now, that would be very helpful.

Kam

[Margaret Peachy]

I'm wondering if anyone has had trouble getting the VM running on the FRED? I've gone into the BIOS and turned on virtualization, but I still get this error when trying to boot the VM:

Failed to open a session for the virtual machine BitCurator-1.7.92.

VT-x is not available (VERR_VMX_NO_VMX).

Result Code:	E_FAIL (0x80004005)
Component:	ConsoleWrap
Interface:	IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

 

Thanks,

Margaret

On Thu, Dec 1, 2016 at 2:18 PM, Dawson, Leilani <lda...@wcs.org> wrote:

Hi all,

 

I’m glad this has sparked so much discussion—it’s a relief to know the problem is not just ours and that Matthew, Kam, et al. are working on it. 

 

As an update, we’ve currently decided to go the VM route.  We’re looking forward to going back to direct install at some point, but for now it seems that using the VM on FRED’s pre-installed Windows is the most straightforward solution.  (It also vastly simplifies access to our interim storage area.)

 

Best,

-Leilani.

 

From: bitcurator-users@googlegroups.com [mailto:bitcurator-users@googlegroups.com] On Behalf Of Kam Woods
Sent: Thursday, December 01, 2016 2:07 PM
To: bitcurator-users@googlegroups.com
Subject: Re: Issues with getting Ubuntu 1.7.40 onto new FRED

 

Margaret,

 

I'm afraid I don't have them any more. They were quite specific to a particular FRED setup (pre-UEFI, a particular RAID configuration, and dual-boot on separate drives with Windows 7), and would in any case not apply to Leilani's situation. Per Matthew's last reply (until someone is able to give me additional feedback on 1.7.92), the simplest thing to do in the meantime would be to immediately disable the read-only mounting on install.

 

Kam

On Thu, Dec 1, 2016 at 10:14 AM, Margaret Peachy <mpe...@gmail.com> wrote:

Hi, All -

I wanted to circle back to Leilani's original email, as I'm also running into the same problem. Kam, would the instructions that you had posted (referenced in Leilani's email) still be helpful today in installing the BitCurator environment alongside Windows on the FRED? If so, do you still have them, since the original link is broken.

Thanks,
Margaret

--
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-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/e28b9224-b64e-472a-8dcf-05fd02d13176%40googlegroups.com.

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

--
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-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/CAAOjFxDmYwBdjYUHDn%3DVQzNy8bxsOzEhb_PNObA2g_btZJBydA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Click here to report this email as spam.

--
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/AmL1qT-q_b0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcurator-users+unsubscribe@googlegroups.com.
To post to this group, send email to bitcurator-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/DM2PR0401MB11332C486597D27423491854A58F0%40DM2PR0401MB1133.namprd04.prod.outlook.com.

[Kam Woods]

Margaret,

There are several reasons this might occur. The most common is that while you might have enabled some virtualization controls in the BIOS, you did not *explicitly* enable VT-x extensions. This differs from BIOS to BIOS (even FRED machines, which have many different motherboards from year to year), so you may need to do some digging to find the "Intel VT-x" feature and enable it.

Another reason may be that you have Hyper-V enabled in Windows. You can disable Hyper-V by running cmd.exe as an Administrator user and entering the command "dism.exe /Online /Disable-Feature:Microsoft-Hyper-V".

Finally, if you are running a version of VirtualBox prior to 5.1.10 (along with the 5.1.10 host extensions), you may simply be seeing a bug in VirtualBox.

Hope this helps.

Kam

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

[Margaret Peachy]

Thanks, Kam - that worked, along with reinstalling the virtual machine after disabling Hyper-V.

Best,

Margaret

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