It’s not copied on boot, at least not on my MT300N-v2. Maybe it is on first boot, but here’s what I see after truncating and vacuuming the database, and rebooting:
root@router:/# ls -il /etc/tertf/* /rom/etc/tertf/* /overlay/upper/etc/tertf/*
3177 -rw-r--r-- 1 root root 12288 Jan 25 06:15 /etc/tertf/mac_vendor.db
4437 -rw-r--r-- 1 root root 472 Jan 25 07:04 /etc/tertf/tertfinfo_bak
3177 -rw-r--r-- 1 root root 12288 Jan 25 06:15 /overlay/upper/etc/tertf/mac_vendor.db
4437 -rw-r--r-- 1 root root 472 Jan 25 07:04 /overlay/upper/etc/tertf/tertfinfo_bak
767 -rw-r--r-- 1 root root 950272 Feb 15 2021 /rom/etc/tertf/mac_vendor.db
There was no tertfinfo_bak
in the /rom
squashfs, so one was created, and that write operation was trapped, and redirected into /overlay/upper
. After disassembling /usr/bin/gltertf
(the only binary in /usr
to reference mac_vendor.db
), it appears that sqlite is doing something clever/stupid since gltertf
is the only thing that opens mac_vendor.db
and only to do a SELECT
. And now that that file was written, it’s being served from /overlay/upper
rather than /rom
.
Too much work. I don’t want to maintain build infra for my various gl.inet products. Easier and more maintainable to keep a shell script to apply my local changes: opkg update
, install my ssh keys, install some packages, configure things, patch out undesirable behavior from the startup scripts… So I can either temporarily install sqlite to truncate the database, or just keep a copy of the truncated database for my configurator script to install.