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.Received on Tue Jul 05 2016 - 16:21:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC