Netinstall fails with brand new CRS310-8G+2S+IN

Hardware MikroTik hardware general
41

The problem with simpler ways (as in case of netinstall) is that sometimes app needs lots of control over lower levels of networking ... which is what high-level solutions (containers and VM platforms to a certain extent; unfortunately also Windows even if run on bare metal) take away.

The complexity of netinstall includes requirement that netinstall app is the only DHCP/BOOTP protocol server present on network where the device being netinstalled is connected. Which in case of running a container on a multi-purpose device (main router even) normally won't happen.

42

I had some time over the weekend to play a bit with Tiny Core Linux.

Tiny Core Linux is (IMHO) the only (or maybe one of very few) Linux distros that makes sense outside a "full", "normal" install, where you have to decide between 23 text editors, 3 or 4 shells/GUI's, etc. in a multi-Gbyte install, as it is highly modular.

Of course the way this modularity has beem reached is highly debatable, and if you want something the way you like it it is a PITA to put together something working.

Anyway, a 150 Mb image can contain the Linux system with GUI (around 30 Mb), a netinstall and a (mipsbe) .npk (around 70 Mb including the netinstall .tar.gz) leaving 50 Mb free/usable, the "extra" .npk still mipsbe is another 15 Mb zip.
So the "final" version should probably be around 200 Mb, to leave even more free space available and be on the safe side.

I went for the 9.0 version (current is 16.1) because it seems like the last one that includes in the on demand install repository the QtWeb browser (which is lightweight and good enough to access https://mikrotik.com/download), the only meaningful alternative for more recent versions is dillo (which I don't particularly like).

I also tested the CLI Lynx browser, and it works to download from Mikrotik just fine, but probably it won't be much appreciated by non-Linux guys, anyway for the CLI/text only version one could use MC (midnight commander) instead of xfe as file manager, personally I am very fond of OFM's (orthodox file manager).

Anyway, packages to download and install are:
tc-install-GUI <- to create the image from the booted .iso
Qtweb <- web browser
Openssl <- otherwise there would be issues with https certificates
xfe <- file manager (the only one that seems like working good enough while still tiny and including expanding/extracting capabilities for both .tar.gz and .zip )

Then you can access Mikrotik and download the netinstall and the needed .npk's.

I tested that netinstall starts just fine in this test (Virtualbox) VM (in the sense that it runs and gets to the "waiting for routerboard"), but I have had no time/will to attempt actually netinstalling (needlessly) a Mikrotik device, I will try next time I have a serious issue with a device.
However, loosely - though probably some touch-ups will be needed - 200 Mb seem like more than enough.

43

So the "final" version should probably be around 200 Mb

I've recast my NetInstall-in-a-VM process in terms of Alpine Linux, which gets the installation into the same size range before bringing down NPKs and netinstall-cli, though without a GUI.

There is a small hit to usability as a result, but it's paid for by simplicity in the default networking configuration, most notably the lack of a default firewall. It's a net push, as far as I'm concerned.

I've left the Fedora Workstation details in the article, both in case someone still wants to go that way, and to avoid losing the documented firewall discoveries.

I do still think a containerized version of this is possible. Because netinstall-cli is distributed as a statically-linked executable, it may even be possible to do without the Alpine layer, bringing the runtime size into the 160 meg range.

44

Good :), though I probably need to re-phrase.
The 200 Mb for Tiny Core Linux is the size of a hd-like image containing everything (i.e. the base OS, a simple and nice GUI (that also Windows users will find easy to use[1]) a graphical browser to download from mikrotik "normally" and some 150+ Mb free to contain the Mikrotik downloads and their expanded version).
I.e. it is a "monolithic" (though "frugal") install of everything in the same volume.
If we make it "volatile" using the ramdisk to store temporarily the downloads (like re-mastering it in a "live" .iso) it can go below 50 Mb in size.

So, if it actually works, the tested one is already well below the 160 Mb, actually 150 leaving some 50 Mb free (once ALREADY downloaded netinstall, one base and one extra package and without deleting the archives), raising it to 200 was only to allow some more slack, i.e. storing more versions of netinstall and packages.

[1] and xfe is an easy to use graphical file manager, as well windows users should have not troubles using it

45

It already exists ? On a Tik.

46

I'm well aware. I'm saying it should be possible to run that natively on an x86_64 host with the same benefits as these VMs.

Over half the 200 MiB install size of Alpine is the kernel and its loadable modules. Piggy, piggy, piggy!

47

@Holvoeth
The container version (at least the one in the provided link) implies 1 container=1 version.
The (mini) Linux distro approach is instead "universal", you boot to it and then choose which version to download (if not already downloaded).

@tangent
Yes, I don't see why it should not.
Anyway, my distro is (much) smaller than yours :wink:.

48

No, it does not.
You can feed other NPK files to it when you want.
Done it already plenty of times for arm, arm64 and mipsbe devices.
No change on container. Just environment variables need to be adjusted (and obviously you need to load the NPK files themselves on storage).

Unless you are referring to the specific netinstall version ?

49

Yep, I have no experience whatever with them, but I have seen quite a few reports of people that had to try different versions of netinstall to finally make the device "take" it.
Of course we don't have a real "proof" that it was needed, given the "strange" ways netinstall behaves, those reports may well have been "coincidences", i.e. when changing the netinstall version, something else was changed and it was this *something else" (or the full moon rising, or getting past midnight on wednesday, etc.) that made finally the thingy work.