Question on bootup messages

1

Hello

When I launch my app in aws on a t4g.nano instance I see these msgs in the system log console:

UEFI firmware (version  built at 09:00:00 on Nov  1 2018)
e[2Je[01;01He[=3he[2Je[01;01He[2Je[01;01He[=3he[2Je[01;01He[2Je[01;01He[=3he[2Je[01;01He[0me[35me[40men1: assigned 169.254.202.129
en1: assigned FE80::7C:9EFF:FED4:A459
en1: assigned 2A05:D014:11FB:6103:AD1C:DC7F:D2F5:7300
2023/12/03 14:43:30 DerBurritoAPI Initialization start...
frame trace: 
loaded klibs: ntp@0xffffffff80200000/0x7000 tls@0xffffffff80300000/0xa5000 cloudwatch@0xffffffff80220000/0x11000 
assertion t >= last_raw failed at /home/circleci/project/src/runtime/clock.h:78 (IP 0xffffffff8002b210)  in now(); halt
Keep alive watchdog timeout.
Trigger reset is on
free uncompleted tx mbuf qid 1 idx 0x18
Device reset completed successfully, Driver info: Elastic Network Adapter (ENA) ena v2.3.0
Potential MSIX issue on Rx side Queue = 0. Reset the device
Trigger reset is on
free uncompleted tx mbuf qid 1 idx 0x0
Device reset completed successfully, Driver info: Elastic Network Adapter (ENA) ena v2.3.0
Potential MSIX issue on Rx side Queue = 0. Reset the device
Trigger reset is on
...

I notice that my app gets executed, because this msg is the first line of code in my app:

2023/12/03 14:43:30 DerBurritoAPI Initialization start...

Then the klibs get loaded, which I would expect to happen before the app gets executed, I thought that this happened because I set “CPUs”: 2, in the config.json, so I set it to 1, but the result was the same.

And then a failed assertion, with a halt at the end:

assertion t >= last_raw failed at /home/circleci/project/src/runtime/clock.h:78 (IP 0xffffffff8002b210)  in now(); halt

After that, the same messages keep on repeating, and my application gets “halted” (I assume) as it does not respond. Any idea of what would be happening?

I also added this config to see if it would change the order of the messages but it didn’t.

"exec_wait_for_ip6_secs": "5",
"exec_wait_for_ip4_secs": "5",

Note that my VPC contains IPv6-only subnets, so not sure if that might have something to do with this problem. I’ll try deploying my app in a traditional IPv4 subnet. Will keep you posted.

Thanks and regards,
Ernesto Medina.

2

You are right that the klibs are loaded before the app gets executed; in your log, the “loaded klibs” line is only there as part of the error messages printed as a result of the failed assertion (it’s an informative message listing the klibs that were loaded in the kernel at the time when the failure happened).
The bug causing this failure has been identified and fixed in AWS: add support for PTP hardware clock by francescolavra · Pull Request #1979 · nanovms/nanos · GitHub. If you want, you can try the fixed Nanos kernel by specifying the --nanos-version 46cf22d option in your Ops command line when creating an image.

1 Like
3

Would this work also?

{
    "NanosVersion": ["46cf22d"]
}
4

No, specifying the Nanos version via the configuration file is currently not supported (except for the NightlyBuild flag).

5

Should I exclude -n while using --nanos-version 46cf22d or there is no conflict?

6

-n and --nanos-version should never be specified in the same command line because they conflict with each other, so yes, you should exclude -n while using --nanos-version 46cf22d

7

I was able to fix the problem, thanks.
We can close this one.

Regards,
Ernesto.