Technical Articles
Adjusting installer script for SAP NetWeaver Dev Edition for distros with kernel version 5.4 or higher
Intro
UPDATE September 2022: openSUSE Leap 15.4 is using kernel version 5.14.x, so the script in this blog will be needed as a workaround, if you intend to use Leap releases 15.4 or greater!
[At the original time of writing (June 2021), openSUSE Leap (15.3) had a Linux kernel version of 5.3.x. So back then, if you would be installing SAP NetWeaver Dev Edition using the “official” SAP guides, which are based on the openSUSE Leap 15 distros with kernel versions of 5.3.x or lower) then you wouldn’t be needing the script modifications in this blog’s Appendix.]
If you are using openSUSE Leap release 15.4 or higher, then the kernel version will be at least 5.14.x, which is greater than the 5.4.x threshold i.e. you will need the script presented in the Appendix below in order to install SAP NetWeaver Dev Edition 7.52 SP04.
Similarly, most Ubuntu releases (such as 21.04 used below as example) have been on an above-threshold kernel version since at least 2021, so this blog is also relevant for such Ubuntu distros – you implement the script and the install run should work.
Please also check the following advice: whichever distro you are using, it’s good to be aware, that you will need to get the newer Sybase “Part License” from the downloads site, extract (unrar) it, rename it to “SYBASE_ASE_TD.lic”, and put it in the subdirectory of the unrarred archives at ./server/TAR/x86_64/ … also you should delete any out of date .lic files, so as not to confuse Sybase.
The downloaded rar files, 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.
Anyway, this blog is going to consider – and solve š… using simple bash script modifications – two problems that you can run into, when using Ubuntu 21.04 or greater, or openSUSE Leap 15.4 or greater, as the base distro for the SAP system installation. This blog mainly shows Ubuntu (at the time of blog creation Ubuntu was the only in-scope distro), but in September 2022 I tested successfully for openSUSE Leap 15.4, so a couple of screenshots from that test run also added at the end. Here’s a screenshot of the code (don’t worry, copy-pastable script listed later):
[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. However it can be that SAP has no intention of fixing its installer, as it seems to want people to use the Docker image and so there have been no fixes done since around 2018 when the rar archives were last updated on Downloads site].
The current bugs that we will solve for our in-scope distros (kernel version 5.4.x or greater) 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 (or openSUSE Leap 15.4), 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 21.04 or openSUSE Leap 15.4, 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). In older versions of these distros – which either coincidentally or not, had kernel versions of 5.3.x or lower, this too-early-ending issue did not occur.
However, I have an idea how we can solve this issue: by executing the ‘saphostexec -install’ 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
When trying to install the SAP system with ASE database on Ubuntu 21.04 (or e.g. on Leap 15.4), then although our above trick for saphostexec gets us onto the “main install” stage, still the installation run hangs eventually and just waits:
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 Former Member and Daniel Thrall respectively:
https://answers.sap.com/questions/13185432/docker-installation-of-as-abap-752-sp04-hangs.html
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 21.04 (later also worked for openSUSE Leap 15.4), 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.
[Note that there is a risk in re-using this script – if your installation run fails for another reason, then zimshalabimstall.sh script does not (when re-run) check whether the T11889 flag has already been added. So it’s an exercise for the reader to either implement such a check, or, if like me you prefer to just delete all extracted files:
sudo rm -rf /sapmnt /sybase /usr/sap
…and start again, then no need to implement any such check, since the re-run will then be acting on a “clean” (i.e. extracted and not yet modified) version of the RUN_NPL file].
UPDATE September 2022: the exact same script (both parts of which were needed i.e. the part that prevents script-exit on using saphostexec, and the part that adds the T11889 flag) was tested on openSUSE Leap 15.4… test successful:
…
Four months later this blog post helped me to get the docker image working - thanks a lot, Dylan!
Hi,
Glad to hear that suggestions from the blog helped you.
Thank you Dylan! I spent one week until found this solution. It worked for me pretty well!
Hi, sounds like SAP haven't got around to fixing this bug... glad that my workaround blog was useful for you.
Thank you very much for this informative blog entry. These informations were really helpful.
Glad itās still useful advice.
Thanks for this dylan drummond . Great to have these issues (both that I came across) in one place.
Any idea why I get the following though?
Ā
Thanks
Ian
Hi. I haven't encountered this error, so unfortunately I haven't got any idea how to solve it.
Maybe there is some sap-related process or some "half-installed" stuff hanging around in your VM. You could try deleting stuff:
and then reinstall with all the bits about saphostexec and the -T11889 flag and the right place to put the ASE TestDrive license file and so on all fixed.
That's all that comes to mind. Good luck now.
Hi Dylan
Thanks for the swift reply. I removed the container, reinstated the changes you suggested above and all good. I have an NPL system running.
Cheers
Ian
Good that it's working now.
Thanks Dylan Drummond,
That helped me to overcome the problem of "installation hanging at : Authorizations set forĀ /sybase/NPL/startase_reset_sa." by installing SAP NetWeaver Dev Edition 752 on openSUSE Leap (15.3) instead of openSUSE Leap (15.4).
For information, the script for working around didn't overcome the Error for me ! may be I didn't realy understand how to deal with it.
Regards.
Hi,
good that you got things working on openSUSE Leap 15.3... based on your error-report for openSUSE Leap 15.4, I thought maybe I should test whether my script works for that distro also, as it is always a risk that upgrading stuff breaks other stuff š ... anyhow my installation worked fine using the script, at least I didn't have any issues. Updated the blog with some text and screenshots showing that it works for openSUSE Leap 15.4
So that means I could not replicate your error. You got things working on Leap 15.3 and that is the main thing, after all Leap 15.3 is "more recent" than NetWeaver 752 SP04. But good luck if you choose to try again for Leap 15.4.
Dylan, thank you so much for this guide! I've been trying to install SAP NetWeaver 7.52 on openSUSE Leap 15.4 for 2 weeks now, and none of the other guides and solutions worked. Yours worked perfectly!
Thank you once again for providing clear and concise instructions!
Hi,
good to hear that the blog-advice helped you.
At the time when I originally wrote this blog for Ubuntu, I thought "unlikely this one will reach many people as the official guides are for openSUSE Leap". But then I realised a couple of months ago that since Leap 15.4 is on a kernel version above the "threshold", so first I tested that the same advice would work for Leap 15.4, then I modified the blog to be a bit more openSUSE-friendly - though I avoided doing hard work of a complete re-write because, y'know, we all hate hard work š
Absolutely brilliant, thank you Dylan !!!
Glad to hear it's still a useful blog... not sure how long SAP will continue to renew the ASE license (current one expires in spring 2023), but if they do then I suppose this blog's "active lifetime" will extend into the future also.
Thanks Dylan, great job!
Finally I've managed to install 7.52 SP04, installation wasn't going very well with latest opensuse releases, until I found your post.
Hoping to find new SYBASE ASE license updated before March2023 (fingers crossed).
Good to hear. Yes letās hope SAP keep the whole Dev Edition concept going in 2023 by providing a renewed ASE license.
Thank you so much Dylan!
I had tried the installation several times now with openSUSE-Leap-15.4 and always got errors.
That the errors could be due to the new Linux kernel on that I would never have come!
With the help of your script, the installation has now run cleanly through!
Many thanks for it!
Thank you for your video!!!! https://www.youtube.com/watch?v=U7MUn0WLpps
You're very welcome! thanks for the mention!
good to hear the script was useful.
Dylan, i have followed the steps, but currently it stays stopped:
Help!
For me, following the steps correctly always leads to successful installation. Also, this blog isn't a generic and wide-ranging guide on the installation process, rather we assume that the reader is able to install the Dev Edition using older distros, I am just offering some extra advice for installing on newer distros. So I am not able to help you, since I cannot replicate the issue where you follow my blog and the installation fails. If you are stuck, you can of course try using an older version of e.g. openSUSE Leap, say 15.3. For reference, here is the advice from the introduction to this blog:
"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."
You were right. The video helped me !!! š
Ā
Tnks!
Good to hear you got it working.
Thank you Dylan,
I success fully completed installation with the help ofĀ your Script and Article (https://blogs.sap.com/2018/04/05/installing-sap-netweaver-developer-edition-on-an-ubuntu-desktop-vm-the-non-concise-guide/). This work around very help full.
Glad (though a little bit surprised) to hear that the 2018 blog is still accurate enough when used with this blog's advice (five years being a long time in computing). And good that you got the Dev Edition up and running.
Hello Dylan and everyone,
In case you haven't noticed yet, SAP NetWeaver AS ABAP Developer Edition 7.52 SP04 SYBASE_ASE license is extended until 31/03/2025.
This is what the file info.txt attached to the license says:
Extended expiry: 31-mar-2025
Backup existing license before replacing
Copy new license to /sybase/NPL/SYSAM-2_0/licenses
Rename it to SYBASE_ASE_TD.lic .. . etc
Ā
Good news
Stephane
Ā
Thanks for spotting this. So it means that Dev Edition should still be usable for at least another two years from now, good news indeed!
Hi Dylan
Ā
My SAP NetWeaver AS ABAP Developer Edition 7.52 SP04 SYBASE_ASE licenseĀ expired. I tried this method available in this linkĀ https://abapacademy.com/blog/sap-trial-license-expired-how-to-prolong-sap-trial-license/ but it did not work for me.
As a work around I re install the ABAP Developer Edition with replacing the license SYBASE_ASE_TD.lic with new license in TD752SP04part01\server\TAR\x86_64\. Now it is working and having the old data also.
What I want to know is there any other process available. Please let me know.
Thank you.
Hi,
there are no easy shortcuts here, because this is about two different kinds of license.
Type A: the license SYBASE_ASE_TD.lic, which is probably required to run the Dev Edition at all. The old version of this license expired on 31.03.2023, so any installations done with that, may not work any more (I cannot test - well, I could arrange a test but I am lazy, etcetera - as I haven't been in this position, but it seems a reasonable assumption). So one solution for that is to reinstall Dev Edition, but with the newer version of SYBASE_ASE_TD.lic in the correct location, as you have done. That newer version is indeed provided on the Dev Edition download site https://developers.sap.com/trials-downloads.html?search=752
Another solution, in case you don't want to reinstall Dev Edition from scratch, is to just replace the license from inside your Linux VM. It is located at /sybase/NPL/SYSAM-2_0/licenses/SYBASE_ASE_TD.lic - you can view it using:
sudo cat /sybase/NPL/SYSAM-2_0/licenses/SYBASE_ASE_TD.lic
So if you copy your new license into your home directory, /home/marmot (for example), then the following would likely work (assuming here you are in this home directory):
sudo mv /sybase/NPL/SYSAM-2_0/licenses/SYBASE_ASE_TD.lic /sybase/NPL/SYSAM-2_0/licenses/SYBASE_ASE_TD.lic_bac_old
sudo cp SYBASE_ASE_TD.lic /sybase/NPL/SYSAM-2_0/licenses/SYBASE_ASE_TD.lic
Then next time you start up your NPL system, some relevant process for Sybase stuff should pick up the new version of SYBASE_ASE_TD.lic.
I haven't tested this, so this is just a suggestion in case anyone wants to try it. [It would be up to whoever wants to test this, to make sure that it is allowed to use this workaround - probably it's ok since these Dev Editions have no commercial use (contain no business functionality), but I am not a lawyer, so I am only giving a possible workaround, not saying that you must or should use itĀ
]
Type B: in all cases where Dev Edition is up and running with the correct SYBASE_ASE_TD.lic, in addition to that, you need the Hardware Key license from https://go.support.sap.com/minisap/#/minisap which you install using the SAP* user in a SAPGUI session, as described in all the installation guides. To renew that Hardware Key type of license, it is as simple as just doing the same SAP* user trick, with a newer NPL minisap NPL.txt license that you can generate again from https://go.support.sap.com/minisap/#/minisap - actually, this Type B fix is what is discussed in the abapacademy blog that you mentioned.
So now that you have reinstalled Dev Edition using the newer SYBASE_ASE_TD.lic (which is valid until spring 2025 if I remember right), then, whenever your 3 month validity Hardware Key license expires (but the SYBASE_ASE_TD.lic is still valid), then you can just regenerate the NPL.txt license of Type B and install it as SAP*.
So to me it seems that there are two different processes, and depending on your scenario then either one (Type B, although logically there could be a scenario where just a Type A fix needed) process, or two (Type A and Type B processes) are required.
Hopefully this explanation is helpful.
Hi
These below process are working now. I had a mistake with permissions to the SYBASE_ASE_TD.licĀ file, after change the permissions it is smoothly running.
https://abapacademy.com/blog/sap-trial-license-expired-how-to-prolong-sap-trial-license/
sudo mv /sybase/NPL/SYSAM-2_0/licenses/SYBASE_ASE_TD.lic /sybase/NPL/SYSAM-2_0/licenses/SYBASE_ASE_TD.lic_bac_old
sudo cp SYBASE_ASE_TD.lic /sybase/NPL/SYSAM-2_0/licenses/SYBASE_ASE_TD.lic
Thank you.
Good to hear it worked out.
after changing i got the error. Any idea?
Hi,
I have never encountered this error. I reckon it's highly unlikely to be caused by the changes in the installer script described in this blog, since (a) this blog has existed for two years and been read thousands of times, so probably used in practice hundreds of times, without anyone else reporting such an error; (b) it's not the kind of error that for example making a bash script wait for 30 seconds would cause to occur.
Much more likely, is that you made some minor mistake in all the other configurations that need to be done, in order to install successfully. I don't run any Debug As A Service company that is going to offer to solve your specific installation issue, but I quickly googled the error message using search term "sap install modlib.jslib.caughtException abort execution because of", and it looks like many other threads on the internet discuss similar errors. So I opened the first one, which was https://answers.sap.com/questions/13008312/sap-netweaver-752-sp-abort-execution-because-of-st.html and it turned out that the OP had an invalid master password... got no idea if that is the same root cause for your issue, but anyway good luck googling the various discussions and trying out the various answers.
--
Having said all that, one thing that is worth checking, is the following text near the end of my blog:
"[Note that there is a risk in re-using this script ā if your installation run fails for another reason, then zimshalabimstall.sh script does not (when re-run) check whether the T11889 flag has already beenĀ added. So itās an exercise for the reader to either implement such a check, or, if like me you prefer to just delete all extracted files:
ā¦and start again, then no need to implement any such check, since the re-run will then be acting on a ācleanā (i.e. extracted and not yet modified) version of the RUN_NPL file]."
In other words, it is a good idea to delete all extracted files, in case you don't want to enhance the (enhanced) installer script, before trying again.
The other thing that some people discussed was that some issues are caused by not having the correct ASE license in the correct place with the correct name, before installing. So you could check that as well, here is a quote from near the beginning of this blog:
"Please also check the following advice: whichever distro you are using, itās good to be aware, that you will need to get the newer Sybase āPart Licenseā from theĀ downloads site, extract (unrar) it, rename it to āSYBASE_ASE_TD.licā, and put it in the subdirectory of the unrarred archives at ./server/TAR/x86_64/ ⦠also you should delete any out of date .lic files, so as not to confuse Sybase."
That is about all the ideas I have for you with this one. Good luck now!
Thank you so much for this.
I spent the whole day on installing, retrying again and again, solving issues one at a time bug failing to find the -T11889 parameter.
Again, thank you !
Good that you got it working.
Although it would be easier for everyone if SAP updated the installer script to make this blog redundant, my guess is they are concentrating nowadays on other tools for developers, so it might be that the advice for the -T11889 flag stays relevant for as long as until the Dev Edition is either updated or sunsetted.