rockstor / rockstor-installer Goto Github PK

By moving to 4.0.4-0 newly created installers will have, preinstalled, a version of Rockstor that can successfully authenticate against the Stable Channel updates. See the following issue in rockstor-core of the recently discovered and fixed Stable Channel update bug:

Stable updates regression Rockstor 4 release candidate
rockstor/rockstor-core#2227

This is important as we approach our first "Built on openSUSE" Stable Channel release. Version 4.0.4-0 is Release Candidate 5:
https://forum.rockstor.com/t/beta-built-on-opensuse-testing-channel-changelog/7097/11
But if all is well, i.e. no show stopper like we have just had in the above, this 4.0.4 version may well be promoted and deemed to be our re-launch version.

In this repo we currently build from the latest version available in testing. This is currently not a problem as our testing is in release candidate phase ready for imminent promotion to the stable channel. But there after, as the testing channel readopts it's name sake purpose we need to pin the testing rpm version used in this repo to a known good release candidate or release version.

It is proposed that we pin to version 4.0.0-0.

This will allowing for the testing of the update mechanism to the actual RC, with no functional change, of 4.0.1-0 when subscribing to the Stable channel there after: once we have finalised the exact rpm version that is to be promoted to the Stable channel.

As we near our Rockstor 4 re-launch, which is specified as 'Built on openSUSE Leap 15.2' and given our move to multi arch, the recent inclusion of a couple of aarch64 targets (Pi4 & ARM64EFI), it is proposed that we remove the Leap 15.1 profiles. This proposal is in the light of Leap 15.0 & 15.1 having served as our run-up to the Rockstor 4 release on a 15.2 base, and the fact that in 2 months time, from this issues creation, Leap 15.1 is EOL: see https://en.opensuse.org/Lifetime (November 2020).

The additional repo base target is also a significant draw on our limited resources and ends up thinning out our available testing resources, both computational and human. We are now also looking to the jump directive that aims to further the binary compatibility and kinship of openSUSE Leap and SLES offerings. This is a far more important target to concern ourselves with in the future than the soon to be EOL Leap 15.1 from our development past. And given Jump 15.2 now has an alpha release we should look to pruning our prior development targets to make way for the new development target of Jump 15.2 and in turn it's successor.

This removal of the Leap 15.1 base should also help to avoid the 'optic' that we will be supporting a Leap 15.1 Rockstor 4 base as this is not the case. It was a development stepping stone, as was 15.0 before it, to the more appropriate Leap 15.2 that we have indicated as our preferred Rockstor 4 re-launch base.

Currently you need a drive under 500GB to install 4.0.2 and this is confusing for new users. Sometimes the install drive will be bigger (as in my case) because I have spare drives that aren't being used and one is 4TB. I propose increasing the hard drive limit to 5TB and give users the choice to install there or not (the drives will show up before install overwrites them and this is normal behavior).

I am using this issue to submit a PR fixing this on the boot install line instead of reworking underlying components. A change to the kiwi file should suffice.

The OBS repository http://download.opensuse.org/repositories/network:/time/openSUSE_Leap_15.2 might not be needed anymore as the changelog in the chrony package seems to indicate a fix for an infinite loop bug:

Tue Sep 29 08:52:56 UTC 2020 - Reinhard Max [email protected]

• Integrate three upstream patches to fix an infinite loop in
  chronyc (bsc#1171806).
  • chrony-select-timeout.patch
  • chrony-gettimeofday.patch
  • chrony-urandom.patch

https://build.opensuse.org/package/view_file/openSUSE:Leap:15.2:Update/chrony/chrony.changes?expand=1

Although the latest version of chrony from the Leap15_2_Updates repository is still at 3.2, it might now be OK to use without experiencing the 100% CPU usage we encountered in the past.

It appears that the shells repo needed for Shellinabox is now available for Leap 15.2 (x86_64 only, though), so we might be able to update the current one we use (Leap 15.1):
http://download.opensuse.org/repositories/shells/openSUSE_Leap_15.2/

The shellinabox version appears identical:

Leap 15.2

http://download.opensuse.org/repositories/shells/openSUSE_Leap_15.2/x86_64/shellinabox-2.20+git.1548649128.4f0ecc3-lp152.3.1.x86_64.rpm.mirrorlist

Leap 15.1

http://download.opensuse.org/repositories/shells/openSUSE_Leap_15.1/x86_64/shellinabox-2.20+git.1548649128.4f0ecc3-lp151.3.1.x86_64.rpm.mirrorlist

I tried to install the build image on a system, which is set to EFI. So CSM is disabled on this system.

The USB strick bootet without any problem. Installation went fine.
But after reboot the installed system does not boot.
The UEFI firmware does not even find any bootable disk.

So I think there is a problem with the grub installation on this system.

This issue is a follow-up of #49 .

In our config.sh, we currently use the BaseMount and BaseCleanMount. As reported in the kiwi build log, however, these functions are now deprecated as this is now taken care of by kiwi-ng itself. This deprecation happened in October 2020:
OSInside/kiwi#1597

The above methods are obsolete since kiwi handles these mount/umount processes as part of the core builder code.

It thus seems we can safely remove them from our config.sh, as has been done in Leap15.3 JeOS kiwi-template:
https://build.opensuse.org/package/view_file/openSUSE:Leap:15.3/kiwi-templates-JeOS/kiwi-templates-JeOS.changes?expand=1

---

Wed Sep 2 10:00:36 UTC 2020 - Fabian Vogt [email protected]

• Drop call of baseCleanMount, not necessary

and

---

Wed Jan 20 14:56:24 UTC 2021 - Fabian Vogt [email protected]

• Actually drop the call of baseCleanMount

Since "(Repositories) include our OBS repo in the final image. Fixes #9 #11" we have at least one additional repository. All our previous image repositories had their GPG keys auto imported. It is proposed that we do, like-wise, with these newly added repos.

Package repositories in question:

added by referenced pr:

• https://build.opensuse.org/package/show/home:rockstor:branches:Base:System/systemd-presets-branding-rockstor

due to be added, and image persistent, in "Prototype ARM64 EFI build (also Ten64) (#7) #8"

• https://build.opensuse.org/project/show/home:mcbridematt

The former is a subproject of the official Rockstor OBS.
The latter is another OBS repo managed by @mcbridematt of Traverse Technologies who are an Arm64 Rockstor partner.

Note that the latter is likely to be replaced, as per comments in the referenced pr, with another obs repo. The associated key should be changed when that repo change takes place.

Without these keys being pre-added, see the existing rpm --imports within config.sh, we get the following indicator on requested zypper actions:

installerarm64efi:~ # zypper info systemd-presets-branding-rockstor
Retrieving repository 'home_rockstor_branches_Base_System' metadata ------------------------------------------------------------------------------------------------------------------------[\]

New repository or package signing key received:

  Repository:       home_rockstor_branches_Base_System
  Key Name:         home:rockstor OBS Project <home:[email protected]>
  Key Fingerprint:  701B4521 E8F34B2E 68876430 798A6926 FBE3ABFF
  Key Created:      Wed 30 Jan 2019 11:45:56 GMT
  Key Expires:      Fri 09 Apr 2021 12:45:56 BST
  Rpm Name:         gpg-pubkey-fbe3abff-5c518e74


Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r):

Rendering these repositories inactive until such registration takes place.

Current workaround:

zypper --non-interactive --gpg-auto-import-keys refresh

The currently imported gpg public keys are as follows:

rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n'

gpg-pubkey-307e3d54-5aaa90a5    gpg(SuSE Package Signing Key <[email protected]>)
gpg-pubkey-39db7c82-5847eb1f    gpg(SuSE Package Signing Key <[email protected]>)
gpg-pubkey-3dbdc284-53674dd4    gpg(openSUSE Project Signing Key <[email protected]>)
gpg-pubkey-5f043187-5ed2a099    gpg(The Rockstor Project (Rockstor Development) <[email protected]>)
gpg-pubkey-17280ddf-5a631c69    gpg(network OBS Project <[email protected]>)
gpg-pubkey-b91e1e8b-5be66216    gpg(shells OBS Project <[email protected]>)

As per this thread: https://forum.rockstor.com/t/problem-building-rockstor-4-with-vagrant/7639 the specified vagrant box for the installer is failing to mount shared folders.

eg.

Currently the following repo is used during installer image build but not included in the final installer; this looks to be an error of omission and may hinder / overly complicate distro updates in the future:

https://build.opensuse.org/package/show/home:rockstor:branches:Base:System/systemd-presets-branding-rockstor

An Indication of it's requirement is seen in the distro update 'walk through' recently posted on our forum:

https://forum.rockstor.com/t/btrfs-balance-error/7261/4

Where, without the inclusion of this repo, the resulting:

zypper dup --no-recommends --download-in-advance

post sed update of repo variants, results in the removal of our systemd-presets-branding-rockstor package.

Current workaround is to add this repo accordingly to the post sed edited repos prior to a Distribution update. And for the example Leap 15.1 (dev only) to our proposed re-launch base of Leap 15.2 (an arrangement assumed to mimic the comming Leap 15.2 -> Leap 15.3 distro update) we have:

zypper --non-interactive addrepo --refresh -p97 http://download.opensuse.org/repositories/home:/rockstor:/branches:/Base:/System/openSUSE_Leap_15.2/ home_rockstor_branches_Base_System
zypper --gpg-auto-import-keys ref

And the proposed kiwi-ng config fix is to simply add the 'imageinclude="true"' potion to all occurrences of this repo definition within rockstor.kiwi.

It has been observed that when installing on a system that already has a Rocsktor install on another disk, the resulting installer will:

1: fail to run the JeOS first boot wizard (Locale, Keyboard Layout, License Agreement, Time Zone, 'root' user pass).
2: fail to start the Rockstor services as Postgresql is not auto started.

This looks to be caused by some systems reading their config from the already existing Rockstor install and thus failing to invoke themselves on the fresh install.

Fix: re-install with the offending prior Rockstor system drive removed, or wiped.

We currently use an http 'legal' link that is now https hosted due to:
rockstor/rockstor-core#2226
Plus we have a hard-coded liability amount: tie this to the first years paid subscription as that was the original intent with the currently given amount. This also allows us to vary our subscription for different countries/currencies in line with what may be appropriate going forward.

Note that these updates must also be reflected in our website repository as it, in turn, has a copy of the resulting EULA post edits performed by the installer build process.

At install/first boot we present the following message:

Your Web-UI should be available directly after:
"[ OK ] Started Rockstor bootstrapping tasks."
appears below.

This is incorrect as it should read:

Your Web-UI should be available directly after:
"[ OK ] Finished Rockstor bootstrapping tasks."
appears below.

There is also not exact match for "[ OK ] Started Rockstor bootstrapping tasks." but we do have a near match of:

 Started Rockstor bootstrapping tasks.

This message is defined in our root file additions in the following file:
root/etc/issue

This change is deemed important as it is one of the very first messages that informs the user that there will likely be a small delay between the presentation of the login screen and the availability of the Web-UI. On slower hardware such as the Pi4 this delay is significant.

We currently have all 15.2 profiles as "Current" and 15.3 as "In-Development". It is proposed that we now promote our 15.3 profiles to the "Current"/"Core" status. This is as a result of the 15.3 profiles now having had a fair amount of 'field' testing (> 5 months) and there having been no significant negative feedback. And in view of the need to move forward on our recommended base OS and to actively observe the relevant EOL status. OpenSuse Leap 15.2 is due to reach end of life in November/December this year (2021). At which point, soon thereafter, we will likely remove the associated profiles as we did with the now EOL 15.1: "Remove Leap15.1 profiles" #21 (September 2020).

This is to support 64-bit ARM systems that implement the Embedded Boot or [https://github.com/ARM-software/sbsa-acs](Server boot) standard - the basic gist is that these systems follow a PC style boot flow using EFI and (typically) Grub2.

With some tweaks it might be possible to use this for the Raspberry Pi 3 and 4 as openSuSE embeds a copy of U-Boot to implement EFI - in which case we can have just one aarch64 image.

I haven't named it after my system (Ten64) as there are wider applications such as virtual machines -in fact all the systems I am running in "production" at the moment are running as VMs, but the resulting image will work on the Ten64 and other supported boards "bare metal" as well.

This is another follow-up to #49.
Currently, we define the NTP servers for chrony to use while building the installer as follows:

However, Leap 15-3 JeOS now uses a much more streamlined setup using SUSE NTP pool:

#=====================================
# Enable chrony if installed
#-------------------------------------
if [ -f /etc/chrony.conf ]; then
	suseInsertService chronyd
fi

This results in:

# ls -lah /etc/chrony.d/pool.conf
-rw-r--r-- 1 root root 32 May 27  2020 /etc/chrony.d/pool.conf

... defining the SUSE pool:

# cat /etc/chrony.d/pool.conf
pool 2.suse.pool.ntp.org iburst

Interestingly, this file is provided by:

# zypper se --provides /etc/chrony.d/pool.conf
Loading repository data...
Warning: Repository 'Update Repository (Non-Oss)' appears to be outdated. Consider using a different mirror or server.
Reading installed packages...

S | Name                 | Summary                                | Type
--+----------------------+----------------------------------------+--------
  | chrony-pool-empty    | Empty pool preconfiguration for chrony | package
  | chrony-pool-openSUSE | Chrony preconfiguration for openSUSE   | package
i | chrony-pool-suse     | Chrony preconfiguration for SUSE       | package

... which itself was installed as part of chrony, I believe:

# zypper info chrony-pool-suse
Loading repository data...
Warning: Repository 'Update Repository (Non-Oss)' appears to be outdated. Consider using a different mirror or server.
Reading installed packages...


Information for package chrony-pool-suse:
-----------------------------------------
Repository     : Main Repository
Name           : chrony-pool-suse
Version        : 3.2-9.21.1
Arch           : noarch
Vendor         : SUSE LLC <https://www.suse.com/>
Installed Size : 32 B
Installed      : Yes (automatically)
Status         : up-to-date
Source package : chrony-3.2-9.21.1.src
Summary        : Chrony preconfiguration for SUSE
Description    : 
    This package configures chrony to use the SUSE NTP server pool by
    default.

It's interesting to see it pulls down chrony-pool-suse and not chrony-pool-opensuse... another way Leap and SLE are getting closer?

In some circumstances, mainly developmental, it is desirable to have an installer with the very latest kernel. It is proposed that we add a remarked out section to enable this that references the relevant additional repositories i.e.:

https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-tuning-multikernel.html#sec-tuning-multikernel-latest

However we must be clear, via comments in this new section, that this is likely a breaking change.

It would also be nice if we could accompany this change with a similarly positioned btrfs-progs resource. However this may be spun off in it's own issue. Previously our early Tumbleweed profiles addressed this developer niche but with the dropping of python 2 in that distro variant we must first address issue rockstor/rockstor-core#1877 before we can again entertain maintenance on that profile.

Currently, I am attempting to build inside an openSuSe 15.2 lxc on proxmox.

A lot happens but fails looking for stdout.

Would this even be possible? Does the container need to ran as root (not unprivileged in promox speek)

Would a vm work?

Does the building OS have to be bare metal?

I read the readme but the term discrete OS puzzled me.

Both our Leap 15.2 and Leap 15.3 based Pi4 profiles express extreme log spam when booting from USB with an empty sdcard slot. This is a know upstream issue that also has associated CPU load:

"mmc0: timeout waiting for hardware interrupt (without SD card)": raspberrypi/linux#3092
and the later linked:
"Mute SDHCI REGISTER DUMP": raspberrypi/linux#3657

It is proposed that we add, via the extraconfig.txt mechanism referenced in confgi.txt:

# Get more options/information on http://elinux.org/RPiconfig
# or on https://www.raspberrypi.org/documentation/configuration/config-txt.md
#
# !!!!! This file will get overwritten by updates. Please use !!!!!
# !!!!! extraconfig.txt if you want to set additional !!!!!
# !!!!! configuration options or add dt overlays. !!!!!

The following config item to address this:

dtparam=sd_poll_once=on

With the pending release of openSUSE Leap 15.3 (beta currently) the time is nigh for adding the relevant architecture profiles.

https://en.opensuse.org/openSUSE:Roadmap#Schedule_for_openSUSE_Leap_15.3

In line with an earlier update which moved us from 4.0.0-0 to 4.0.4-0, along with some more recent encouraging reports of folks experience on the forum with this latest version, it is proposed that we now default to using the 4.0.7-0 rpm. This also side steps fresh installs from the resulting installers having to upgrade from the prior unmaintained ztaskd to the new huey task manager (in 4.0.6-0). This was a very significant core subsystem dependency update that would be best built-in from the start. See:

"Replace orphaned django-ztask with Huey ..." rockstor/rockstor-core#2283

Further we have a key bug fix related to changes in our upstream kernels in the CentOS to openSUSE move relating to the case of the reported product uuid / Application ID:

"Fake Product UUID Case Sensitivity Incorrect on Rockstor 4 ..." rockstor/rockstor-core#2300
issue: rockstor/rockstor-core#2290

This in turn will help to alleviate a further tripping-point with regard to transitioning earlier CentOS initiated Stable Subscriptions over to a newer Rockstor 4 "Built on openSUSE" install: without the need to edit the Appliance ID in Appman. It also fixes the detection of fake Product uuids: previously working in Rockstor 3 but broken in Rockstor 4. A key enabler that can currently only take place during a fresh install. Again avoiding pain points/paper cuts with getting up and running easily.

The referenced 4.0.0-0 to 4.0.4-0 change was enacted in the following pr:
#35

Thanks originally to @mikemonkers and to forum member GeoffA for highlighting potentially missing packages.

It seems that some official Leap 15.2 images for the Pi4 and some Vagrant images do not have, pre-installed, the following requied packages:

btrfsprogs
gfxboot

With these packages not installed the resulting .raw file is incomplete and will fail to build. This is easier to spot in the x86_64 world as there is then no ISO that is expected. But in the Pi4 profile, where the *.raw is all that is expected, it is required to delve into the

/home/kiwi-images/build/image-root.log 

log file to find these failures.

Several of the convenience functions present in config.sh, including some that we currently use, have recently been deprecated:
OSInside/kiwi#1833

From this PR, I identify only suseImportBuildKey() as being a function we currently use and that will be deprecated in a future kiwi-ng release. As the new code mentions, though, this seems to now be taken care by kiwi so we might be able to simply remove the call to suseImportBuildKey in our config.sh:

function suseImportBuildKey {
    deprecated "${FUNCNAME[0]}" <<- EOF
	This is done by kiwi at call time of zypper
	EOF
}

https://github.com/OSInside/kiwi/blob/c40f44d9f681f80449d088b18c1d3f3a2d4f3316/kiwi/config/functions.sh#L814-L818

Update the default version to our latest Stable release candidate 9 (4.0.8-0) which includes an important http-> https change on the rock-ons that may fix Rock-on refresh function for those on slow networks:
https://forum.rockstor.com/t/beta-built-on-opensuse-testing-channel-changelog/7097/15

In some cases, where the suggested pre-edit suggestion is skipped, the current resulting image results in inelegant and uninformative installer image names, e.g,:

Rockstor-.x86_64-4.0.0-0.install.iso

and similarly named Grub entries thus:

*Boot from Hard Disk
Install Rockstor-
Failsafe -- Install Rockstor-

and likewise strangely texted raw image progress screen of:

Loading Rockstor-.raw

The intention of the suggested pre-edit it to label the resulting image according to it's base OS (usually Leap 15.2 currently) and it's target, ie x86_64 or RaspberryPi4 so that the resulting installer images will turn out like the following examples:

Rockstor-Leap15.2-mycustom.x86_64-4.0.0-0.10.install.iso
Rockstor-Leap15.2-RaspberryPi4.aarch64-4.0.0-0.raw
Rockstor-Leap15.2-ARM64EFI.aarch64-4.0.0-0.8.qcow2

With the above also indicating changes in version number.

However if the suggested edits are not done, we should default to something more meaningful and this also helps with keeping automation contributions simple and removes the minimum number of required steps. And avoids us having to pop in yet another scripted layer that might otherwise introduce further dependencies (bash / sh etc.) and obfuscate the minimum required opperations.

This issue propose that we substitute the existing, placeholder text of "Rockstor-" with "Rockstor-NAS" as at least then installer built with zero customisation are still at least a little less inelegant. We loose the OS base flavour info with this approach but that is relatively unimportant given any official images will be labelled accordingly. And the resulting installer and it's consequent installed instance still advertises the 'Build on ' distro variant.

Hey all

So I built the installer with 15.2 Leap in a vagrant box but had some errors building the image due to missing commands.

The command
kiwi-ng --profile=Leap15.2.x86_64 --type oem system build --description ./ --target-dir /home/kiwi-images/
Failed a couple times due to missing commands. I got the build to work after installing these packages:
qemu-tools
gptfdisk
e2fsprogs
squashfs
xorriso

As per our #21 "Remove Leap15.1 profiles" Leap 15.2 is now past EOL, see: https://en.opensuse.org/Portal:15.2 (31st December 2021). Given this recently changed status it is proposed that we now remove all profiles based on Leap 15.2.

This is in the context of a dependency on the resolution of issue:

Promote 15.3 profiles given 15.2 approaches EOL #81

Requires #81

Which in-itself has further dependencies.

As of Leap 15.3 there are 2 additional repositories that are auto added on a new opensuse Leap 15.3 install. In our existing Leap 15.3 profiles these are implicitly added but as we don't specify them during the installer build the resulting install has a tone of updates pending. This is sub-optimal and not in line with our prior Leap 15.2 profile experiences.

It is proposed that we add, for the duration of the build only, these two new repositories so that the resulting installer can be build with the available updates at the time of build. It is also then clearer where we are sourcing our packages for the build.

See: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/#installation-new-update-repos

We can then leave the existing mechanism to instate these repositories in the final installer, along with their debug (disabled) counterparts so that we at least stick more closely with upstreems current way of adding these repos. And to avoid a potential conflict if we instate them in the resulting installer image and the existing mechanism then tries to re-instate them. I.e. we omit the:

imageinclude="true"

property. Such as we currently do with the "Rockstor-Testing" repo as we only want that to be instated by the users action but we need it to get our initial specified version of the 'rockstor' package. Likewise with our "kiwi" repo which is needed for the installer image build only, and not required in the final installer image.

This move also ties into being more explicit with the repos used/expected in the installer-builder/resulting-installer

Linking to a related documentation issue in the same area:
"Update FAQ Rockstor 4 repositories section" rockstor/rockstor-doc#300
which contains the details of the actual repos our resulting installs end up with from our existing Leap 15.3 profiles.

Thanks to NiTRO Boy via support email for highlighting our lack of infiniband support in our installer. Apparently we did have infiniband capabilities in our now legacy v3 CentOS based offering.

The ibutils package is assumed to provide the required functionality:

rleap15-3:~ # zypper in ibutils
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 7 NEW packages are going to be installed:
  ibutils libibdm1 libibumad3 libopensm9 libosmcomp5 libosmvendor5 tcl

7 new packages to install.
Overall download size: 3.6 MiB. Already cached: 0 B. After the operation, additional 16.9 MiB will be used.
Continue? [y/n/v/...? shows all options] (y):

And so the cost size looks to be an additional 17 MB.

It is proposed that we add this to our installer package list so that this facility is available immediately on install.

Thanks to forum member smokku for highlighting this issue via support email. Network manager is unable to enact a team network setup due to a lack of capabilities on the teamd deamon. The suggested fix was as follows:

I needed to create
/etc/systemd/system/NetworkManager.service.d/caps.conf
with the following contents:

[Service]
CapabilityBoundingSet=CAP_CHOWN

It is proposed that we add this file to our root overlay (those files within our /root directory) so that Network manage is awarded these additional capabilities.

Currently our RaspberryPi4 & ARM64EFI profile variants (Leap 15.2/15.3) set an EFI partition size of 64 MB, where as our x86_64 profile variants set a size of 33 MB. It is proposed that we normalise on the safer-bet of 64 MB especially given our Rockstor 4 recommended minimum system disk size of 16GB. The Pi4 and presumably also the ARM64EFI profiles do put more stuff in these partitions but it is still proposed that standardising on say 64 MB would be cleaner and safer and potentially provide less confusion for those adding new profiles and looking to the existing profiles for guidance.

Our in-repo instructions should be as accessible as possible and they currently assume "git clone" knowledge. There is not good reason for this, i.e. it is not a pre-requisite for DIY NAS enthusiasts like say how to attache a SATA drive is. As such this issue proposes to add a simple short 'config retrieval' section to address this omission in our README.md file so that improve our accessible outside of those already familiar with git and other more developer orientated tools.

At the end of the initial install process we are greeted with the following:

Welcome to Rockstor built on openSUSE - Kernel 5.3.18-lp152.36-default (ttyAMA0).

Your Web-UI should be available directly after:
"[ OK ] Started Rockstor bootstrapping tasks." appears below.

First login here as the 'root' user for further instructions.

Enter key for a new login prompt.

Although this is already long, it is proposed here that we split the "Your Web-UI ..." section thus:

Your Web-UI should be available directly after:
"[ OK ] Started Rockstor bootstrapping tasks."
appears below.

as this makes it easier, at a glance, to pick out the key quoted systemd line, and only adds one more line to the existing output.

We have recently encountered at least a couple of failures related to our stance in disabling IPv6. The first and currently most significant was in a recent upstream docker update to version: 20.10.6
"Docker 20.10.6: all containers stopped and cannot start if ipv6 is disabled on host"
moby/moby#42288
The second is in our ability to instantiate/configure, via the Web-UI, a teaming/bonding interface reported by forum member Emmanuel_perez in the following forum post:
"Issues when trying add Teaming to Rockstor network "
https://forum.rockstor.com/t/issues-when-trying-add-teaming-to-rockstor-network/7913

We originally disabled IPv6 via yast2 which in turn edits /etc/sysctl.conf file. But this, ironically now, in turn caused a docker and postfix issue:
rockstor/rockstor-core#2139 (comment)
when no IPv6 config was assigned/available to the loopback and ethernet interfaces and services still attempted to use them.
So we moved to disabling via the kernel command line and tweaked our postfix (email notifications) to use only IPv4.
See part of "[openSUSE] fix postfix config re ipv4, tlsmgr, & CA file settings. ...":
rockstor/rockstor-core#2135
"Enforce "inet_protocols = ipv4" in postfix if a prior 'all' setting is found. This avoids postfix service failure on ipv4 only systems."

The original intention for our move to disable IPv6, system wide, was as follows, from: rockstor/rockstor-core#2139 (comment)

[Our] intention [in disabling IPv6 is down to:] ... our Web-UI can only configure for ipv4 so we should, with our appliance aim, ensure the entire system is only using ipv4. Otherwise there are network configurations at play that were not intended by our users. I had initially though that the Yast suggestion in the dev notes would be sufficient.

& from @tyukh in the same issue:

Since I am not a maintainer, I can only give my opinion. IPv6 is not used, has not been tested, and is completely unsupported in Rockstor codebase. Because of this, enabled IPv6 can cause potential problems and strange behavior.
For example, the configuration for a some service may have IPv6 settings (e.g. interface binding) that Rockstar does not expect and process.

However we now have complete dysfunction of Rock-ons (our docker based plugin system) due to the above sited upstream docker bug that has been acknowledged & fixed in the docker development team:
moby/moby#42413
but not backported to our Leap 15.* base for a few weeks now. Likely as a default Leap install is not affected by this issue.

Docker 20.10.7 does now have this fix in place: https://docs.docker.com/engine/release-notes/#20107

But given we have the following very similar issue from dockers history (in 2016):

- Fixed a bug which prevents docker reload when host is configured with ipv6.disable=1 ([#21019](https://github.com/docker/docker/pull/21019))

We may well now be swimming against the tide and would be best advised to drop our non standard grub config which was not favoured at the time but found to be the only 'fix'. From: rockstor/rockstor-core#2139 (comment)

I think I'd rather go the sysctl route as we already do some editing there in initrock I believe where as we currently don't mess with grub and I'd rather leave it that way if possible.

So we are left with the hard choice of removing our hard disable of IPv6 simply due to the repeat issues found in software we absolutely depend upon simply not any longer being familiar with OS's in our current state. And returning to our prior multi year setting of not disabling but also not configuring IPv6 at all. At least until we do add this non trivial capability anyway.

Comments and alternative options welcome.

Correct path in run_kiwi.sh file and update Readme for MS-windows (without bash) commands.

as per installation experience described on the forum:
https://forum.rockstor.com/t/problem-building-rockstor-4-with-vagrant/7639/14?u=hooverdan

This is a minor issue, but almost tripped me up. In the instructions for editing rockstor.kiwi, it says to change any lines preceded by "<!-- Change to" but only the first line that needs to be changed has "<!-- Change to". The following four lines (52, 107, 158, and 459) have "<!--Change to" (missing the space between the - and C). When I opened it up in vim to make the changes, I searched for the entire string, and probably wouldn't have noticed there were lines left out if there were more than one entry to change from that search result.

Tried compiling per instruction in README on Leap15.2 running on a Pi4.

kiwi-ng --profile=Leap15.2.RaspberryPi4 --type oem system build --description ./ --target-dir /home/kiwi-images/

Resulting with the following error
[ ERROR ]: 20:16:51 | KiwiInstallPhaseFailed: System package installation failed: No provider of 'raspberrypi-eeprom' found.

Adding the following repository to rockstor.kiwi allowed build to finish successfully...

https://download.opensuse.org/repositories/hardware:/boot/openSUSE_Factory_ARM/

Thanks to forum member papaskitch for reporting this requirement. Apparently for the Pi400's built in keyboard to work it is required to use at least a 15.3 profile. It is proposed that we make a small note in the readme to indicate this to avoid folks running into this same issue while our Leap 15.2 profiles still exist.

Contextual forum reference: https://forum.rockstor.com/t/failed-to-delete-the-share-tm-error-from-the-os-failed-to-mount-pool-seagate-due-to-an-unknown-reason-command-used-usr-bin-mount-dev-disk-by-label-seagate-mnt2-seagate/7921/4

Our Ten64 specific repository used as part of the ARM64EFI profile could do with a link to it's OBS repo overview page:

https://build.opensuse.org/project/show/home:mcbridematt

That way folks could more easily lookup it's contents.

Thanks to @mikemonkers in the following forum thread for helping to highlight a lack of clarity on our part re OS requirements for our bare kiwi-ng method. We could also improve our 'Marks' user compliance re:
https://en.opensuse.org/openSUSE:Trademark_guidelines
in the following existing excert of the Readme:

Given our image target OS is exclusively openSUSE, a Leap 15.1 or 15.2 install is recommended as the host operating system.

Which should, by my initial reckoning in the sited forum thread, read "Built on openSUSE".

Referenced forum thread:
https://forum.rockstor.com/t/problem-building-rockstor-4-with-vagrant/7639/13

I am more than likely missing something very basic here being all new to kiwi-ng. I am trying to create an iso for RaspberryPi4 using the following command on a x86_64 machine with qemu installed

./kiwi-env/bin/kiwi-ng --debug --target-arch=aarch64 --profile=Leap15.2.RaspberryPi4 --type oem system boxbuild --box leap -- --description ./ --target-dir ./images

please note the --target-arch=aarch64 option

The complete log of the above command is here https://gist.github.com/daya/189a838eeb119117a47cc09241895d13

But the most important info is on line 361
[ ERROR ]: 18:37:33 | KiwiProfileNotFound: profile Leap15.2.RaspberryPi4 not found for host arch x86_64

What I am unable to understand is why does kiwi-ng uses qemu-system-x86_64 when it should be using qemu-system-aarch64 as I am using the global option --target-arch=aarch64

1:52p ~/D/r ✨master* ➤ qemu-system-aarch64 -cpu help                                                                                                                                                                                                                                                                                                       
Available CPUs:
  arm1026
  arm1136
  arm1136-r2
  arm1176
  arm11mpcore
  arm926
  arm946
  cortex-a15
  cortex-a53
  cortex-a57
  cortex-a7
  cortex-a72
  cortex-a8
  cortex-a9
  cortex-m0
  cortex-m3
  cortex-m33
  cortex-m4
  cortex-m7
  cortex-r5
  cortex-r5f
  max
  pxa250
  pxa255
  pxa260
  pxa261
  pxa262
  pxa270-a0
  pxa270-a1
  pxa270
  pxa270-b0
  pxa270-b1
  pxa270-c0
  pxa270-c5
  sa1100
  sa1110
  ti925t

Any help is much appreciated as I am stuck on this for few hours now.

On some low power devices, i.e Pi4 / Ten64, and slower/older x86_64 machines, the default Network Manager wait online service leaves insufficient time before 'declaring' to it's dependants that no online state is available. This false negative on online status can lead to dependants, i.e. KVM installs or Hashicorp Vault instances, failing to start as their dependency of online state was not indicated.

The proposed fix is to increase the default wait setting for the NetworkManager-wait-online service.

The service derives it's timeout setting from the following parameter:

## Type:        int
## Default:     30
#
# When using NetworkManager you may define a timeout to wait for NetworkManager
# to connect in NetworkManager-wait-online.service.  Other network services
# may require the system to have a valid network setup in order to succeed.
#
# This variable has no effect if NetworkManager is disabled.
#
NM_ONLINE_TIMEOUT="30"

in /etc/sysconfig/network/config

some experimentation has indicated that a setting of 45 seconds looks to resolve the observed failures.

Thanks to forum member ktraglin for reporting the following broken Pi4 profile: "Leap15.2.RaspberryPi4".

Using Rockstor 4 Installer Recipe (RaspberryPi4) from github.

I’ve tried to build the installer using a fresh install of:
openSUSE-Leap-15.2-ARM-JeOS-raspberrypi4.aarch64-2020.07.08-Build1.147.raw.xz

as well as a more recent one released this month:
openSUSE-Leap-15.2-ARM-JeOS-raspberrypi4.aarch64-2020.07.08-Build1.163.raw.xz

I’ve tried several times to build the installer, but keep getting these errors:

[ INFO ]: Processing: [########################################] 100%
[ ERROR ]: 21:53:04 | KiwiInstallPhaseFailed: System package installation failed:
[ INFO ]: 21:53:04 | Cleaning up SystemPrepare instance
localhost:~/rockstor-installer #

Some of the more interesting debug messages (from “/home/kiwi-images/build/image-root.log”) are as follows:

DEBUG: 23:03:59 | system: Resolving package dependencies…
DEBUG: 23:03:59 | system: 2 Problems:
DEBUG: 23:03:59 | system: Problem: nothing provides libc.so.6(GLIBC_2.33)(64bit) needed by shellinabox-2.20+git.1548649128.4f0ecc3-3.20.aarch64
DEBUG: 23:03:59 | system: Problem: nothing provides libc.so.6(GLIBC_2.33)(64bit) needed by shellinabox-2.20+git.1548649128.4f0ecc3-3.20.aarch64
DEBUG: 23:03:59 | system: Problem: nothing provides libc.so.6(GLIBC_2.33)(64bit) needed by shellinabox-2.20+git.1548649128.4f0ecc3-3.20.aarch64
DEBUG: 23:03:59 | system: Solution 1: do not install shellinabox-2.20+git.1548649128.4f0ecc3-3.20.aarch64
DEBUG: 23:03:59 | system: Solution 2: break shellinabox-2.20+git.1548649128.4f0ecc3-3.20.aarch64 by ignoring some of its dependencies
DEBUG: 23:03:59 | system: Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] ( c ): c
ERROR: 23:03:59 | KiwiInstallPhaseFailed: System package installation failed:
localhost:~/rockstor-installer #

Please see the following forum thread for context:
https://forum.rockstor.com/t/beta-installer-build-fails-on-raspberrypi4/7710

Issue author has also seen this and the last know successful build of this profile within the closed beta builds of our ISO was at the release of the 4.0.5 rpm:
https://forum.rockstor.com/t/beta-built-on-opensuse-testing-channel-changelog/7097/12

A small, non-breaking typo in the README.md instructs to using the Leap15.1 profile rather than Leap15.2 as the header of the section describes.
https://github.com/rockstor/rockstor-installer#leap152x86_64-profile

Although both are valid, we might want to fix this typo for consistency.

This issue is a follow-up to #49.

In the upstream kiwi recipe, we can see the following changes related to the Leap15.3 profile for Raspberry Pi:

Tue Feb 9 14:34:11 UTC 2021 - Nicolas Patricio Saenz Julienne [email protected]

• Install 'raspberrypi-eeprom' package on Raspberry Pi image (jsc#SLE-13566)

https://build.opensuse.org/package/view_file/openSUSE:Leap:15.3/kiwi-templates-JeOS/kiwi-templates-JeOS.changes?expand=1

Accordingly, the <packages> specific to the Raspberry Pi profile are:

    <packages type="image" profiles="RaspberryPi">
        <package name="raspberrypi-eeprom" arch="aarch64"/>
        <package name="raspberrypi-firmware" arch="aarch64"/>
        <package name="raspberrypi-firmware-config" arch="aarch64"/>
        <package name="raspberrypi-firmware-dt" arch="aarch64"/>
        <package name="u-boot-rpiarm64" arch="aarch64"/>
        <package name="dracut-kiwi-oem-repart"/>
        <package name="kernel-default"/>
        <!-- For WiFi: -->
        <package name="jeos-firstboot-rpiwifi"/>
        <package name="bcm43xx-firmware"/>
    </packages>

https://build.opensuse.org/package/view_file/openSUSE:Leap:15.3/kiwi-templates-JeOS/JeOS.kiwi?expand=1

In our rockstor.kiwi, we currently have:

I can thus see the following differences:

1. raspberrypi-eeprom is missing in our current rockstor.kiwi recipe. It should be added.
2. kernel-firmware is present in our rockstor.kiwi but not in upstream kiwi recipe. @phillxnet , I'm not familiar with the requirement for this package, so I assume you added it for a good reason.
3. jeos-firstboot-rpiwifi is missing in our current rockstor.kiwi recipe and should probably be added.

Number 1 and 3 should be safe to add... I'm hesitant about removing number 2, though, as it was most likely added for a good reason.

When using more recent versions of kiwi-ng there is an apparent regression where the resulting Rockstor install no longer displays the intended "Rockstor-NAS" / "Rocsktor-Leap15.2-RaspberryPi4 [ OEM ]" etc grub boot options, depending on if the suggested edit of "name=" was carried out.

The issue has been tracked down to a change in behaviour of kiwi-ng itself. An exemplary and informative run down on why this is now the case is available via the upstream issue opened to investigate this change in behaviour:

"Regression in Grub menu options - user text - oem"
OSInside/kiwi#1575

An example of a possible work around for this change in behaviour was provided.

I am opening this issue to track our progress in applying said workaround so that we might restore our own 'label' as "openSUSE" used in this context, although functionally only cosmetic, is likely not to be compliant with openSUSE Trademark guidelines:

https://en.opensuse.org/openSUSE:Trademark_guidelines

If you are able to advise on this specific "Marks" use/issue then please chip in here. Otherwise this issue is likely a blocker for our planned installer download availability, and as such will receive priority attention as we near our first "Build on openSUSE" stable channel release.

The upstream kiwi templates for various versions of JeOS Leap have now seen several small updates that might deserve some attention to see whether these should be merged (in an attempt to follow upstream as much as possible). In particular, several of these changes target the Raspberry Pi4 profile, as mentioned in #48 (comment)

@phillxnet, I am using the following Leap 15.3 JeOS kiwi template as reference (as this one seems to be the upstream repo for their appliances images, if I'm correct):
https://build.opensuse.org/package/show/openSUSE:Leap:15.3/kiwi-templates-JeOS

Changes would include updates to:

• kiwi recipe itself (rockstor.kiwi)
• config.sh

@phillxnet, before discussing the changes themselves, I wanted to make sure we were on the same page with regards to which repo to use as reference. Even thought they don't really differ in their contents, it seems important to cautiously choose our "reference" to track so that we stay coherent. The Leap 15.3 JeOS template above includes profiles for all the openSUSE "appliance types" and is the upstream repo (apparently) so it seems like a good choice.

During especially boot issue diagnostics we could do with one or two more little tools included by default. We are based on a JeOS (Just enough Operation System) effort from upstream and so contain mainly just rockstor dependencies beyond the upstream JeOS. It is proposed that we add the following tools by way of easing boot diagnosis:

• tree - 109.8 KiB (Tree is a recursive directory listing command...)
• pesign - 431.8 KiB (Signing tool for PE-COFF binaries ...)
• ntfs-3g - 4.1 MiB (userland ntfs but likely redundant post Leap 15.4 however)

Our top level readme, which will be seen by most folks, needs to be updated to acomodate for our dropping the Ten64 profile in preference for the more generic ARM64EFI. We should also now reference our newly added vagrant 'wrapper'.