Linux distros with official VM images

[RoGeorge]

Each couple of years I'm spending hours to setup old toolchains, again and again.  The older the toolchain, the harder to setup it again on current OSs. 

Decided to never do that again, and from now on to keep a virtual machine for each devboard/toolchain.

Was looking in particular for ready made VirtualBox images of Ubuntu, but found them distributed only by 3rd parties, e.g. https://www.osboxes.org/virtualbox-images/  Eventually it can be any other Linux distro, as long as it's an official VM image.

Don't want a 3rd party VM image, or to make my own VMs.
Which Linux distro, if any, use to provide official VMs, too, for free?

[Marco]

The big cloud providers probably have better QA than Ubuntu any way.

[greenpossum]

Set up a VM the way you want, then take a snapshot of it if you need to restore to a checkpoint, or put it on another machine.

[mrflibble]

Since the answer is "no, there are no exact matches for the given problem", might as well go for plan B:
Install your own VM anyways, but make it unattended. Optionally with prepared configuration.

The idea here being that you have to do the work only once to get your intended setup. After that you can rerun the automated install, optionally with different VM settings for your target VM. Or simply clone or snapshot the VM you just created.

If coming up with the config is too much work, AND there exists a 3rd party image that has all the packages & config you really like, AND you don't quite trust this 3rd party but you do sorta-kinda trust them but let's not go overboard here, THEN you can do as follows: Grab sortof okay 3rd party ubuntu VM image. Extract preseed config. Depending on paranoia level go over this config, and tweak where needed. Grab official ubuntu installer image. Run official ubuntu installer using your preseed config. That way you get the benefit of a prepared known-to-work config, while still using only trusted packages from the official ubuntu repo.

Alternatively you could look into using docker images. Pro: smaller footprint than 1 full VM image for each toolchain. Con: If you don't trust those 3rd party images, then you should definitely not trust the average docker image. The amount of crap floating out there is ... amusing. Same recipe applies though. I regularly grab a docker image that has more or less what I want, and then give the Dockerfile a much needed scrub. Then I recreate the docker image using repo's & configs I actually trust.

Depending on the amount of toolchains & similarities & expected lifetime 5,10,30,60 years, I would probably go with one VM for running docker. And then for each of those 10+ toolchains have a docker image. Or maybe just 1 VM per toolchain. It would all depend on the specifics. Anyways, just some options you may want to consider.

PS: just google "ubuntu preseed" for some inspiration. Or "debian preseed" for more reliable inspiration.

[RoGeorge]

I didn't know about preseeding, thank you!   

I am avoiding docker because I don't want yet another 3rd party dependency.  The need is for a standalone "something" that can be fired up 10 years from now, has all the tools for the given project already installed and configured, can be kept offline, and can be run without much fiddling assuming there is an IBM PC computer available with whatever OS will be 10 years from now.

Storing full virtual machines seems to be the most promising, beaten only by keeping physical machines.

[ve7xen]

Ubuntu does provide pre-baked VM images. However they are designed for cloud deployment, so if you just start them up in VirtualBox, you won't be able to log in to them. There are solutions for this, but out of scope for this board, I think. It is a bit cumbersome.

https://cloud-images.ubuntu.com/

If your intent is just preservation, why don't you install Ubuntu Desktop from the ISO and use that as a template to create your own VMs?

[bitman]

Each couple of years I'm spending hours to setup old toolchains, again and again.  The older the toolchain, the harder to setup it again on current OSs. 

Decided to never do that again, and from now on to keep a virtual machine for each devboard/toolchain.

Was looking in particular for ready made VirtualBox images of Ubuntu, but found them distributed only by 3rd parties, e.g. https://www.osboxes.org/virtualbox-images/  Eventually it can be any other Linux distro, as long as it's an official VM image.

Don't want a 3rd party VM image, or to make my own VMs.
Which Linux distro, if any, use to provide official VMs, too, for free?

Consider using containers - or if you're on Linux at least use libvirt - not virtualbox or other proprietary toolsets.  Look for qcow images and there are a ton that are easily to use on libvirt. But containers will make your life much much easier. You'll find a ton of images on places like docker hub or quay.io where you can simply pull an image and when now images are available, you can simply "pull again".  The difference is that the containers come "self-contained" with everything they need and still work off your single host system.  What containers are not so good at is GUI stuff (it is possible, but not really their use case) so if you're looking at setting up IDEs and other testing software you're most likely better off with a VM.

Fedora (my preferred) offers qcow images pre-configured etc. for download. You can most likely find ova images too but since I don't use Windows I haven't really looked for them. The only trick with the qcow image is that since they come pre-configured you have to inject a "cloud-init" setup or use the qemu-img to customize their IP/Network and user setup. Root is by default disabled in these images. But you can use this "cheat" on every system - so it's a one time deal only.   What this does not do (compared to containers) is offer you an upgrade path when there's a new image available. You'll have to use the traditional "yum/dnf update" to update each image.

I highly recommend getting a bit of ansible and you can run one command to update all your VMs.

[westfw]

has all the tools for the given project already installed and configured

Most of the linux installs I've done have come up with some sort of user-oriented environment, rather than a development environment (are there version (preseeded?) setups that install popular combinations of development tools?)The chances that there's a pre-made VM that matches any particular set of tools seems really slim :-(

[bitman]

has all the tools for the given project already installed and configured

Most of the linux installs I've done have come up with some sort of user-oriented environment, rather than a development environment (are there version (preseeded?) setups that install popular combinations of development tools?)The chances that there's a pre-made VM that matches any particular set of tools seems really slim :-(

A lot of distributions have solutions for this. Again containers are meant to solve the issue of dependency distribution by including everything in the package. There are FlatPak and similar delivery mechanisms that also allows someone to distribute a single item that holds everything. Installing and maintaining gets simpler - as long as you have the HDD for it. What isn't so simple is how you maintain your overall security patches when everyone includes their own version of what used to be shared libraries.

Finally distros have "spins". These spins are pre-packaged installs based around a topic (graphical design, electronics, robotics etc).

But at this point I have to stress that if you're looking at finding a commercial vendor who still thinks SELLING software is a profit center, this stuff will never happen. FOSS solutions supported by a community of contributors DO want to make it easier to consume.  So if you're hoping your xlinx or mplab will all of a sudden become available in your favorite linux distribution and be easy to setup - nope.

[RoGeorge]

I'm talking about manually installing the required toolchains, then "froze" that virtual machine, and store it together with the devboard.
- I don't care about security or other updates, that virtual machine will never see the Internet.
- It must all work offline.  Must be self-sufficient.
- I don't need to distribute anything, just to conserve the software toolchain for each devboard.
- It's for personal use only.

The whole thing should be in a format that can be run in 10 years from now.  I'm not sure containers will still be a thing after a decade, we already started to use Kubernets, and who knows what will come.  I'm thinking a today container won't run on a random computer decades from now.

[SOLVED]
1. Manually install the minimal version of Ubuntu that can still run the toolchain for a given devboard (smaller versions tend to be smaller in disk size)
2. Manually install required tollchain(s)
3. Always use each devboard with its virtual machine, never with the current OS
 

[bitman]

I'm talking about manually installing the required toolchains, then "froze" that virtual machine, and store it together with the devboard.
- I don't care about security or other updates, that virtual machine will never see the Internet.
- It must all work offline.  Must be self-sufficient.
- I don't need to distribute anything, just to conserve the software toolchain for each devboard.
- It's for personal use only.

The whole thing should be in a format that can be run in 10 years from now.  I'm not sure containers will still be a thing after a decade, we already started to use Kubernets, and who knows what will come.  I'm thinking a today container won't run on a random computer decades from now.

[SOLVED]
1. Manually install the minimal version of Ubuntu that can still run the toolchain for a given devboard (smaller versions tend to be smaller in disk size)
2. Manually install required tollchain(s)
3. Always use each devboard with its virtual machine, never with the current OS
 

First - happy you have a solution you like. So as a last comment to your perspective on what will be there 10 years from now:

* Your VM image will not be supported 10 years from now.
* Containers is an old technology - we used it in the 60ies, 80ies and 90ies as part of main line very powerful tooling to do computing. Don't confuse "docker" with containers.
* If you're not worried about updates your customers will be. I'll be happy to send you a ton of links from IoT and other types of embedded projects that all thought that security didn't matter to them and the consequences of those ideas were to them, their customers and the investors of those companies.  Your attitude here is quite a bit scary to me.  I like hundred of millions of other people live with the consequences of relaxed/ignored security and ideas of what it takes to make enterprise products.

Freezing development environments and dependencies can "easily" be done. Build tools and repository management have been tools for 20+ years. When you run your build, dependencies are resolved and downloaded and they stay downloaded until kingdom come depending on your settings.  If you're really nervous you make that repository local to your system (better if you make it a proxy/cache) so it will build fully disconnected too. Granted, the connected may just be to an internal office server.

Anyway - you said you find a solution that makes you happy - so I'll leave this thread here with those remarks responding to your views.  For private use I really have no steak but it scares me that what you do here is repeated so many times, with the same mindset, in products/services sold to the public. So let this be my little voice of objection to the notion that security doesn't matter. It does, even when it's just a private/home project.

Good luck.

[RoGeorge]

* Containers is an old technology - we used it in the 60ies, 80ies and 90ies as part of main line very powerful tooling to do computing. Don't confuse "docker" with containers.

I guess i'ts a typo about the 60s, but that's not what I want to ask.  Indeed, by container I was thinking Docker, and I don't understand very well the difference between chroot, namespaces, containers, docker and so on.  I'm familiar with Linux for a long time, and for about a year I ditched Windows completely, yet I might use the wrong terms while asking something, so just to be sure, let's take an example:

- some time ago there was a devboard from TI called MSP-EXP430G.  It was for the MSP430 family of Texas Instrument microcontrollers.  It came with a socket, so it can be used as a programmer/one wire hardware debugger for many TI chips.  I still have a few MCU models ordered back then that can be programmed/debug with that small devboard.

- now it's winter, and the air humidity is low, so I want to log the temperature and humidity from two rooms using a HTU21D sensor and a nRF24L01+ 2.4GHz transceiver (not Wi-Fi, not IoT) connected to a MSP430 microcontroller which I already have plenty in stock.

- searching online, there are many similar projects made with Arduino, or with Energia (the Arduino IDE from TI, for their boards only).  However, the MCUs I have are pretty small in both RAM (128 or 256 bytes) and flash (1-2KB), and I want to make them run from a CR2032 coin battery, so Arduino/Energia examples are not good, nor in memory footprint, nor in power save.  I want full control, so I'll write all from scratch, as a C exercise.

- TI is using CCS (Code Composer Studio) as a C/C++ IDE.  CCS is a combination of GCC with a MSP430 port, packed together with Eclipse.  Has all the tools, including a working one wire hardware debugger.  However the current CCS, v9.3, while it supports the MCUs I have in stock, it does not support my devboard any more, so I won't be able to program/debug the chips.

- I know for sure CCS v5.3 works great (because I did a few projects with it back then), but after fiddling with it and searching for a few hours, I couldn't install CCS v5.3 in my current Ubuntu 18.10

- This April, Ubuntu 20.04 LTS will come out (Long Time Support - 5 years free updates or 10 years with paid updates), and I can hardly wait to switch to it.  My current Ubuntu is a mess, so I'll reinstall everything from scratch in Ubuntu 20.04 LTS.

Now, given all that, how, or what kind of containers should I use, so to be sure next time in April or maybe in 2024 April I won't spend yet another weekend to re-install CCSv5.3, for example?

Asking for an example just to better understand how the containers work, because I have a few other devboards in a similar situation.

[bd139]

Don't use containers for this shit. You're just going to give yourself more of a headache. I know. My day job is running thousands of them. VMs is a possibility but then you inherit the problem of dealing with target programming devices and the like from inside VMs which is even more of a problem.

If you need to install multiple "static" toolchains on linux the best way to do it is create a /opt/whatever/ directory for each tool chain and just add that to the path as required manually (or with a script). Sometimes things need more persuading than others and if there's anything that uses OS distribution packages it's a pain in the butt but once it's working it's robust, doesn't screw the OS, doesn't screw the toolchains up and you can drag it to new OS versions easily.

As for your requirements I tend to use AVR with AVR-gcc and try and make everything sleepy, low clock and interrupt driven to save power. That gives you a somewhat more hassle free toolchain, economy and similar power usage to MSP430. The last thing I built was a morse keyer with average power consumption of about 30uA. That's nearly 2 years off one CR3032...

Edit: also if you’re using Linux the best advice is use LTS releases only of Ubuntu and don’t upgrade until they’ve been out for a year!

[RoGeorge]

use LTS releases only of Ubuntu and don’t upgrade until they’ve been out for a year!

That last advice scares me, so to not clutter this topic, I've opened another one to ask why not (and other things about Ubuntu 20.04 LTS, which I plan to install very soon).
https://www.eevblog.com/forum/general-computing/ubuntu-20-04-lts/

[bd139]

I'll keep it on this thread for now but I'd avoid it on the basis that their QA is quite frankly terrible. Had nothing but problems with everything LTS going back to 10.04 LTS. I'm not saying that it's unique to them. CentOS 7 was horrible for 9 months until they ironed out all the systemd integration bugs. If you need stability you need to be conservative.

[RoGeorge]

To me the greatest pain was the hardware, I have and use both the nVidia and the i7 GPUs.  In 2018, when I switched from Windows to Linux, the only two iso that were able to boot upto a GUI were Fedora and Ubuntu.

All the rest (I've tried many, 5-10 flavors at least) were not able to make it up to a GUI login.  Tried 2-3 BSD flavors, too.  Couldn't get any working GUI for them either.  Could be only my fault, because I still don't have a good overview of the many possible GUIs, and how they work.

[bd139]

This is why I use windows despite being basically a full time Linux dude

[Karel]

This is why I only use AMD graphics cards and the default opensource drivers that come with the distro 

[madires]

* Your VM image will not be supported 10 years from now.

I'm using VMs for 20 years now and I had no major issues with moving them to new or different VM solutions. VMs are ideal to keep legacy software running.

Some hint for VirtualBox: If you've installed Guest Additions and like to disable the automatic time/date synchronization to be able to change time/date in the VM run:
  VBoxManage setextradata "VM name" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1

[nctnico]

If you need to install multiple "static" toolchains on linux the best way to do it is create a /opt/whatever/ directory for each tool chain and just add that to the path as required manually (or with a script). Sometimes things need more persuading than others and if there's anything that uses OS distribution packages it's a pain in the butt but once it's working it's robust, doesn't screw the OS, doesn't screw the toolchains up and you can drag it to new OS versions easily.

This may work for standalone tools but not for tools which depend heavily on OS supplied tools and libraries (a buildroot environment for example). Think about specific versions of Python and system libraries for packages which aren't supporting cross compilation fully.

[SiliconWizard]

This is why I use windows despite being basically a full time Linux dude

I must admit that when it comes to OS compatibility, things are much less painful with Windows on average. That was actually a strong point of Windows, as long as developers were reasonably following a few rules (at least up to more recently where it's going downhill IMO).

Linux is a lot more fragmented (which is a normal consequence of the open source model, not criticism!)