Here is how you fix the reboot issue
After first launch,
1. create backup of /etc/fstab
2. In your /etc/fstab file, add 'nofail' to /dev/xvds, /dev/xvde, /dev/xvdz
e.g.
/dev/xvds /usr/sap xfs nobarrier,noatime,nodiratime,nofail,logbsize=256k,delaylog,x-systemd.device-timeout=360 0 0
/dev/xvde /hana/shared xfs nobarrier,noatime,nodiratime,nofail,logbsize=256k,delaylog,x-systemd.device-timeout=360 0 0
/dev/xvdz /media xfs nobarrier,noatime,nodiratime,nofail,logbsize=256k,delaylog,x-systemd.device-timeout=360 0 0
3. after saving your /etc/fstab, if you want to check for correctness, you can take command 'mount -a' and it should not give any output if valid. You don't need to restart system to check.
SUSE Linux for SAP 12 SP1 and SP2
Since Begin of November, we are offering customers the usage of SUSE Linux for SAP as Base Image for High End SAP HANA Systems. We performed extensive validation of SUSE Linux for SAP compared to the other SUSE Linux editions on AWS. We did not run into any additional efforts. As part of the validation we are also performing automated reboots.
Tips for the other reviewers:
1. For automation experts: SUSE Linux 12 brings Systemd with concurrent boot processes. You might need to maintain your boot dependencies or add sync points when you perform automated actions at boot time.
2. The other area where we had challenges was with the X1.* and the M4.16xlarge instance types, because those come with ENA Networking (20 Gbps) but not with the required Network Drivers. The symptom is limited network performance.
This issue was resolved with SUSE Linux 12 SP 2 (General Edition and SAP Edition)
PS: Just for this review I re-tested the reboot scenario with SLES for SAP 12 SP 1
Happy to help if you have questions.
questions@ocean9.io
Works great after update.
Just tried this, and it works fine. Looks like the image has been updated. Launched the instance, logged into the server, then rebooted and launched again successfully. Instance is up and running.
Working great
I've used this image and did not find the problem that was reported. I can patch/reboot and use yast and everything else that I'm very familiar with.
Love the HANA Firewall !
Working with HANA express
I noted the negative reviews but looks like the update recently made to the image solved the kernel panic issue. Found the image on Marketplace here was easy way to test some of the OS functionality and using with HANA express didn't run into issue on install.
Same issues as others. Kernel panic after first reboot. Can't connect
[ 1.685530] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 1.688829] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.12.57-60.35-default #1
[ 1.688829] Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/12/2016
[ 1.688829] 0000000000000000 ffffffff815202d0 ffffffff817df358 ffff881e0c291e20
[ 1.688829] ffffffff8151b251 ffff881e00000010 ffff881e0c291e30 ffff881e0c291dd0
[ 1.688829] ffff881e0c291e20 ffff881e0c291e38 0000000000000012 0000000000000001
[ 1.688829] Call Trace:
[ 1.688829] [
[ 1.688829] [
[ 1.688829] [
[ 1.688829] [
[ 1.688829] [
[ 1.688829] [
[ 1.688829] [
[ 1.688829] [
[ 1.688829] [
[ 1.688829] [
Not usable currently
Same problem as the other reviewers: Disfunctinal after first reboot. HANA Express install itself was fine, until I shudown the instance and rebooted. Tried several new installations, all the same result. Viewing EC2 console system log shows that it panics because of missing/corrupt root device. Hope they wil fix it....
Kernel panic after first reboot
Same issue as first reviewer. First boot worked fine, could do work as required. When rebooting the instance, the instance was never reachable anymore. The system log in the EC2 Management Console shows a Kernel Panic.
Unable to connect to instance after reboot
Our experince is not at all Good....After simply launching the instance ,we logged on to server .And checked basic stuff . Found the OS fine for SAP.But And rebooting the server we are unable to loggon. AWS support saying that issue with this AMI....