Skip to Content
Technical Articles

Adjusting installer script for SAP NetWeaver Dev Edition for distros with kernel version 5.4 or higher

Intro

 

At the time of writing (June 2021), openSUSE Leap (15.3) had a Linux kernel version of 5.3.x. So if you intend to install SAP NetWeaver Dev Edition using the “official” SAP guides, which are based on the openSUSE Leap 15 distro, then you probably won’t need the script modifications in this blog, instead your installation should run smoothly and you have your own SAP instance on your local machine, so that’s all good. (If a future release of openSUSE Leap contains e.g. a 5.4.x kernel or higher, then this blog might become useful to you).

The downloaded rar files (which you can get from here), when extracted, contain brief generic instructions. The more detailed SAP guides for installing on openSUSE Leap are available here and here. The SAP community has a few blogs explaining how to install the Dev Edition on Ubuntu, for example one of mine is here. This blog assumes you are reasonably familiar with the install process for SAP NetWeaver Dev Edition.

[One general piece of advice though: whichever distro you are using, in 2021 it’s good to be aware, that you need to get the newer Sybase license from the downloads site, extract (unrar) it, rename it to “SYBASE_ASE_TD.lic”, and put it in the subdirectory ./server/TAR/x86_64/ … also you should delete the out of date .lic file, so as not to confuse Sybase].

Anyway, this blog is going to consider – and solve 😀… using simple bash script modifications – two problems that you can run into, when using Ubuntu (and possibly some other distros) as the base distro for the SAP system installation.

[I suppose it could be that in future, SAP corrects its installer script based on this blog, in that case the below will only be a minor footnote in the history of computing]. The current bugs are as follows:

Main script exits when using saphostexec, even though “nothing is wrong” 🤔.

Starting Sybase ASE database when the Linux kernel version is >=5.4 …doesn’t work 😱.

Solving these will be easy for you, because in the blog I give the code changes needed, and you just implement those by copy-pasting, then run the enhanced installer script, and your SAP system installation succeeds – by the way, here is what script-modified success looks like:

So, let’s get these minor bugs solved, shall we? You can either read the blog through for a longer discussion, or if you know what you are doing and just want the code, then jump to the Appendix.

 

Get the main installer script to keep running after executing a saphostexec command…

So when running the main installer script “install.sh”, in the function server_install() after extracting a load of files, the script then moves into the directory /tmp/hostctrl and executes the command:

./saphostexec -install || do_exit $ERR_install_saphost

Though this isn’t a tutorial on bash scripting syntax, the “||” means “OR” in the following sense: if the first part ‘./saphostexec -install’ returns without an error, we’re done here, let’s move on… OR if ‘./saphostexec -install’ fails, then do the other option i.e. exit the whole install.sh run and output an error message defined earlier in the code:

[$ERR_install_saphost]="Could not install saphostexec"

 

When using openSUSE Leap 15.3, this goes as we expect (no error message, main script continues). On Ubuntu 21.04 Desktop version that I used for this blog’s debugging effort, this does not go as we expect: instead, what happens is that the command ‘./saphostexec -install’ returns with no error, but exits the script anyway. [So you can test this yourself, by e.g. putting an ‘echo hello’ command just after the above command for saphostexec: the echo command is not executed, and neither does the defined error message “Could not install saphostexec” appear].

Now one of the nice things about VMs is you can have snapshots, so when something doesn’t work out, you can restore the previous snapshot (in our case: just before running “install.sh”) and have a new installation run. So remember kids to start the uuidd service each time before you run the installer script. So I restored from snapshot, started uuidd, and made a copy of install.sh to work with:

sudo systemctl start uuidd
cp install.sh zimshalabimstall.sh

Then in the new script put a command just before ‘.saphostexec -install’, so as to exit the main script:

exit 0

Then if the new script is not itself executable, make it so, and run that installer script:

chmod +x zimshalabimstall.sh
sudo ./zimshalabimstall.sh

Once it exits, then as the sudoer, manually run the command that would have come next, and afterwards check what exit code we got back from that saphostexec command:

cd /tmp/hostctrl/
sudo ./saphostexec -install
echo $?

So that ran just fine, here is some of the output:

badmin@vhcalnplci:/tmp/hostctrl$ sudo ./saphostexec -install
[…]
[Thr 140600393182144] Executing : useradd -c “SAP Local Administrator” -r -g sapsys -s /bin/false sapadm
Check Installation Path …
ok
Copy Executable …
ok
Generate Profile …
ok
Install SYS-V service …
./installsapinit.sh: 206: chkconfig: not found
[WARNING] installsapinit.sh exit with status 5
-> Start /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile <-
start hostcontrol using profile /usr/sap/hostctrl/exe/host_profile
ok
[OK] SAPHostExec / SAPHostControl succesfully installed
[…]
SAPCAR: rc 0
badmin@vhcalnplci:/tmp/hostctrl$ echo $?
0
badmin@vhcalnplci:/tmp/hostctrl$

So an exit code of 0, in Linux that usually means “Everything is fine”. Now I don’t know why it should be, that in Ubuntu, executing this ‘saphostexec -install’ command in a bash script, causes the bash script to end its processing (if any readers know the root cause, feel free to enlighten us all). However, I have an idea how we can solve this issue – by executing the command with the ‘&’ character added, so that in effect we execute the command asynchronously, as the ‘&’ character says “do the action stated, but let that happen in a new subshell/process ‘in the background’, while we continue on with our own script’s process”.

One side-effect of this tactic, is that we have no easy way of knowing how long the command takes to execute or even if it was successful, but we are in hackathon mood today, so the only “safety net” code we are going to provide is (a) a wait command in the main script processing, to give the subshell command a chance to complete, and (b) we will comment out the main script’s command that would actually delete the subdirectory /tmp/hostctrl including the saphostexec file in there – so as this is just a load of temporary files, after next reboot they will be gone anyway; while on the other hand if we deleted files that were being used by another process, that could get messy.

So either we restore the VM again (and start uuidd, and copy install.sh to a new installer file), or we manually remove the ‘exit 0’ line from current zimshalabimstall.sh; then we replace the original code:

    ./saphostexec -install || do_exit $ERR_install_saphost

    # TODO: is it ok to remove /tmp/hostctrl?
    cd /
    rm -rf /tmp/hostctrl || log_echo "Failed to clean up temporary directory"

 

with this code:

#Replace this line with one which tries to continue (this) main script using ‘&’:
    #./saphostexec -install || do_exit $ERR_install_saphost
    ./saphostexec -install &

#Wait for a while so that hopefully the asynchronous call ends:
    log_echo "Waiting 30 seconds for asynchronous call to /tmp/hostctrl/saphostexec -install to complete..."
    sleep 30
    log_echo "30 seconds are up, continuing the main script."

    # TODO: is it ok to remove /tmp/hostctrl?
    cd /
#Let's not remove the temporary directory, in case saphostexec command
#is still executing. So commenting out:
    # rm -rf /tmp/hostctrl || log_echo "Failed to clean up temporary directory"

 

You will be better off reading the next section and adding some more code before running the new installer script, but anyway, now if the script is run it can proceed without exiting on saphostexec call:

So, that is our solution for enabling the main script to continue processing while also ensuring the ‘saphostexec -install’ command is called. A bit hacky, but using a decision-workflow of one person asking himself, it got approved because hey, it works. Now let’s move on right away to the second thing, which is about Linux distros with kernel version >=5.4…

 

Adjust an ASE database config file in mid-flight to avoid installation hanging on ASE startup

At first, when trying to install the SAP system with ASE database on Ubuntu, the installation run was hanging at this stage:

INFO 2021-06-03 16:29:44.619 (root/sapinst) (startInstallation) [iaxxbfile.cpp:594] id=syslib.filesystem.aclSetSucceeded CIaOsFile::chmod_impl(3,0755)
Authorizations set for /sybase/NPL/startase_reset_sa.

 

You can wait for hours (tested 🤣), nothing more will happen, so eventually you need to Ctrl+C out of the installation run. “Now what?”… well, I rootled around a bit in that network of networks the cool kids are calling “the Internet”, and found what look like the relevant answers, from Robert Stepanov and Daniel Thrall respectively:

https://answers.sap.com/questions/13185432/docker-installation-of-as-abap-752-sp04-hangs.html

https://answers.sap.com/questions/13386863/i-updated-my-system-and-now-server-is-crahing.html?childToView=13385953

So to summarise their answers: If the Linux kernel version is greater than or equal to 5.4, ASE startup doesn’t work without a config change: and the config change to make it work again, is to include in the appropriate file the trace-flag 11889. It turns out that this config change does indeed solve the problem, so thanks to Robert and Daniel for their informative answers. For people with access to read SAP Notes, there is the related Note 3018138 about the topic, with the Resolution section as follows:

“Resolution
Upgrade ASE to a version where CR 824104 is fixed when fix becomes available

Work-around:
Enable traceflag 11889 in the RUN_<server> file. This traceflag prevents initialization of the “Simplified Native Access Plan (SNAP)” feature buring boot.”

You could always wait for SAP to fix the issue and package the new ASE in the free NetWeaver Dev Edition, but that might be a long wait; so instead of waiting, we will right away just implement the trace-flag workaround in our zimshalabimstall.sh script (where we already have the code above that keeps the script running after calling saphostexec).

By the way, to find out which Linux kernel your current distro you are working with has, here is the command:

uname -r

Result of this command for Ubuntu 21.04 Desktop:

badmin@vhcalnplci:~$ uname -r
5.11.0-18-generic
badmin@vhcalnplci:~$

So with a kernel version of 5.11.x, which is several minor versions forward from 5.4.x, we can expect that the above advice for setting the trace-flag 11889, applies to our case.

Maybe you restore the VM to the state of just before installation, starting uuidd service again. Then add in again to new script zimshalabimstall.sh the above code snippet for working around saphostexec call (which ends with commenting out deletion of /tmp/hostctrl subdirectory); anyway, immediately after that code snippet, we can also add the following new code snippet:

# Now we modify the RUN_NPL executable (executable permissions are for sybnpl user):
FILENPL=/sybase/NPL/ASE-16_0/install/RUN_NPL
if test -f "$FILENPL"; then
    echo "$FILENPL exists. Adding the -T11889 option to config in that file:"
    sed -i 's/NPL.cfg \\/NPL.cfg -T11889 \\/g' /sybase/NPL/ASE-16_0/install/RUN_NPL
    cat $FILENPL
    echo "-T11889 config option added"
    sleep 15
else
    echo "$FILENPL does not exist. Not modifying what doesn’t exist, ontologically seems ok."
fi

Then just run the new installer (if not an executable, make it so using ‘chmod’):

chmod +x zimshalabimstall.sh
sudo ./zimshalabimstall.sh

So the idea here, in the new code snippet, is to use the ‘sed’ utility to modify the file at the appropriate place, adding the trace-flag ‘-T11889’. If you look at the file /sybase/NPL/ASE-16_0/install/RUN_NPL after the ’sed’ command has run, you will find in there the modified line:

-c/sybase/NPL/ASE-16_0/NPL.cfg -T11889 \

I put the ‘sleep 15’ line into the bash script just so I could view the output of the ‘cat’ command for the modified file while the main installer script was running, to check that the code did what it was supposed to ok. In fact I even had time to take a screenshot:

At least for me, these code changes worked fine: the SAP system was installed successfully on Ubuntu, running the enhanced installer script as sudo. I’m not saying my workaround code is the most elegant way to solve the two problems noted in the intro, however I can say that the workaround code got the installation procedure working again, which was nice 🏆.

Appendix – bash script code.

For reference, here are the code snippets combined into one. So in our zimshalabimstall.sh (which is a copy of install.sh) we are replacing the old code:

    ./saphostexec -install || do_exit $ERR_install_saphost

    # TODO: is it ok to remove /tmp/hostctrl?
    cd /
    rm -rf /tmp/hostctrl || log_echo "Failed to clean up temporary directory"

 

with the following code:

#Replace this line with one which tries to continue (this) main script using ‘&’:
    #./saphostexec -install || do_exit $ERR_install_saphost
    ./saphostexec -install &

#Wait for a while so that hopefully the asynchronous call ends:
    log_echo "Waiting 30 seconds for asynchronous call to /tmp/hostctrl/saphostexec -install to complete..."
    sleep 30
    log_echo "30 seconds are up, continuing the main script."

    # TODO: is it ok to remove /tmp/hostctrl?
    cd /
#Let's not remove the temporary directory, in case saphostexec command
#is still executing. So commenting out:
    # rm -rf /tmp/hostctrl || log_echo "Failed to clean up temporary directory"

# Now we modify the RUN_NPL executable (executable permissions are for sybnpl user):
FILENPL=/sybase/NPL/ASE-16_0/install/RUN_NPL
if test -f "$FILENPL"; then
    echo "$FILENPL exists. Adding the -T11889 option to config in that file:"
    sed -i 's/NPL.cfg \\/NPL.cfg -T11889 \\/g' /sybase/NPL/ASE-16_0/install/RUN_NPL
    cat $FILENPL
    echo "-T11889 config option added"
    sleep 15
else
    echo "$FILENPL does not exist. Not modifying what doesn’t exist, ontologically seems ok."
fi

 

Our smoketesting has shown that when we run (as sudo) this enhanced installer script:

chmod +x zimshalabimstall.sh
sudo ./zimshalabimstall.sh

…on Ubuntu (21.04 Desktop) with kernel >=5.4, the installation then completes successfully, due to the code changes.

 

 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.