BusyBox/ed crashes with illegal instruction on Ovirt using OVA QCOW2 4.11

[derekatkins]

trafficstars

Running 'ed configuration.yaml' and I get an Illegal Instruction (core dumped).

HassOS release with the issue:

HassOS 4.11

Supervisor logs:

There is nothing in the log from the timeframe of the crash.

Journal logs:

config $ journalctl -bash: journalctl: command not found

Kernel logs:

[446091.798254] traps: ed[15810] trap invalid opcode ip:55ba78f707d4 sp:7ffeaa206580 error:0 in busybox[55ba78eed000+9c000]
[446091.802066] audit: type=1701 audit(1596393071.567:119): auid=4294967295 uid=0 gid=0 ses=4294967295 subj==docker-default (enforce) pid=15810 comm="ed" exe="/bin/busybox" sig=4 res=1

Description of problem: I am running HassOS 4.11 within my OVirt VM infrastructure. I installed the OVA QCOW2 image and built the VM around that using the OVA configuration information (2G RAM, 2 CPUs). The system has been up and running for a while.

I was trying to use 'ed' to modify the configuration.yaml (I hate vi, and you don't have emacs installed). But all of a sudden it seems to crash:

config $ ed configuration.yaml 
"configuration.yaml", 47 lines, 1071 chars
: 2p
# Configure a default setup of Home Assistant (frontend, api, etc)
: s/#
ed: missing 2nd delimiter for substitute
: s/#//
Illegal instruction (core dumped)

It was not doing this when I first started using HassOS. I do not see any issues in the VM Host logs.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[derekatkins]

HI. I upgraded to HassOS 4.13 and still see the problem.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[derekatkins]

Still seeing this periodically in 5.10. Will update shortly, but the issue is still there. Wish I had a good way to reproduce reliably, or a way to get a crash dump to push into gdb when it does crash.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[derekatkins]

I am still seeing this. I did find a way to reproduce this behavior, however I am currently away from my main computer so cannot recreate it now; I will update next week when I get back to my HA instance. IIRC, the issue shows up when trying to remove characters from a line.

[github-actions[bot]]

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[derekatkins]

Yep, still an issue with HassOS 6.6 and the "Terminal & SSH" Add-On:

[core-ssh config]$ ed sensors.yaml
"sensors.yaml", 155 lines, 5495 chars
: $p
      unit_of_measurement: 'days'
: s/_of_//p
Illegal instruction (core dumped)
[core-ssh config]$

[agners]

There is no ed on OS level. It seems you are using the Terminal Add-on. The Terminal runs in its own container which is Alpine Linux based.

But I can indeed reproduce the core dump here:

[core-ssh ~]$ echo "# test" > test
[core-ssh ~]$ ed test
"test", 1 lines, 7 chars
: s/#//
Trace/breakpoint trap (core dumped)

Moving to Add-on issue tracker.

[agners]

I can also reproduce this on my x86-64 machine:

$ docker run -it alpine 
/ # echo "# test" > test
/ # ed test
"test", 1 lines, 7 chars
: s/#//
Illegal instruction (core dumped)

So it probably should get reported to Alpine Linux directly: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Contribute

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[derekatkins]

Oh, was that meant for me to go report it to Alpine?

[agners]

@derekatkins yes, sorry, should have been more specific. I don't care about ed that much :slightly_smiling_face: . The check above with the official Alpine image only shows that it hasn't been caused by something on our end.

[derekatkins]

@agners Fair enough. Done. See https://gitlab.alpinelinux.org/alpine/aports/-/issues/13504

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[derekatkins]

Looks like upstream is working on fixing it (and has actually already pushed a commit). Not sure when it'll be in a state where this add-on can pull in the fix?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[derekatkins]

... still a bug ....

[agners]

Looks like upstream is working on fixing it (and has actually already pushed a commit). Not sure when it'll be in a state where this add-on can pull in the fix?

It seems that the fix didn't got backported to Alpine 3.15 (https://gitlab.alpinelinux.org/alpine/aports/-/commits/3.15-stable/main/busybox). So it likely will need Alpine 3.16, and then the bump to the CLI add-on, so unfortunately it will take quite a bit.

[agners]

This is no longer reproducible. Most likely got fixed by #2576.