How is decided which version of ubuntu-console image is used?

When I add “console:ubuntu” to cloud-config or I type “ros console switch ubuntu”, which way is decided what version of ubuntu-console will be started?
Can I change the version of the image that will be used?
I’m asking this because our rancher os v0.6.0 started to download the ubuntu-console:v.0.7.0 after reboot. We use ipxe net boot and we didn’t change anything in our own built files (initrd, ipxeLoad, vmlinuz). It seems like this is an upgrade that nobody asked for. Is there an automatic upgrade process behind all this?

The v0.6.0 Ubuntu console should be the one used. Can you give me a bit more info on your setup (cloud-config, kernel parameters, etc…)?

OK, so basically we have decided to build the project, because we needed the PATA_AMD kernel module in the build. We have some machines with older IDE controllers and in order to be reach the local disks we need the module.
So first we started with Rancher OS 0.4.4, pulled the latest version from os, os-kernel projects, built them and that was working fine with kernel 4.2.8 ( linux-4.2.8-ckt3-rancher-x86.tar.gz, Ubuntu-4.2.0-28.33-rancher, I think)
After this we have decided to move to v0.6.0. We have pulled the v0.6.0 release from github and the os-kernel (commit 754391d). But we were unable to build the kernel, so we have decided to use the old kernel 4.2.8 with new v0.6.0 os.
And this was working as well. This was on 14th of September. But a week ago we had to reboot some machines and then rancher os started to download ubuntu console v0.7.0 during the boot process and now we are not able to login. It works with default console. We have build new v0.7.0 rancher and that works well with the old kernel. I know that maybe this mixture of old kernel with new rancher os is not “legal” and we will move on with the kernel version (if find out how to build kernel with PATA_AMD module in newer versions, maybe the documentation is outdated?).
Important fact is that we use discless setup, only the user docker’s state is persistent (–graph parameter is used), nothing else is persistent (not rancher, not system-docker)
But my main question is, what is the strategy of rancher os with upgrading system images? We use rancher os on bare metal and we would like to control upgrades, no automatic upgrade of any sort is desired. Also, what happens if we don’t have internet connection? Will rancher os work and boot properly?

Okay, I think I see the problem now. The default build target for make produces a development ISO that tracks master of the os-services repo. That means as soon as we updated to v0.7.0 images then your ISO was looking at these new images.

The current solution is to build RancherOS with make release rather than just make. I think there are definitely some improvements we can make on our end, such as having a better default and having more docs on this. We’re currently refactoring our build process, so this is something we’ll try to keep in mind.

So basically if we use the officially built releases or we build by using “make release”, then nothing gets upgraded automatically?