Main disk would not boot cleanly.
could not fsck_ffs, cannot find inode
files went missing from /etc (make.conf, pf.conf, firewall*,
file went missing from rc.d
files went missing from /etc/X11
shell history file remained locked.
find suddenly could not find /usr/local/lib/*/libc.so.5
freecolor could not find its libraries
Xorg could not find lib* in /usr/local/lib
etc
somewhat fixed those from backup.
Which hosed the latest pkg install * upgrades (byobu bump, etc) which I
reinstalled
Put the disk on backup, latter mountroot, ran fsck_ffs on the failing disk
/root and /usr, multiple times,
..
Inexplicably got all libraries back, working, and files restored AS FAR AS I
KNOW
but as usual in this case, which happens at least twice a year, although I
restore
the desktop and programs (usually) to a working state, with adequate backups,
.
Why is there not some feature to build more resilency into the operating
system, so that
it could at least detect (spare copies of .so. in the background, auto check
etc...)
no matter if it takes more time upon boot, how to self-repair (for newbies or
INSTALLWORLD fixes)
rather than repair piecemeal by *experienced users* (2004 here) that cannot be
retold
without complaint, in other words, document failures and retool base tools for
more
reliability upon inode-disappearing loss of files and directories, especially
in the case of
/etc /boot etc which are critical to booting to a non-single-user environment.
Why is there ^^^, I suspect, not enough coders, time...
which is why I feel the need to post this issue here, as long as there IS NOT
enough
coders, time, maybe before pkg-base is fully implemented "pkg-base" could be
made
resilient to the above type errors. ( sudden missing .so. during a pkg base
upgrade, for
example...)
Just as a sort of feature request, delay it a year or so to make the binaries
BIGGER and
more capable, static not dynamic, etc...
No real contributing input above... I apologize in advance, if you will allow
me to do so, just
a freebsd end-user here, no time to contribute due to other issues.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
