Проблемы при установки из Stage 1
Пытаюсь установить Gentoo 2008 из stage 1 с использованием свежего дерева портежей, но почему-то при запуске бутстрапа, спустя некоторое время сборка прекращается с ошибками, подскажите пожалуйста в чем проблема:
Используемые файлы:
stage1-x86-2008.0.tar.bz2 (взят с установочного диска Gentoo 2008)
portage-latest.tar.bz2 (23.01.2009) взят с зеркала http://debian.ihug.co.nz/gentoo/snapshots/?C=S;O=A
Все тарболлы проверял на целостность - все в норме. Система x86.
Список тарболлов необходимых для бутстрапа получил командой /usr/portage/scripts/bootstrap.sh --fetchonly
после чего их скачал вручную и положил в отведенное им место.
Если использовать портежи с установочного диска, то все ставится без проблем, но мне нужно именно свежее дерево портежей.
Вот лог сборки:
>>> Unpacking source...
>>> Unpacking lzma-4.32.7.tar.gz to /var/tmp/portage/app-arch/lzma-utils-4.32.7/work
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/app-arch/lzma-utils-4.32.7/work/lzma-4.32.7 ...
* econf: updating lzma-4.32.7/config.guess with /usr/share/gnuconfig/config.guess
* econf: updating lzma-4.32.7/config.sub with /usr/share/gnuconfig/config.sub
./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --build=i686-pc-linux-gnu
checking if debugging code should be compiled... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-linux-gnu-g++... no
checking for i686-pc-linux-gnu-c++... no
checking for i686-pc-linux-gnu-gpp... no
checking for i686-pc-linux-gnu-aCC... no
checking for i686-pc-linux-gnu-CC... no
checking for i686-pc-linux-gnu-cxx... no
checking for i686-pc-linux-gnu-cc++... no
checking for i686-pc-linux-gnu-cl.exe... no
checking for i686-pc-linux-gnu-FCC... no
checking for i686-pc-linux-gnu-KCC... no
checking for i686-pc-linux-gnu-RCC... no
checking for i686-pc-linux-gnu-xlC_r... no
checking for i686-pc-linux-gnu-xlC... no
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking for C++ compiler default output file name...
configure: error: C++ compiler cannot create executables
See `config.log' for more details.
!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/app-arch/lzma-utils-4.32.7/work/lzma-4.32.7/config.log
[31;01m*[0m
[31;01m*[0m ERROR: app-arch/lzma-utils-4.32.7 failed.
[31;01m*[0m Call stack:
[31;01m*[0m ebuild.sh, line 49: Called src_compile
[31;01m*[0m environment, line 2060: Called _eapi0_src_compile
[31;01m*[0m ebuild.sh, line 593: Called econf
[31;01m*[0m ebuild.sh, line 529: Called die
[31;01m*[0m The specific snippet of code:
[31;01m*[0m die "econf failed"
[31;01m*[0m The die message:
[31;01m*[0m econf failed
[31;01m*[0m
[31;01m*[0m If you need support, post the topmost build error, and the call stack if relevant.
[31;01m*[0m A complete build log is located at '/var/tmp/portage/app-arch/lzma-utils-4.32.7/temp/build.log'.
[31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/app-arch/lzma-utils-4.32.7/temp/environment'.
Такое ощущение, что куда-то исчез компилятор ... Только непонятно как это может быть ??? До этого пакета собирались несколько пакетов, причем никаких проблем не было, а тут на тебе.
Может быть несовместимы версии пакетов stage1-x86-2008.0.tar.bz2 и portage-latest.tar.bz2, но ведь это самые последние версии?
Подскажите пожалуйста что не так ???
- Для комментирования войдите или зарегистрируйтесь
На вашем месте я бы собрал
На вашем месте я бы собрал сначала через портежи с установочного диска, а потом бы сделал emerge --sync. А вообще тарболы я брал с зеркала яндекса ftp://mirror.yandex.ru/gentoo-distfiles/snapshots/ для портежей и ftp://mirror.yandex.ru/gentoo-distfiles/releases/x86/2008.0/stages/ для стейджей. Попробуйте скачать оба архива и сделать всё заново.
А смысл какой заново сливать
А смысл какой заново сливать файлы, они же не битые ?
Что касается emerge --sync - так этож времени сколько надо чтобы все собрать, неделю, да и с трафиком не особо...
Тоесть, насколько я понял stage1-x86-2008.0.tar.bz2 и portage-latest.tar.bz2 (23.01.2009) должны собираться вместе?
В каком смысле вместе?
В каком смысле вместе? Скачиваете оба эти архива и действуете. А насчёт emerge --sync это не особо долго, у меня скорость 10 кбайт/сек и синхронизируется где-то за полчаса.
Ну, знаете ли, всякое бывает =). Чёрная магия и всё такое =). Много раз тупо перекачивал какой нить архив или образ и всё чудеснейшим образом работало. Но лучше скачивать конечно же с прямых/официальных источников, в данном случае с gentoo.org а не с debian.
Кстати, а файл
Кстати, а файл portage-20090123.tar.lzma обязательно нужно сливать или нет?
Я его не скачивал, мне кажется достаточно и *.tar.bz2, может быть в этом причина ?
portage-20090123.tar.lzma не
portage-20090123.tar.lzma не нужно сливать, это тот же архив просто упакованный другим архиватором. Скачивайте tar.bz2 они весят меньше, чем lzma или tar.gz
ОК, спасибо, буду
ОК, спасибо, буду пробовать...
__________________
PS: Кстати действительно md5 у файлов portage-latest.tar.bz2 с яндекса и debian разные... Чудеса да и только...
так lzma же более совершенный
так lzma же более совершенный алгоритм, почему он должен весить больше?!
хм, действительно, простите
хм, действительно, простите великодушно за некомпетентность =). Но лично когда я создаю архив, tar.bz2 получается несколько меньше... может всё зависит от типа фалов?
надеюсь всё же файлов ;)
надеюсь всё же файлов ;)
ты пробовал с ключом -9 ?
Да, от типа фаЙлов =). Всегда
Да, от типа фаЙлов =). Всегда сжимаю только с ключом 9, т.к разница во времени для меня не критична, а размер важен
когда собираешь со stage1
когда собираешь со stage1, нужно собирать toolchain (gcc,glibc,linux-headers) тех же версий, что и в stage, потом уже обновлять (когда готова stage3)
при сборке не стоит выставлять дополнительные USE ключи, делай это только после emerge -e system (когда у тебя готова stage3)
Совершенно верно!
Откуда вывод, что человеку для достижения его целей лучше всего сгодился бы stage3 из autobuilds...
Stage 3 не дает такой
Stage 3 не дает такой оптимизации как stage 1, да к тому-же ставит толпищу совершенно ненужных мне программ.
На самом деле
satge1 - это вообще без оптимизации и почти без USE-флагов :) И к тому же - со статической линковкой. И пока satge1 в stage3 не превратится, ничего этого и не будет. Так что "толпища совершенно ненужных программ" всё равно будет в конечном итоге установлена! ;-)
Это например? nano?
Это например? nano?
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Нет не nano, а другие,
Нет не nano, а другие, названия которых запоминать небыло особой нужды. Да и помимо этого, неоднократно замечалось, что при установке со stage 3 возникают проблемы с java. Я вообще молчу про графический "неработающий" инсталятор, который падает в аут посреди процесса инсталляции. Если копнуться дальше, то проблем в gentoo хватает вполне...
На работе купили 10 новых компов, все одинаковые абсолютно. Ставили на них Gentoo 2008 по одному и тому-же описанию (которое было написано сотрудником, который работает у нас и одновременно является одним из разработчиков AltLinux (пишет дрова)) и несмотря на это - процесс установки на всех компах шел почему-то по разному!!! И несмотря на то, что все делалось по одной "бумажке" - система на всех компах почему-то собралась по разному...
Так што дело тут не в нано. Просто Gentoo потихоньку становится неуправляемой системой...
_____________
PS: Никого нихотел обидеть, но просто если уж разработчики таких систем иногда не могут ничего понять, то обычному пользователю остается только застрелится...
>На работе купили 10 новых
>На работе купили 10 новых компов, все одинаковые абсолютно.
>система на всех компах почему-то собралась по разному...
зачем делать одну и ту же работу 10 раз?! куда разумнее взять один комп, отладить на нём, сделать stage4 и перенести ОС на другие машины одной командой, перенеся также таблицу разделов и загрузчик ;)
Согласен полностью, но иногда
Согласен полностью, но иногда работать не очень прёт, а пока ставится gentoo со stage 1 можно заняться чем нибудь другим :)
поток сознания...
поток сознания...
Вполне логично, что по-разному!
С одного IP в сутки 10 раз дерево не синхронизируешь, а поскольку rsync-сервер не развёртывался (ну, раз все машины ставились одинаково), следует предположить, что синхронизация дерева проводилась в разное время. Отсюда и немножко разные настройки, разные верси прог. Ну, и не думаю, что в ALT-е держат бестолковых! ;-)
Никакой синхронизации не
Никакой синхронизации не производилось, т.к отсутствует соединение с инетом, тогда в этом просто небыло необходимости...
Мы просто заказали срез всего дерева на 16 DVD (вроде за июнь 2008) через инет и всё с него ставили.
А на данный момент я ставлю систему на домашнем компе, т.к. некоторую работу приходится делать на дому...
в целях изучения ОС собрать
в целях изучения ОС собрать со stage1 будет вполне полезно :)
+1 сам собирал с 1 стейджа
+1 сам собирал с 1 стейджа (впервые) и познал столько нового! Правда ставил я всё это дело около месяца неторопясь =)
CHOST не тот
Похоже, что ты изменил СHOST в /etc/make.conf
В stage1-x86-2008.0.tar.bz2 эта переменная установлена в "i486-pc-linux-gnu", и компилятор там соответствующий. Судя по сообщениям configure - CHOST у тебя - i686-pc-linux-gnu. Отсюда и грабли...
Если хочешь сменить CHOST - после смены надо собрать binutils, gcc и glibc. Хотя, в моем случае хватило сборки gcc, а потом bootstrap без проблем собрал все остальное.
Кстати, прикольно научить систему в stage1 использовать distcc - оказывается, это вполне реально, хоть и мороки много.
Нет это я не менял. Изменил
Нет это я не менял. Изменил только:
CFLAGS="-march=prescott -O3 -pipe"
CXXFLAGS="$(CFLAGS)"
MAKEOPTS="-j3"
Ничего больше в этом файле не менял.
CHOST у меня по умолчанию - i686-pc-linux-gnu
Странно. Выходит, что у меня
Странно. Выходит, что у меня другой stage1-x86-2008.0? Такое может быть?
Я брал с distfiles.gentoo.org, и там - i486-pc-linux-gnu, прописан в /etc/make.conf (который есть в этом архиве по умолчанию). Соответственно - в голом stage1 бинарники компилера находятся /usr/i486-pc-linux-gnu/<и т.д.>, там же binutils.
В моем случае все было так же, как ты описал, на lzma-utils произошел вылет, по той же самой причине. Когда начал копать - нашел единственное объяснение: я копировал вместо имеющегося в stage1 make.conf свой, в котором CHOST=i686-pc-linux-gnu. Естественно, что сборка gcc помогла решить проблему, а потом bootstrap изящно завершил картину.
Я думаю вы были правы с самого начала!
Всё верно, stage1 для x86 -- это CHOST с i486. i686 - это уже stage2/stage3. Думаю, у всех так...
так что делать? у меня тоже
так что делать? у меня тоже такое:
>>> Compiling source in /var/tmp/portage/app-arch/lzma-utils-4.32.7/work/lzma-4.32.7 ...
...
checking whether make sets $(MAKE)... yes
checking for x86_64-pc-linux-gnu-g++... no
checking for x86_64-pc-linux-gnu-c++... no
...
:\
или в предыдущем посте решение? надо проверить...
у мну
CHOST="x86_64-pc-linux-gnu"
Это немножко другая проблема...
А что говорит emerge --info? (можно через pastebin)
а что именно
а что именно интересует?
---
Portage 2.1.6.4 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r7 x86_64)
=================================================================
System uname: Linux-2.6.24-gentoo-r7-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5000+-with-glibc2.2.5
Timestamp of tree: Sun, 18 Jan 2009 01:45:01 +0000
app-shells/bash: 3.2_p17-r1
dev-lang/python: 2.4.4-r13
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox: 1.2.18.1-r2
sys-devel/autoconf: 2.61-r1
sys-devel/automake: 1.10.1
sys-devel/binutils: 2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool: 1.5.24
virtual/os-headers: 2.6.23-r3
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LDFLAGS="-Wl,-O1"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl amd64 berkdb bzip2 cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog midi mmx mudflap multilib ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl sse sse2 ssl sysfs tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
----
пробовал emerge lzma вышло такое
!!! All ebuilds that could satisfy "app-arch/lzma" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-arch/lzma-4.57 (masked by: ~amd64 keyword)
- app-arch/lzma-4.43 (masked by: ~amd64 keyword)
- app-arch/lzma-4.27 (masked by: missing keyword)
---
мейк я не трогал, собираю из stage1
CFLAGS="-O2 -pipe"
CXXFLAGS="${CFLAGS}"
CHOST="x86_64-pc-linux-gnu"
USE="mmx sse sse2"
--- кочал с mirrors.de откуда-то...
А интересует вот что...
Последовательность действий и инструкция какая используется? Вот, например, одно из руководств. Но сборка из stage1/stage2 официально не поддерживается и официально не описана. Это не нужно простому юзеру. Багов при такой сборке можно встретить больше. Оптимизация всё равно начинается где-то после satge2, не раньше. Зачем оно вам? У вас даже в CFLAGS/CXXFLAGS не выставлен тип процессора -march=... ИМХО, вам лучше развёртывать со stage3 по хендбуку...
Скочал Stage3, будем
Скочал Stage3, будем переделывать! :)
Траффик медленный, за 4 часа закочалось.
В stage1 gcc с nocxx собран,
В stage1 gcc с nocxx собран, нет там c++ компилятора. Собери lzma-utils с USE="nocxx", потом собери нормальный gcc и дальше уже развлекайся
Ubuntu is an African Word that means "Gentoo is too hard for me"
+1Всёравно эту затею с
+1
Всёравно эту затею с stage1 никогда не брошу! :)
Причём всем полезно знать что и к чему там, ато я поначалу вообще не ожидал подвохов.
А как lzma-utils собирать, тоже emerge, с USE="nocxx" не заглючит?
Я дотого в crux сидел и всё собирал естественным путём make all :) хотя это и там даже
не дистриб вей, а emerge только увидел недавно.
может lzma-utils без emerge собрать :)
как собирать:# USE="nocxx"
как собирать:
и ничего не надо ручками собирать, в крайнем случае ebuild xxx unpack,...,ebuild xxx merge
Ubuntu is an African Word that means "Gentoo is too hard for me"
после сборки lzam-utils с
после сборки lzam-utils с USE="nocxx" у меня появилась трабла с man - при попытке покурить манов писал, что не может распаковать lzma-архив... решилось пересборкой man с USE="-lzma"
Где мало слов, там вес они имеют... (с) W. Sheakespeare
И все-таки я сделал как мне посоветовал уважаемый Tormentor.
Именно так я и сделал. Все вроде бы сработало, но хотелось бы уточнить как правильно производить полное обновление всей системы:
----Вариант №1----
emerge --sync
emerge -e system
----Вариант №2----
emerge --sync
emerge -uND world
revdep-rebuild
Если оба варианты неверны то черкните плиз правильный вариант.
Встретился с той же
Встретился с той же проблемой, почитал советы по поводу "nocxx", покурил скрипт bootstrap.sh... Все оказалось намного проще. Собственно, никому не надо делать emerge.
При ошибке типа "C++ compiler cannot create executables" в /etc/make.conf прописывается переменная STAGE1_USE="nocxx" , дальше перезапускается bootstrap.sh и все, у вас указан флаг для компиляции с помощью bootstrap.sh. Проблема решена :)
О, не знал о таком. Спасибо
О, не знал о таком. Спасибо за инфу :)
Ubuntu is an African Word that means "Gentoo is too hard for me"
Насколько я понял по
Насколько я понял по завершении работы bootstrap.sh, т.е перед emerge -e system переменную STAGE1_USE="nocxx" нужно убрать ? Или на emerge -e system она не влияет?
Ну вероятно она задействуется
Ну вероятно она задействуется только при [пере]сборке stage1 через bootstrap.sh, поэтому не повлияет на работу емержа
Ubuntu is an African Word that means "Gentoo is too hard for me"
Костыль это, а не решение (ИМХО)
> При ошибке типа "C++ compiler cannot create executables" в /etc/make.conf прописывается переменная STAGE1_USE="nocxx" , дальше перезапускается bootstrap.sh и все, у вас указан флаг для компиляции с помощью bootstrap.sh. Проблема решена :)
Вот это и есть костыль и нужно 10 раз подумать, прежде чем такое советовать! STAGE1_USE прописана в каждом профиле и менять её не следует. Сборка стеджей определяется не только профилем и снэпшотом портежей, но и системой каталист, которая генерит эти стейджи и LiveCD.
Если приглядеться в исходники catalyst, то там много чего дописывается перед компиляцией. Например, даже добавляется "nodoc noman noinfo" во FEATURES. Поэтому из третьего стейджа много чего приходится пересобирать до полного соответствия выбраным USE-флагам и т.п. Именно в этом выборе и проблема.
Очевидно, что плюсЫ не нужны на первом стейдже, но если юзер это умудрился поменять. Опять же нужно умудриться, ибо при сборке первых двух стеджей в USE пропускается далеко не всё - это определяется профилем, bootsrap.sh и каталистом.
да у них там архивы битые!
да у них там архивы битые! :)
или ебилды кривые, а я в их не рублю...
в distfiles всё в формате bz2 как положено, а эти два нафига такие непонятно!
gentoo-headers-2.6.27-2.tar.lzma
gentoo-headers-base-2.6.27.tar.lzma
и недокаченные чтоли по 8-10 килобайт... Архивы битые точно проверил.
А этот нормальный ;-
lzma-4.32.7.tar.gz
Стоит ли сохранить то что накочало? главное ведь amd64 или ещё различия есть в тарболах?
кто сказал что дистфайлсы
кто сказал что дистфайлсы положено хранить в bz2? кто в чем хочет, в том и хранит
lzma-более прогрессивный метод сжатия, а gentoo-headers и не должны много весить, это же просто заголовки
Ubuntu is an African Word that means "Gentoo is too hard for me"
Очень похоже на проблему
Очень похоже на проблему курицы и яйца :)
Для сборки lzma-utils и gmp нужен gcc с поддержкой c++,
а для сборки gcс нужно предварительно собрать lzma-utils и gmp.
Для себя эту проблему решил так:
После chroot в собираемую систему и env-update && source /etc/profile собираем компилятор с поддержкой c++:
Далее bootstrap и все как обычно.
Такой косяк был у меня когда
Такой косяк был у меня когда я прервал бутстрап. Пофиксилось перезапуском бутстрапа
/usr/portage/scripts/bootstrap.sh
USE="nocxx" думаю использовать не стоит, да и бутстрап это не только пересборка gcc
Gentoo уже не та....
Похоже вряд-ли исправят эту ошибку : http://bugs.gentoo.org/257901