: and keep getting overwritten — is there a clean, standard way to prevent thi

[_matthew_]

I’m running a very small TinyCore 17 system that serves only internal DNS and DHCP. I maintain several static LAN hosts in , and I also use a custom . Both files get overwritten on each reboot.

I’ve tracked  to ’s , so I can patch or wrap that if needed. But before I go down the road of patching individual scripts, I wanted to ask:
Is there a clean, standard, supported way to prevent post‑restore scripts from overwriting user‑supplied config files?

From searching the forum, most solutions seem to involve restoring files again at the end of bootlocal.sh. That works, but it feels fragile because some late‑boot scripts and daemons run in parallel with bootlocal.sh, so you can end up in a timing race. What works today might not work in a future release or with different extensions.

So my question is really about the bigger picture:

Is there an existing mechanism to mark certain files as “user‑owned” so that late‑boot scripts skip rewriting them?
If not, would it make sense for TinyCore to have a unified way to do this?

(For example, a group ownership convention or a marker file that helper scripts check before overwriting.)
I’m not looking for a one‑off hack for these two files — I’m wondering whether there’s a clean, general approach that I’ve missed, or whether this is something worth discussing as a feature.
Any thoughts or guidance appreciated.

[Leee]

Hi Matthew,
I'm not sure I understand the issue completely as it looks like there are a few words missing from the post?  However, while I'm not aware of any way to flag files as "not to be overwritten" (except maybe setting the immutable attribute?).

To prevent the "some late‑boot scripts and daemons run in parallel with bootlocal.sh" issue, you could just not use bootlocal.sh - just put everything into bootsync.sh.  That might slow down the overall boot time but you could be sure that any file restoring that you did at the end of bootsync.sh would happen after everything else was started.

[Rich]

Hi _matthew_

... Is there a clean, standard, supported way to prevent post‑restore scripts from overwriting user‑supplied config files? ...

By  "post‑restore scripts" , are you referring to scripts located in  /usr/local/tce.installed/ ?

If so, those scripts typically first check if a file exists so that files do not get overwritten.

If this is what is happening, the extension that is causing it likely has a bug and you
should let us know which extension is causing it.

[_matthew_]

Hello guys, and thank you for responding!

I need to define a bunch of static IP's that are out of the dhcp servers range in /etc/hosts.  Dnamasq reads this by default.  If I put /etc/hosts in the /opt/.filetool.lst file and run filetool I can see that it grabs my /etc/hosts.  I can also go into the tar file filetool creates and verifies that the contents are correct.  So I do a reboot, and when I go back and look at /etc/hosts, my version is gone and the stock version is back.  I have similar issues with /etc/resolve.conf.  I have got past them with band aid fixes:

This is ugly but it is the winning combo:

Code: [Select]

#!/bin/sh
# put other system startup commands here
/bin/date >> /mnt/sda1/reoot.log
/sbin/syslogd -b 3
/sbin/ifconfig eth0 192.168.1.145 netmask 255.255.255.0 up
/sbin/route add default gw 192.168.1.1
echo nameserver 192.168.1.151 >  /etc/resolv.conf
/usr/sbin/ntpd -p pool.ntp.org
/usr/sbin/crond -b
/usr/local/etc/init.d/openssh start
echo nameserver 192.168.1.151 >  /etc/resolv.conf
cat /etc/dnsmasq.anames > /etc/hosts
/usr/local/sbin/dnsmasq

So the first echo nameserver 192.168.1.151 >  /etc/resolv.conf sets it up long enough for ntp to resolve the hosts it needs to start.  Sometime beteween the first one and the second one, it gets plowed.  Without the second echo nameserver 192.168.1.151 >  /etc/resolv.conf the system has no name resolution until it is set again.

And to the person who sugguested the bootsync file that is called before the bootlocal file, in fact that calls the bootlocal file so without question that would get plowed under.

/usr/bin/sethostname dns
/opt/bootlocal.sh &

    [Edit]: Added code tags.  Rich

[Rich]

Hi _matthew_

Please use  Code Tags  when posting commands and responses seen in a terminal. To use  Code Tags  click on the  #  icon
above the reply box and paste your text between the  Code Tags  as shown in this example:

[code][   36.176529] pcm512x 1-004d: Failed to get supply 'AVDD': -517
[   36.176536] pcm512x 1-004d: Failed to get supplies: -517
[   36.191753] pcm512x 1-004d: Failed to get supply 'AVDD': -517[/code]

It will appear like this in your post:

Code: [Select]

[   36.176529] pcm512x 1-004d: Failed to get supply 'AVDD': -517
[   36.176536] pcm512x 1-004d: Failed to get supplies: -517
[   36.191753] pcm512x 1-004d: Failed to get supply 'AVDD': -517
Code Tags  serve as visual markers between what you are trying to say and the information you are posting. They also preserve
spacing so column aligned data displays properly. Code tags also automatically add horizontal and or vertical scrollbars
to accommodate long lines and listings.

[Rich]

Hi _matthew_

... the bootsync file that is called before the bootlocal file, ...

Near the end of  /etc/init.d/tc-config , the system restores the files you
backed up. Shortly after that, bootsync is called and clobbers your hosts
file. Take a look at  /usr/bin/sethostname  and you'll see it too.

I haven't found what what alters resolv.conf yet.
On my systems, it's a script I use to set a static IP:

Code: [Select]

tc@E310:~$ cat /opt/eth0.sh
#!/bin/sh
pkill udhcpc
ifconfig eth0 192.168.1.35 netmask 255.255.255.0 broadcast 192.168.1.255 up
route add default gw 192.168.1.1
echo nameserver 192.168.1.1 > /etc/resolv.conf
echo nameserver 68.237.161.12 >> /etc/resolv.conf
tc@E310:~$

... So the first echo nameserver 192.168.1.151 >  /etc/resolv.conf sets it up
long enough for ntp to resolve the hosts it needs to start.  Sometime beteween
the first one and the second one, it gets plowed. ...

These 3 commands are the only thing run between the echo commands:

Code: [Select]

/usr/sbin/ntpd -p pool.ntp.org
/usr/sbin/crond -b
/usr/local/etc/init.d/openssh startRestart each one manually to figure out who the troublemaker is.

[patrikg]

You can remove the line:

Code: [Select]

pkill udhcpc
And add the kernel commmand line argument:

Code: [Select]

nodhcp
See:
https://distro.ibiblio.org/tinycorelinux/faq.html#bootcodes

To gain a little boot time.

[Rich]

Hi patrikg
I know. I do tend to include the nodhcp boot code.
I leave the pkill in there for a couple of reasons:

1. I copy this script anytime I set up a new machine or TC version.
   The pkill protects me if I forget the nodhcp boot code.

2. I sometimes post this for new users wanting a static IP. The pkill
   ensures it will work regardless of the new users skill level, knowledge
   of boot loaders, and knowledge of boot codes. And, this way I don't
   have to try to walk them through boot loader and boot code changes.

[gadget42]

as i am always trying to learn more about topics as they come along casually...i used duckduckgo-lite to search:

https://start.duckduckgo.com/lite/?q=pkill+udhcpc

and at least right now(post date/time) a tcl forum post is the first result listed:

https://forum.tinycorelinux.net/index.php/topic,20223.0.html

great that the forum continues to be present in search results!

[Rich]

Hi _matthew_
This writeup in finding which process is overwriting a file may be of interest:
https://forum.tinycorelinux.net/index.php/topic,28053.0.html