Date: Sun, 08 Nov 2015 06:49:10 -0800 (PST) From: "Jeffrey Bouquet" <jbtakk@iherebuywisely.com> To: "jbtakk" <jbtakk@iherebuywisely.com> Cc: "current" <current@freebsd.org> Subject: Re: Cannot installworld, don't expect to... part 2... Message-ID: <E1ZvRHK-0007EM-Kh@rmm6prod02.runbox.com> In-Reply-To: <E1ZvGRL-0005AG-Uq@rmm6prod02.runbox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 07 Nov 2015 19:14:47 -0800 (PST), "Jeffrey Bouquet" <jbtakk@iherebuywisely.com> wrote: > I've a not-complete-installworld from today, dumped core halfway through > despite single-user mode... > > began with an install of libc++... which was fine. > > i can restore > /lib > /libexec > /bin > /sbin > /usr/bin > /usr/sbin > from an earlier backup > > and most binaries work again, but nowhere near > full functionality... wanting to restore browser > functionality... which mysteriously broke (all segfault) which > prompted the buildworld. > > setting COMPILER_TYPE results later in > sh: cc; not found during the installworld. > OTOH some buildworld > produced files may have been lost during the fsck to lost+found > > I noticed a few clang files ended up in lost+found during one of the many fsck. > > So as an aside of any usual question... > Is there any documentation > where make installs should proceed? > for instance libc++ first, then ... > > and/or how to run the installworld segment-at-a-time to find the > specific failure? OR it is too complex > > Assuming "no" to each of the above... is there a best > practice to > copy a greater number of the /lib, libexec from > backup to completely restore, or is it necc. to > do a reinstall to an ENTIRELY new disk... given that > the existing disk for some reason does not want to > complete it. > > Maybe even someone has an easier way... or procedure. > > Thanks. > > ... > As an aside, a wanted feature: > > during one disk crash recently, the pass* in /etc wound up in lost+found. > No login resulted. Restored from backup by luck... was clueless. > Would it be wise to build redundancy into the base, so that for example > if /etc/fstab has vanished, its shadow copy in /etc/shadow/... > or even enough binaries, (similar /rescue ) to complete a complete svn > buildworld installworld as a sort of /rescue/usr/src with all binaries and > libraries contained therein. > > Maybe... > > Crash recovered. All /root/.* directories had vanished also... so I was thinking, maybe if fsck_ffs were more elaborate when placing the files in lost+found it would place metadata as to where it came from, and then lost+found-replace.sh or binary could recover FROM lost+found... I could be just wishing though. But the reason for this reply-followup rather than a new post (the paragraph above) with apologies... Now that the recovery here has been done, ( files between nov 3 and nov 7 copied from /mnt where the crashed disk(s) and backups were mounted)... WHAT is the best practice if *this* working r288246 (11.0-CURRENT) builds world, then core dumps during installworld, rendering login and/or paths upon login and/or segfaults of nano, etc after login and/or all working but browsers segfaulting after fixup... since this is a principal desktop ... ... the best practice for "if this installworld hoses, simply copy files from ..." recovery? OR, no one else knows either, which I think is more likely, in which case I apologize for even stating the question. Thanks.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1ZvRHK-0007EM-Kh>