First (very alpha) Nethserver RaspberryPi2/3 IMAGES needs testing

Hi all (@dz00te),

Who can test and give feedback on some RPI 2/3 images, this are the first (thus very alpha!) created with the RootFS Build Factory. This tool is also used by Centos Arm Special Interest group;
In short it parses a board/distro template to bash scripts who creates an IMG file on the local disk, partitions- and mounts it and then installs packages form the centos / nethserver-arm repository’s.

The challenge we need to solve is how can we create a best possible “works out of the box” experience.

The pristine images are never booted and start at first boot with a “signal-event system-init”.
This takes about 5 minutes (large depends on the speed of the SD card) and during this time the pi in not responsive. Even worse: during network configuration you lose ssh connectivity.

This are pristine images, so notice at first boot it takes a while before al is setup!

The only way to see what is happening is to connect a monitor, login and
journalctl -f

Here are images who are booted up (just after creation) as a systemd-nspawn container to run system-init. They boot up in about a minute.
This is not a good solution and prone to cause issues, so give me your thoughts!


browseable link

All Images

Login :  root
Password : centos

Thanx in advance for your feedback!


This is awesome work! :clap:

I flashed with Etcher under Windows 10 at about 11 MB/s
During validation of the image in Etcher windows explorer messages popped up recommending to format the newly created partitions. I just love it.
I put the SD card to my raspi 3, boot, login, journalctl -f and after 4m 57s the installation was ready and I was able to login to web UI.

  • I noticed there’s no wizard and the Hardware is not shown correctly. I got the correct DHCP warning:
  • Set static IPs, LAN and WLAN are working, SSH is working
  • I am going to install all software via web UI…OK this takes some time…but it worked.
  • root partition is only 2GB so it was 85% full after software install, maybe we could autoextend it at first boot install?
  • Reboot worked well and fast, LAN, WLAN, SSH, httpd-admin worked.
  • I tested Nextcloud and I had to change the bind user from libuser to ldapservice to make it work.

If there are some special things to test as regards this image, just tell me.

This already is a very good “out of the box” solution IMO, I’d just write something about the 5 minutes to the screen and to the docs and everything is fine. It’s not unusual to run some installation after first boot. I think open-/libreelec do it too for example.


You did a really excellent job!

I just want to share my experience, since I already had to face similar issues for our appliances with pre-installed NethServer.
Let’s put it straight: I couldn’t find a real solution to the slowness on the first boot :frowning:

The real hint is to reduce at minimum the number of actions executed from the system-init script. Bear in mind, that even a Shorewall restart can take up to 8-10 seconds on a slow hardware. And Shorewall is restarted at least 3 or 4 times during the system init.

Our image is baked from a virtual machine installation which is modified using virt-sysprep scripts. This approach allows to boot the virtual machine once and let it configure everything needed.
Then we craft a special system-init which replaces password and few other things.

In the end, I think we could shrink a bit the system-init if we know exactly what is the hardware target.
I think I spent a couple of weeks to have something not optimal but workable.

1 Like

@mrmarkuz, First of all, thanx for the feedback :+1:

If you mean the first web- screens to fill in your hostname, ssh port, smarthost and opt in/out of statistics; its unexpected behavior and must be fixed

its a known issue, there is a patch (link below) we could consider to do this by default. This would mean it needs to hook up to nethserver-base update-action

It did cross my mind; “grow-part” should be in place because it is based on the centos-releases (see README in root home dir), I did not test this my self. :open_mouth: I would like to see a “TO-DO” waring (just as the green- interface-DHCP warning).

EDIT: found a bug in the RPI2 image :disappointed_relieved:

Can be a bitch and say it’s a upstream issue also present in CentOS-Userland-7-armv7hl-Minimal-1708-RaspberryPi2 :grinning:

If stuff pops we know to find you, i am already happy with the elaborate report :grinning:

1 Like


I figured it is a kind of a Pandora’s box; good tip to look at this scrips. :thinking: