0XV2 serial numbers in ereports tragically end with `\0\0\0`

[wfchandler]

The --serial flag to omdb db ereport list works fine with V1 serials, which use the full length of the serial_number field in the ereport table:

support@oxz_switch1:~$ omdb db ereport list --fetch-limit 1 2>/dev/null
TIME_COLLECTED           RESTART_ID                           ENA CLASS                      SOURCE       S/N         P/N         
2026-04-24T22:50:36.273Z d7bb7093-505f-3141-b6c8-8dd021a8512e 0x1 ereport.data_loss.possible sled 22 (SP) 2EKRJYKV 913-0000023 

root@oxz_switch0:~# omdb db ereport list --serial BRM42220031 --fetch-limit 1 2>/dev/null   
TIME_COLLECTED           RESTART_ID                           ENA CLASS                      SOURCE       S/N         P/N         
2025-10-18T01:57:12.836Z c5f5e7b6-2679-dd10-f4be-fa31dd913af7 0x1 ereport.data_loss.possible sled 21 (SP) BRM42220031 913-0000019 

However, if fails to find matches for V2 serial numbers:

support@oxz_switch1:~$ omdb db ereport list --fetch-limit 1 2>/dev/null
TIME_COLLECTED           RESTART_ID                           ENA CLASS                      SOURCE       S/N         P/N         
2026-04-24T22:50:36.273Z d7bb7093-505f-3141-b6c8-8dd021a8512e 0x1 ereport.data_loss.possible sled 22 (SP) 2EKRJYKV 913-0000023 

support@oxz_switch1:~$ omdb db ereport list --fetch-limit 1 --serial 2EKRJYKV 2>/dev/null
TIME_COLLECTED RESTART_ID ENA CLASS SOURCE S/N P/N 

Examining a record in the DB console, we see the serial is NUL padded to match the length of V1 serials:

root@[fd96:1539:f6fa:107::3]:32221/omicron> SELECT * FROM ereport LIMIT 1;
-[ RECORD 1 ]
restart_id     | 0339a1b6-4837-5e54-eb9c-fe87538f0dd2
ena            | 1
time_deleted   | NULL
time_collected | 2026-04-24 22:50:36.314061+00
collector_id   | 62ffb921-d34f-4677-a81c-64769fcd71d0
part_number    | 913-0000023
serial_number  | 23N44J0Y\x00\x00\x00
class          | ereport.data_loss.possible
report         | {"baseboard_part_number": "913-0000023", "baseboard_rev": 3, "baseboard_serial_number": "23N44J0Y\\u0000\\u0000\\u0000", "ereport_message_version": 0, "hubris_caboose": {"board": "cosmo-b", "commit": "3b9b40d840984e3cca6d40e73f020f96a40538c5", "version": "1.0.67"}, "hubris_task_gen": 0, "hubris_task_name": "packrat", "hubris_uptime_ms": 0, "lost": null}
reporter       | sp
sled_id        | NULL
slot_type      | sled
slot           | 14
marked_seen_in | NULL

I don't think we have a way of passing in a NUL-padded string from a shell, even with shenanigans like this:

support@oxz_switch1:~$ omdb db ereport list -s "$(printf '23N44J0Y\0\0\0')" 2>/dev/null
-bash: warning: command substitution: ignored null byte in input
TIME_COLLECTED RESTART_ID ENA CLASS SOURCE S/N P/N 

We should probably check if the provided serials are V2 and NUL-pad them to match the expected format.

[hawkw]

Ugh, that's so unpleasant, sorry! We should definitely fix this.

An alternative approach might be to strip the NUL bytes from the serials when ingesting the ereports...but we should check that this doesn't break our ability to JOIN with other database tables, which might also contain NUL-padded serials. Yucky.

[hawkw]

Technically, this problem doesn't just apply to omdb, since there is also a similar query for filtering ereports by serial which is performed by the support bundle collector. However, in that case, the serials are coming from other database tables, so they're probably already NUL-padded. We should be testing that this is the case there to make sure that it actually works correctly; I think the SP simulator ought to be changed to emit NUL-padded 0XV2 serials like those from a real life SP.

[hawkw]

Technically, this problem doesn't just apply to omdb, since there is also a similar query for filtering ereports by serial which is performed by the support bundle collector. However, in that case, the serials are coming from other database tables, so they're probably already NUL-padded. We should be testing that this is the case there to make sure that it actually works correctly; I think the SP simulator ought to be changed to emit NUL-padded 0XV2 serials like those from a real life SP.

Update: nope, according to @jgallagher, MGS is (correctly!) stripping the nulls for all the non-ereport traffic. So it's just the ereport records which are wrong, and critically, we can't actually do JOINs with baseboard_ids from inventory. Man. That's rough. Sigh.