Kernel panic at BIG-IP AWS BYOL AMI (ami-f5ffe281) 11.4.0 Build 2384.0
Hi all. I get a constant kernel panic after out-of-the-box installation of BIG-IP BYOL AMI I have installed BIG-IP BYOL 11.4.0 Build 2384.0 (ami-f5ffe281). That's happened three times out of three attempts. One of the attempt was in a different instance type to eliminate instance-type issues.
Here is the system log:
SRAT: PXMs only cover 3839MB of your 30719MB e820 RAM. Not used. SRAT: SRAT not used. Red Hat nash version 5.1.19.6 starting Reading all physical volumes. This may take a while... Found volume group "vg-db-hda" using metadata type lvm1 16 logical volume(s) in volume group "vg-db-hda" now active /sysroot/sbin/setfiles: labeling files, pretending /sysroot is / /sysroot/sbin/setfiles: labeling files under /sysroot/sbin/init matchpathcon_filespec_eval: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 /sysroot/sbin/setfiles: Done. Welcome to BIG-IP 11.4.0 Build 2384.0 Setting clock (utc): Tue Jan 7 13:58:12 PST 2014 [ OK ]
Starting udev: [ OK ]
Setting hostname ip-10-0-0-246.eu-west-1.compute.internal: [ OK ]
Setting up Logical Volume Management: [ OK ]
Checking filesystems Checking all file systems. [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/mapper/vg--db--hda-set.1.root set.1./: clean, 3884/100352 files, 224541/401408 blocks [/sbin/fsck.ext3 (1) -- /shared] fsck.ext3 -a /dev/mapper/vg--db--hda-dat.share.1 dat.share.1: recovering journal dat.share.1: clean, 176/2621440 files, 120467/5242880 blocks [/sbin/fsck.ext3 (1) -- /var/log] fsck.ext3 -a /dev/mapper/vg--db--hda-dat.log.1 dat.log.1: recovering journal dat.log.1: clean, 77/917504 files, 61952/1835008 blocks [/sbin/fsck.ext3 (1) -- /config] fsck.ext3 -a /dev/mapper/vg--db--hda-set.1._config set.1./config: recovering journal set.1./config: clean, 294/393216 files, 30437/786432 blocks [/sbin/fsck.ext3 (1) -- /usr] fsck.ext3 -a /dev/mapper/vg--db--hda-set.1._usr set.1./usr: clean, 34020/288000 files, 421051/575488 blocks [/sbin/fsck.ext3 (1) -- /var] fsck.ext3 -a /dev/mapper/vg--db--hda-set.1._var set.1./var: recovering journal set.1./var: clean, 7286/393216 files, 95443/786432 blocks [ OK ]
Remounting root filesystem in read-write mode: [ OK ]
Mounting local filesystems: [ OK ]
Enabling /etc/fstab swaps: [ OK ]
Activating swap partition: [ OK ]
Starting early syslog-ng: [ OK ]
net.ipv6.route.max_size = 2097152 Memory change detected: current= 30949868 previous= 15436340 Setting mprov_firstboot flag Checking for and completing any logical disk transactions: [ OK ]
Checking for and completing any disk management transactions: [ OK ]
Setting up initial module provisioning: [ OK ]
Writing legacy mprov database: [ OK ]
info: setting ownership of xvda as mixed info: Looking for unbootable initial ramdisk images... info: Looking for solid-state drives... info: No solid-state drives found in this system.
INIT: Entering runlevel: 3
Entering non-interactive startup Applying iptables firewall rules: [ OK ]
Starting mcstransd: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface dummy: [ OK ]
Bringing up interface eth0: [ OK ]
Bringing up interface eth1: [ OK ]
Bringing up interface eth2: [ OK ]
Bringing up interface eth3: Device eth3 does not seem to be present, delaying initialization. [FAILED]
Bringing up interface eth4: Device eth4 does not seem to be present, delaying initialization. [FAILED]
Bringing up interface eth5: Device eth5 does not seem to be present, delaying initialization. [FAILED]
Bringing up interface eth6: Device eth6 does not seem to be present, delaying initialization. [FAILED]
Bringing up interface eth7: Device eth7 does not seem to be present, delaying initialization. [FAILED]
Bringing up interface eth8: Device eth8 does not seem to be present, delaying initialization. [FAILED]
Bringing up interface eth9: Device eth9 does not seem to be present, delaying initialization. [FAILED]
Starting auditd: [ OK ]
Starting restorecond: [ OK ]
Starting irqbalance: [ OK ]
Starting syslog-ng: [ OK ]
Mounting other filesystems: [ OK ]
Starting monitoring for VG vg-db-hda: [ OK ]
Successfully retrieved AWS Instance ID Document
Starting sshd: [ OK ]
Starting ntpd: [ OK ]
Current management-ip configuration mode is: DHCP. Starting vmware-guestd: [ OK ]
Starting httpd: [ OK ]
Starting crond: [ OK ]
BIG-IP 11.4.0 Build 2384.0
Kernel 2.6.32-220.el6.f5.x86_64 on an x86_64
ip-10-0-0-246.eu-west-1.compute.internal login: Stack:
Call Trace:
Code: 31 62 81 48 89 1d 2c b7 5a 00 48 89 58 08 89 6b 28 e8 69 2e 2b 00 0f ae f0 4c 89 f7 ff 15 5c 9c 5b 00 80 7c 24 07 00 75 04 eb 08 90 f6 43 20 01 75 f8 5a 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48
Stack:
Call Trace:
Code: 0f b6 c2 85 c0 74 c2 31 c0 c3 65 48 8b 14 25 c0 cb 00 00 8b 4a 1c ff c1 75 27 66 b8 00 01 f0 66 0f c1 05 d6 94 2f 00 38 e0 74 16 90 0f 1f 84 00 00 00 00 00 66 83 3d c0 94 2f 00 00 75 ec eb
Stack:
Call Trace:
Code: 0f b6 c2 85 c0 74 c2 31 c0 c3 65 48 8b 14 25 c0 cb 00 00 8b 4a 1c ff c1 75 27 66 b8 00 01 f0 66 0f c1 05 d6 94 2f 00 38 e0 74 16 90 0f 1f 84 00 00 00 00 00 66 83 3d c0 94 2f 00 00 75 ec eb
Stack:
Call Trace:
Code: 0f b6 c2 85 c0 74 c2 31 c0 c3 65 48 8b 14 25 c0 cb 00 00 8b 4a 1c ff c1 75 27 66 b8 00 01 f0 66 0f c1 05 d6 94 2f 00 38 e0 74 16 90 0f 1f 84 00 00 00 00 00 66 83 3d c0 94 2f 00 00 75 ec eb
Stack:
Call Trace:
Code: 0f b6 c2 85 c0 74 c2 31 c0 c3 65 48 8b 14 25 c0 cb 00 00 8b 4a 1c ff c1 75 27 66 b8 00 01 f0 66 0f c1 05 d6 94 2f 00 38 e0 74 16 90 0f 1f 84 00 00 00 00 00 66 83 3d c0 94 2f 00 00 75 ec eb
BIG-IP VE just don't like me...
Roee