Am Sat, 21 Jan 2017 22:20:01 +0100 "O. Hartmann" <o.hartmann_at_walstatt.org> schrieb: > Am Thu, 19 Jan 2017 19:38:30 +0000 > Glen Barber <gjb_at_FreeBSD.org> schrieb: > > > On Thu, Jan 19, 2017 at 07:10:00PM +0000, Glen Barber wrote: > > > On Thu, Jan 19, 2017 at 10:16:46AM +0100, O. Hartmann wrote: > > > > On Thu, 19 Jan 2017 06:58:16 +0100 > > > > Matthias Apitz <guru_at_unixarea.de> wrote: > > > > > > > > > El día Wednesday, January 18, 2017 a las 08:00:04PM -0500, Allan Jude > > > > > escribió: > > > > > > > > > > > On 2017-01-18 14:37, O. Hartmann wrote: > > > > > > > Am Wed, 18 Jan 2017 16:38:32 +0100 > > > > > > > Matthias Apitz <guru_at_unixarea.de> schrieb: > > > > > > > > > > > > > >> Why you do not just boot from USB some mem stick image, mount some disk > > > > > > >> space to /mnt, svn checkout CURRENT to /mnt and build a booteable system > > > > > > >> (world and kernel) and install to DESTDIR=/mnt ? > > > > > > >> > > > > > > >> I do not understand all this hassle? > > > > > > >> > > > > > > >> matthias > > > > > > >> > > > > > > > > > > > > > > Wow! > > > > > > > > > > > > > > As I initially stated, that is EXACTLY what I was inclined to do except > > > > > > > the fact that I had already an intact /usr/obj and usr/src with a > > > > > > > complete compiled system. > > > > > > > > > > > > > > I booted from mem stick and I was lost due to no cc! > > > > > > > > > > > > > > Even for "make installworld" it seems I have to rely on the compiler. And > > > > > > > the images (ISO, memstick et cetera) provided these days do not contain > > > > > > > any clang. > > > > > > > > > > Yes, you will need it and it will complain about missing it, if for > > > > > example you moved 'obj and 'src' to other dirs after 'make build...' > > > > > > > > > > But, in your case the mem image really is lacking the cc/clang; I > > > > > fetched the image an did: > > > > > > > > > > > > > > > # mdconfig -a -t vnode -u 1 -f > > > > > ~guru/Downloads/FreeBSD-11.0-RELEASE-amd64-memstick.img # mount -o > > > > > ro /dev/md1p3 /mnt # find /mnt -name clang > > > > > /mnt/usr/share/doc/llvm/clang > > > > > /mnt/usr/lib/clang > > > > > /mnt/usr/lib/debug/usr/lib/clang > > > > > # find /mnt -name cc > > > > > /mnt/usr/include/netinet/cc > > > > > > > > > > With this img alone, you can't compile a system :-( > > > > > > > > > > Setup a system from DVD and build your own image containing a complete > > > > > system on an USB key; with this boot your damaged system, recompile and > > > > > reinstall world and kernel. If you (O. Hartmann) need a step by step > > > > > guide, I could send it to you. > > > > > > > > > > matthias > > > > > > > > > > > > > Hello, > > > > > > > > thanks for your help offering! very kind. > > > > > > > > I've already solved the problem - not with the suggested process, but via > > > > copying missing libs and files from and identical intact source. After that, I > > > > ran make buildword/buildkernel and was able to successfully install the new > > > > system. > > > > > > > > As I stated before: I already had a complete compiled world and kernel existing > > > > in their proper, intact folders (usr/src and usr/obj). There was no need to > > > > compile a whole world. > > > > Intending to "make installworld" failed, this is the real problem, because the > > > > ISO/memstick images provided lack obviously in the required infrastructure and > > > > so these images are worthless for sophisticated rescue operations - or even > > > > such a simple ask as described initially in my posting. > > > > > > > > I created images on CURRENT of my own - they all lack in the ability of having > > > > the necessary tools aboard. So I consider every image useless for rescue > > > > operations except, maybe, the DVD image - but this one is not provided anymore. > > > > For what reason? Time? Accepted. Space/disk usage? Well, welcome back in the > > > > stoneage of computer technology ... > > > > > > > > I remember faintly that there was a small discussion on the _at_CURRENT list, but > > > > I didn't realize that the result would be the extraction of the compiler. > > > > > > > > Just for the record: most servers delivered to us do not have CD/DVD drives > > > > anymore - they are outdated and considered an extra these days. Purchasing 1 GB > > > > USB thumbdrives is getting even harder, smallest size my employer provides now > > > > is 2 GB. And most optical drives are DVD. From my point of view - and this is a > > > > personal view - the "standard" is > 1GB so there is no need to break down by > > > > force the FreeBSD image (if size is the reason) down to < 800 MB or < 1 GB. I'd > > > > consider having < 2GB the line of standards (2 GB USB mem drive). > > > > And for those, with need of very small images, smaller images could be provided > > > > as the extra. > > > > > > > > > > I do want to weigh in here and inform I am actively watching this > > > thread. clang(1) is not in disc1.iso or bootonly.iso because the > > > MK_TOOLCHAIN knob is disabled in the targets that generate them. This > > > has actually been the case for quite some time for these images. > > > > > > dvd1.iso does contain clang, but very rarely (if ever, actually) are > > > there dvd1.iso images produced for development snapshots. This is, in > > > part, solely because of the additional space/bandwidth required on the > > > mirrors (not just mirrors controlled by the Project, but third-party > > > mirrors as well). > > > > > > I am working on splitting out how the memstick.img and disc1.iso images > > > are produced, but ran into a problem which I'm looking into a workaround > > > that is backwards-compatible. Since for USB images, a 700MB limit does > > > not make sense, and right now it just so happens that the memstick.img > > > is created from the same contents of disc1.iso. > > > > > > I know this does not help with the immediate issue, but wanted to chime > > > in with I do see and understand the larger issue, and am working on > > > a more long-term resolution instead of a one-line workaround. > > > > > > > Random thought: > > > > Brought up out-of-band, can you try this from a memstick.img and your > > already-built userland/kernel to do what you had originally tried to > > install the system? > > > > # make -C /usr/src WITHOUT_SYSTEM_COMPILER=1 DESTDIR=/wherever installworld > > > > I think this is why cc(1)/clang(1) is not being used from /usr/obj, and > > you don't have a compiler to compile the compiler. > > > > Glen > > > > I ran on a different(!!!!) machine in the very same situation while installing kernel > and world in SINGLE USER mode! Different machine, also SSD (different model): the > symptomes are the very same. Close to the end of installations of lib32, the box goes > down, crashes. > > After reboot, it can not find any kernel because /boot/kernel as well as every "per > default" installed file/directory is not existent anymore - except thiose files I > touched/copied. > > Files in /rescue do have all NULL size! That was the same on the other box on which > crash I initiated this thread. The same in /sbin, /bin, /usr/bin, /usr/sbin and /lib. > Some libs/files are NULL in size. > > So, apart from the fact that CURRENT disrupts obviously filesystems on installations, I > had the doubtful chance to take a test on your suggestion above: It doesn't work! > > I booted this time again from the USB thumdrive with the recent FreeBSD 12-CURRENT image > without the compiler and mount the still intact usr/obj and usr/src from the corrupted > SSD onto the USB thumdrive and tried to do as requested. > > make -C /usr/src WITHOUT_SYSTEM_COMPILER=1 DESTDIR=/wherever installworld > > The script bugs out at "bsd.compiler.mk line 145: Unable to determine compiler type for > CC=cc. Consider setting COMPILER_TYPE" > > Setting COMPILE_TYPE=cc results in "sh: cc not found", setting to "clang" doesn't work > either. > > Apart from the fact of CURRENT to be incapable of rescuing, there seems to be a very > serious issue with CURRENT regarding its filesystem stability and I do not know how to > address this in the correct way :-( > > I use NanoBSD for about a year for several projects and I already have a useful USB > thumdrive with a full grown system (~ 836 MB if I'm not confused including the > compiler). I tried to makeinstallworld, but this time, it seems that also the usr/obj > has been corrupted, so I had to perform a buildworld, which is still running. > > From my little experiences with building NanoBSD and the use of etc/src.conf as the > source for delegating what is used in the target image and not, I was really wondering > that the "RELEASE" build infrastructure is not using a predefined src.conf to reduce the > size and content of the resulting image. Instead, some "WITHOUT_TOOLCHAIN" hidden and > hard coded knobs are used :-( Somehow the whole thing got more confusing. > > I can understand that some people want some small images for their installation > processes, but I think they can perform the task of creating their own images via make > relaese very easily. > In cases were someone crashed, like me, it would a great benefit having some real rescue > stuff around instead of crippled images. But this might be a different view. > > regards, > > oh > I now have on one box a partially restored system. It seems, that this time, a very serious bug made proper work. I need to restore the library installation/structure in /usr/lib. It is corrupted and has been corrupted by "make installword" with WITHOUT_SYSTEM_COMPILER=1 (which seems useless in this case) and COMPILER_TYPE=clang. There are dead links in /usr/lib, especially libthr.so.X is pointing to nothing. As a result of this desaster I can state, that the images provided officially are not capable of performing such a rescue. Dead man in the water :-( -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC