Some useful Virtual Machine info I thought I'd share...
Ken
New Member Posts: 48 ✭
If you are interested in creating a VM to do development with a UbiLinux installation, here's a little annoyance I've found. The UbiLinux kernel is compiled against the Atom Architecture and requires the MOVBE instruction capabilities to install. these instructions are not part of 3rd generation and earlier CPUs, so you will *not* be able to create a UbiLinux VM on a machine with an IvyBridge or earlier CPU, I have tried both VMware Workstation and Virtualbox, VMware complains about the missing capability and VirtualBox just hangs on install. Both install fine on Haswell 4th gen CPU hosts, however both the platforms I have available for 4th gen CPUs are using low power mobile optimized CPUs so I am not 100% sure that all Haswells and beyond are candidates or if there is Atom MOVBE compatibility specifically in those mobile friendly CPUs. Just be aware that UbiLinux is not generic and has installation limitations beyond just being Intel architecture.
I bring this up because after doing a few kernel compiles that took hours on the Up Board, and failures I have experienced with other solid state storage, I decided that doing something that beats on the "disk" for a couple hours is probably a bad idea on these boards and probably doesn't take too many of those to eat the eMMC. Even SSDs are prone to this, less so, but still, there is a limitation to how many times you can write to these devices before they give in and it isn't that high. While I haven't tested a kernel built on the VM platform yet, my plan here is to be able to compile on a VM with spinning disk with make-kpkg (which produces a dpkg compatable .deb file, it's kind of the standard Debian way of doing things) and import and install it then on the Up Board instead of compiling locally.
...and just to reiterate, anything that does heavy writes is bad on solid state storage, bad on SSDs and worse on eMMC, not just compiles, I have killed SSDs, quality consumer level SSDs like Samsung EVOs in pretty short order doing video recording and Virtual Machines and such. So, if you are considering using a system like this for a media platform, consider either adding a USB -> SATA port and a spinning disk or using network based storage. There are USB to SATA quasi HATs for the Pi that will work on these boards, and virtually all the ones I've seen for the Pi use none of the GPIO pins at all, they are simply Pi form factor boards made to stack on standoffs (though they are also typically USB 2.0 because that is a limitation of the Pi), I have also hooked up an external USB based and powered laptop drive and it seemed to spin up just fine and was recognized by the Up. This isn't a particular issue with the Up Board, it's an issue with any of these small boards using a less robust storage technology and honestly it's an easy solve on the Up, with GigE for network storage and a USB 3.0 port, just understand that with the increase in capability of the Up Board and built-on eMMC means the path to destruction of that component is faster.
I am adding M.2 SSDs to all my Ups for that reason, while SSDs still have limitations they are more robust than the typical flash device. I plan to move any frequent write operations over to SSD and make the eMMC effectively a non-OS operationally written device by moving things like /var and /home to SSD. To any interested I am using one of those Pi quasi-HATs from Ablecom which is cut around the GPIO pins so it's not even part of the stack and provides a pin header for USB (2.0) which I plan to hook up to the extra USB ports header so it doesn't really use any built-on accessible ports on the board either, making it effectively a zero impact upgrade, I actually plan to use the other USB header based port for a SparkLan RT5572 based WiFi paddle board I can stick to the SSD card giving me WiFi-n 5.8 Mhz capability as well in that same zero impact package. From reading here and in several other forums the RT5572 seems to offer a decent driver and gets away from the often clobbered 2.4 Ghz airspace.
I bring this up because after doing a few kernel compiles that took hours on the Up Board, and failures I have experienced with other solid state storage, I decided that doing something that beats on the "disk" for a couple hours is probably a bad idea on these boards and probably doesn't take too many of those to eat the eMMC. Even SSDs are prone to this, less so, but still, there is a limitation to how many times you can write to these devices before they give in and it isn't that high. While I haven't tested a kernel built on the VM platform yet, my plan here is to be able to compile on a VM with spinning disk with make-kpkg (which produces a dpkg compatable .deb file, it's kind of the standard Debian way of doing things) and import and install it then on the Up Board instead of compiling locally.
...and just to reiterate, anything that does heavy writes is bad on solid state storage, bad on SSDs and worse on eMMC, not just compiles, I have killed SSDs, quality consumer level SSDs like Samsung EVOs in pretty short order doing video recording and Virtual Machines and such. So, if you are considering using a system like this for a media platform, consider either adding a USB -> SATA port and a spinning disk or using network based storage. There are USB to SATA quasi HATs for the Pi that will work on these boards, and virtually all the ones I've seen for the Pi use none of the GPIO pins at all, they are simply Pi form factor boards made to stack on standoffs (though they are also typically USB 2.0 because that is a limitation of the Pi), I have also hooked up an external USB based and powered laptop drive and it seemed to spin up just fine and was recognized by the Up. This isn't a particular issue with the Up Board, it's an issue with any of these small boards using a less robust storage technology and honestly it's an easy solve on the Up, with GigE for network storage and a USB 3.0 port, just understand that with the increase in capability of the Up Board and built-on eMMC means the path to destruction of that component is faster.
I am adding M.2 SSDs to all my Ups for that reason, while SSDs still have limitations they are more robust than the typical flash device. I plan to move any frequent write operations over to SSD and make the eMMC effectively a non-OS operationally written device by moving things like /var and /home to SSD. To any interested I am using one of those Pi quasi-HATs from Ablecom which is cut around the GPIO pins so it's not even part of the stack and provides a pin header for USB (2.0) which I plan to hook up to the extra USB ports header so it doesn't really use any built-on accessible ports on the board either, making it effectively a zero impact upgrade, I actually plan to use the other USB header based port for a SparkLan RT5572 based WiFi paddle board I can stick to the SSD card giving me WiFi-n 5.8 Mhz capability as well in that same zero impact package. From reading here and in several other forums the RT5572 seems to offer a decent driver and gets away from the often clobbered 2.4 Ghz airspace.