Re: ISO image: where is the CLANG compiler?

From: O. Hartmann <ohartmann_at_walstatt.org>
Date: Sun, 22 Jan 2017 00:24:52 +0100
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).

Received on Sat Jan 21 2017 - 22:25:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC