Skip to Content.
Sympa Menu

sm-users - Re: [SM-Users] Install without ISO

sm-users AT lists.ibiblio.org

Subject: Sourcemage Users List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-users AT lists.ibiblio.org
  • Subject: Re: [SM-Users] Install without ISO
  • Date: Fri, 9 Dec 2005 14:13:49 +0100

Am Thu, 8 Dec 2005 12:16:22 -0600
schrieb "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>:

> On Dec 08, Karsten Behrmann [BearPerson AT gmx.net] wrote:
> > This guide applies to the 0.9.5, at least mostly:
> > http://wiki.sourcemage.org/install_using_chroot
>
> FYI the current www/wiki/bugs/etc.sourcemage.org box was installed using
> that howto (the host as delivered by the hosting center was running FC4).
> It worked fine.

OK, I used this guide for install to local hard drive from network-booted
host system (http://wiki.sourcemage.org/install_root_and_others didn't seem
to be applicable to me and I must admit that I hardly understood its
benefits) and yes, it works, basically.

One thing to note should be that one shouldn't take the chroot commands too
literal, meaning that one may need to add some `env -i SHELL=...` and `.
/etc/profile` to get somewhere out from a different host distro. I installed
from a Gentoo system that has some paths to things like PAGER different.

I did the install.sh and the chrooted into the install for the rebuild. Again
I plea for the storing of the output of programs ran by the install menu (at
least having a menu point "view last output" available); I just was in the
middle of reading what grub-install told me as the menu reappeared and left
me unsure if it went ok or not.

Then, in the chroot of the fresh to-be Sourcemage system, I stumbled over one
really disturbing disturbance: `less` gave me a segmentation fault! I set
PAGER to more (which worked) and did the rebuild, after which less is OK now.

The rebuild went through mostly - it failed leaving 4 spells in the queue;
the offending one being wget: the gpg check failed since no public key was
found... after overriding the gpg check I got my system complete; installed
ssh and its init script, rebooted and was on the line again. Interestingly,
another attempt to `cast -c wget` works now since there is the WORKS_FOR_ME
thingy set. Is this something local; set because I forced install of wget
before? I didn't update grimoire... but what I had done was `cleanse --fix`
that found many replaced man-pages as usual ... and a changed gcc spec file
and that apparently needed rebuild of gcc. I didn't like the idea right now
and said no to that, which left me with the message that gcc is hopelessly
broken.

I diffed the current spec file and the one in the gcc install cache:

root@kiste:~# diff -ru oldspec gcc-3.4.4.specs
--- oldspec 2005-12-09 13:43:53.000000000 +0100
+++ gcc-3.4.4.specs 2005-12-09 13:39:41.000000000 +0100
@@ -122,3 +122,42 @@
*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) %l %{pie:-pie} %X
%{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z}
%{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %(link_libgcc) %o
%{fprofile-arcs|fprofile-generate:-lgcov}
%{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}

+@c++-header:
+%{E|M|MM:cc1plus -E -D_GNU_SOURCE %(cpp_options) %2 %(cpp_debug_options)}
%{!E:%{!M:%{!MM: %{save-temps|no-integrated-cpp:cc1plus -E -D_GNU_SOURCE
%(cpp_options) %2 -o %{save-temps:%b.ii} %{!save-temps:%g.ii} \n} cc1plus
%{save-temps|no-integrated-cpp:-fpreprocessed %{save-temps:%b.ii}
%{!save-temps:%g.ii}}
%{!save-temps:%{!no-integrated-cpp:%(cpp_unique_options)}} %(cc1_options)
-D_GNU_SOURCE %2 %{+e1*} -o %g.s %{!o*:--output-pch=%i.gch}
%W{o*:--output-pch=%*}%V}}}
+
+@c++:
+%{E|M|MM:cc1plus -E -D_GNU_SOURCE %(cpp_options) %2 %(cpp_debug_options)}
%{!E:%{!M:%{!MM: %{save-temps|no-integrated-cpp:cc1plus -E -D_GNU_SOURCE
%(cpp_options) %2 -o %{save-temps:%b.ii} %{!save-temps:%g.ii} \n} cc1plus
%{save-temps|no-integrated-cpp:-fpreprocessed %{save-temps:%b.ii}
%{!save-temps:%g.ii}}
%{!save-temps:%{!no-integrated-cpp:%(cpp_unique_options)}} %(cc1_options)
-D_GNU_SOURCE %2 %{+e1*} %{!fsyntax-only:%(invoke_as)}}}}
+
+@c++-cpp-output:
+%{!M:%{!MM:%{!E: cc1plus -fpreprocessed %i %(cc1_options) %2 %{+e*}
%{!fsyntax-only:%(invoke_as)}}}}
+
+.ii:
+@c++-cpp-output
+
+.cc:
+@c++
+
+.cp:
+@c++
+
+.cxx:
+@c++
+
+.cpp:
+@c++
+
+.c++:
+@c++
+
+.C:
+@c++
+
+.CPP:
+@c++
+
+.H:
+@c++-header
+
+.hh:
+@c++-header
+


Are these changes essential and from where do they come? They look g++
related... Since g++ is a separete spell (but still gcc), I suppose this
installed a spec file adding the C++ stuff. Now, why does this break gcc? Why
isn't the file just attributed to g++ and with the replaced man pages? And
what happens if I install other parts of the gcc suite? What happens if I
allow reinstallation of gcc?
Probably the same I ingorantly did: I replaced the specs file with the one
from the cache and that makes cleanse happy... now I'm curious if the next
C++ stuff I want to install will compile...



At last, I spotted some lines that don't look too calming during pkgconfig
install:

Building pkgconfig
Unpacking source file pkg-config-0.18.1.tar.gz for spell pkgconfig.
Using gcc version: 3.4.4
Installing in dir: /usr/src/pkg-config-0.18.1
pkgconfig 0.18.1
configure.in:80: warning: AC_CANONICAL_HOST invoked multiple times
configure.in:391: warning: AC_CACHE_VAL(glib_cv_sane_realloc, ...):
suspicious presence of an AC_DEFINE in the second argument, where no actions
should be taken
autoconf/general.m4:1799: AC_CACHE_VAL is expanded from...
configure.in:391: the top level
configure.in:80: warning: AC_CANONICAL_HOST invoked multiple times
configure.in:391: warning: AC_CACHE_VAL(glib_cv_sane_realloc, ...):
suspicious presence of an AC_DEFINE in the second argument, where no actions
should be taken
autoconf/general.m4:1799: AC_CACHE_VAL is expanded from...
configure.in:391: the top level

I suppose that this isn't fatal, but it's not reassuring, either...



Conclusion
----------

So, apart from the usual glitches (every install is a bit different...) the
system seems to be up and running. Next time I'll try to install it to a NFS
share like the old host system (and see how it performs compared to Gentoo
there... I see a high chance to beat `emerge --sync` which takes AGES with
all its small files and the portage cache).


So, folks,

Thomas.




Archive powered by MHonArc 2.6.24.

Top of Page