[9fans] 9front: /lib/ndb/local clobbered after edit w/ sam, soon following update

[9fans] 9front: /lib/ndb/local clobbered after edit w/ sam, soon following update

[Michael Hansen]

Earlier today, I ran sysupdate on a Thinkpad T23 running
9front-3196.bf2df3ad17fa and rebuilt from source, as shown in the
9front wiki.

Later, I edited /lib/ndb/local with sam to specify a different ntp
server. After writing the change, closing the file, and quitting sam,
I restarted with fshalt -r.

After the restart, the machine's name had defaulted to cirno, and all
dns lookups seemed to be failing. I checked /lib/ndb/local to see if
I'd accidentally changed more than I thought, and the whole thing had
been replaced with what looked like C source I'd been looking at,
earlier. (Not the whole file, just the last ~20 lines.)

I copied another machine's /lib/ndb/local onto a flash drive, copied
it to /lib/ndb, modified it to suit the Thinkpad with sam, again, and
restarted with fshalt -r.

/lib/ndb/local got clobbered again, except this time, it was
overwritten with something having the general appearance of line
noise, heavy on unprintable characters.

I repeated the process of reconstructing /lib/ndb/local from another
box, only this time, I used ed instead of sam, and all appeared to be
well, after restarting.

Any ideas what went wrong? Trying to figure-out whether this is a DDTT
situation, or if I should worry that something got corrupted in the
update process, or that my recently installed SSD might have issues.

Re: [9fans] 9front: /lib/ndb/local clobbered after edit w/ sam, soon following update

[cinap_lenrek]

sounds like filesystem corruption, yes. in that case, do not override
anything. keep it as it is and depending on the filesystem, run a check
to determine the extend of the damage.

what filesystem is this? if its cwfs, read further:

if the damage seems small, you might just clear the directory entry
for the corrupted files (abandoning the blocks) and recreate it from
backup. do not just delete the file or override it! the block pointers
could be wrong pointing into other files, you'll just corrupt these
or put these blocks on the freelist! a filesystem check can reveal this.

see fs(8) manpage for the check and clri commands.

you enter these commands on the filesystem console, accessube by:

con -Cl /srv/cwfs.cmd

with cwfs, all changes to the filesystem are first done in the cache
and later the cache is written out to the dump at night. you can
recover main from the worm dump, which will reinitialize the cache.

note, this assumes that the corruption is in the cache only and hasnt
propagated to the worm yet. (check 9fs dump; cd /n/dump and see
if the backup is still intact)

to reinitialize the cache from last dump, you reboot and
use bootargs local!/dev/sdXX/fscache -c to enter config mode,
then in config mode enter:

recover main
end

--
cinap

Re: [9fans] 9front: /lib/ndb/local clobbered after edit w/ sam, soon following update

[cinap_lenrek]

what ssd is it?

--
cinap