Nico Kadel-Garcia wrote on 2/22/17 1:05 AM: > On Tue, Feb 21, 2017 at 3:58 AM, MAH Maccallum > <[log in to unmask]> wrote: >> Thanks, Christoph-Erdman. I managed to resolve the problem by >> uninstalling a Windows program that was, I think, causing the >> issue by trying to access the Linux partition, so I am back in action, >> but your information will certainly help avoid such issues in future. >> Thanks again, Malcolm > Note to the wary. The simpler solution, for the future, is not to use > dual-boot. Virtualize one OS inside the other, and don't expose one > system's disks to the other.except over more regulated, network based > file sharing. I admit that, these days, I'll use Windoes as the base > OS for better support from my hardware vendor and better game > performance, and use VirtualBox or other virtualization systems for > running lighter weight Linux VM's. for testable research and > development on my laptop or desktop. I don't get the full speed of the > the hardare for my Linux VM's, but they're so much lighter weight I > don't usually *care*, and I can still run my games and critical > Windows apps. > > And yes, I've run critical debugging tools and penetration tools from > my Linux VM, on an encrypted disk for basic security in the admittedly > tougher to secure Windows environment, and even run PXE, DNS backup > servers, and internal Scientific Linux yum mirrors on VM's on my > laptop for debugging and network services as needed. And it's been mch > easier to debug or repair a broken VM than an unbootable dual-boot > setup. > > I'm not discounting dual-boot solutions for bare metal speed or > debugging hardware driver compatibility, but I don't see a lot of > point to it these days. When VMware Workstation 3 came out over 15 years ago, I totally stopped supporting dual-boot on my users' computers and highly encouraged them to use VMware. When informed that they could share files between their Windows host and the linux VM in real time, it became a no-brainer. We had a license for multiple systems, so all they had to do was grab it from our local software repo and install it. Life became so much easier. If you are looking for a significant improvement in performance over a VM, you can go the container route and install Docker for windows (https://docs.docker.com/docker-for-windows/). However, that just gives you a command line interface (CLI). On a linux host running Docker, you can run a windows manager in the Docker container. See here: https://csicar.github.io/docker/window-manger/2016/05/24/docker-wm.html How to do that on a Windows host, I don't know - never went there. Docker images start up exceedingly fast (in a couple of seconds) and performance is almost as fast as the native hardware (be it windows, mac, or linux based), whereas, as Nico points out, running a VM is much slower in performance than the native host. It's not for everyone, but if you need native host performance, it's something to try. Most folks are familiar with VMs, so there's a bit of a learning curve with Docker and its terminology and syntax, plus you may run into unforeseen gotchas with Docker. I, personally, have not used Docker on Windows or a Mac - just on linux. You don't have to build a linux OS with Docker (as with a VM, although you can download pre-built VMs) - you just download a pre-built container from the public Docker hub of whatever distro you'd like, be it Ubuntu, CentOS, etc. But the container is ephemeral, so if you make changes to it (add/update software), you need to issue a "docker commit" command after exiting the container, otherwise any changes vanish. You can build your own, which is what I had to do last summer when I needed an SL6.x container and none were to be found on the Docker hub - just latest 7.x releases of CentOS. There were some CentOS 6.x containers, but they were special use cases built by individuals and not approved by Docker for general use and were not being updated to stay current. And who knows what goofy or weird software or setups were in them. After building my own, based entirely on the host SL6.x system where I had Docker installed, I then needed to upload my SL6.x container to the public Docker hub repository, as setting up your own container repository is significantly non trivial. Meaning, I could then go to any linux system with Docker installed and download (pull) my SL6.x container and run it as is. Caveat: I'm retied now, so I haven't worked with Docker since last summer and haven't kept up with any new changes or features. And as always, your mileage may vary... Just another option... - Larry -- P. Larry Nelson (217-693-7418) | IT Administrator Emeritus 810 Ventura Rd. | High Energy Physics Group Champaign, IL 61820 | Physics Dept., Univ. of Ill. MailTo: [log in to unmask] | http://hep.physics.illinois.edu/home/lnelson/ ------------------------------------------------------------------------------ "Information without accountability is just noise." - P.L. Nelson