On Wed, 22 Dec 2021, Al Slater wrote:

> On 21/12/2021 18:26, Andy Fiddaman wrote:
> >
> > On Tue, 21 Dec 2021, Al Slater wrote:
> >
> >> Hi,
> >>
> >> I am trying to start an omnios r151040g instance in AWS using a t3.micro
> >> instance type to test out the new ena driver.
> >>
> >> On boot, I am getting the following panic
> >>
> >> panic[cpu0]/thread=fffffe00033f0c20: timed out waiting for admin response
> >
> > I just tried booting a t3.micro instance using the latest r151040g cloud
> > image ( 
> > https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdownloads.omnios.org%2Fmedia%2Fr151040%2Fcloud-151040g.vmdk.zst&data=04%7C01%7Cal.slater%40essiell.com%7Ce7578aa0f01e4ba23ecb08d9c4c82a6e%7C67bdf01501684644977d405802dde4b9%7C1%7C1%7C637757186251659247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bUpbTCg2fCNQW6BRtpAjib8vo1hXH927zCNZaPb7N%2Fk%3D&reserved=0
> >  )
> > and saw the same as you - it paniced and rebooted three times but then is up
> > and working. There's obviously something to fix here but does yours ever
> > stabilise? I think what's happening with mine is that the cloud-init that's
> > in the cloud images is playing with interfaces (ephemeral DHCP interfaces 
> > etc.)
> > and triggering the problem with teardown that Peter saw.
> >
> > After three reboots, I'm here:
> >
> > OmniOS r151040 Version omnios-r151040-d75907718a 64-bit
> > Copyright (c) 2012-2017 OmniTI Computer Consulting, Inc.
> > Copyright (c) 2017-2021 OmniOS Community Edition (OmniOSce) Association.
> > WARNING: illegal PCI request: offset = 100, size = 4
> > WARNING: illegal PCI request: offset = 100, size = 4
> > Hostname: ip-172-31-11-21
> >
> > ip-172-31-11-21 console login: root
> > Password:
> > Last login: Tue Dec 21 18:20:13 2021 on console
> > OmniOS r151040  omnios-r151040-d75907718a       December 2021
> > root@ip-172-31-11-21:~#
> > root@ip-172-31-11-21:~# ipadm
> > ADDROBJ           TYPE     STATE        ADDR
> > lo0/v4            static   ok           127.0.0.1/8
> > ena0/dhcp         dhcp     ok           172.31.11.21/20
> > lo0/v6            static   ok           ::1/128
> > root@ip-172-31-11-21:~# ping 1.1.1.1
> > 1.1.1.1 is alive
> > root@ip-172-31-11-21:~#
> >
> > I could publish this AMI if you'd like to experiment with it.
> >
> > Andy
>
> Initially the reboot/panic loop occurred many times (>3) until I stopped
> the instance.
>
> After many stops and restarts I managed to get the instance to stay up.
>
> Now I no longer get the panic at all on stop/restart.
>
> Maybe not all nitro hosts are equal?
>
> ipadm output looks slightly odd with 2 entries for ena0? Something to do
> with cloud-init?
>
> root@ip-10-110-25-244:~$ ipadm
> ADDROBJ           TYPE     STATE        ADDR
> lo0/v4            static   ok           127.0.0.1/8
> ena0/ephdhcp      dhcp     ok           10.110.25.244/24
> ena0/dhcp         dhcp     down         10.110.25.244/24
> lo0/v6            static   ok           ::1/128

Yes, the 'ephdhcp' interface is one that cloud-init creates when it's doing
its datasource detection and I suppose it crashed halfway through. You can
clean it up from the nitro console with something like:

 ipadm delete-addr ena0/dhcp
 ipadm delete-addr ena0/ephdhcp
 ipadm create-addr -T dhcp ena0/dhcp

It's easy enough to trigger the crash again by doing `ipadm delete-if ena0`
and I grabbed a crash dump which can be found at
https://downloads.omnios.org/misc/ena.vmdump.3

Andy


------------------------------------------
illumos: illumos-discuss
Permalink: 
https://illumos.topicbox.com/groups/discuss/Ta838d1d97b3f9153-Mf76f5a5248652639aa476e88
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

Reply via email to