his bug is for tracking bugs with the test-stages. It is used to help the releng-team to keep track of all the stuff that should be / needs to be fixed. The test-stages have a datestamp in their filename - please mention this datestamp when reporting anything. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I'm not sure this bug belongs here, but here goes. I'm doing a stage1/network install in a VMWare virtual machine using the 2005.0 testing minimal install CD 20050115. I got the stage1 and portage tree in OK, did an "emerge sync" and got "bootstrap.sh" completed successfully. So the system is in between stage2 and stage3. When I did the "emerge system", it croaked compiling iputils-021109-r3. It will take me a while to copy the documentation from the VMWare virtual machine into this bug report (USB memory sticks are your friend), but the error message is /usr/lib/gcc ... bin/ld: cannot find -lfl Also, I have set "ACCEPT_KEYWORDS=~x86" in /etc/make.conf. This looks a lot like bug http://bugs.gentoo.org/show_bug.cgi?id=59428, except that the compiler version is different. This looks easy to fix ... just emerge whatever iputils is looking for and continue with "emerge system". I don't know my way around the Portage utilities well enough to do that on my own yet, though.
Got it ... here's the log of "emerge system" Calculating system dependencies >>> Unpacking source... >>> Unpacking iputils-ss021109-try.tar.bz2 to /var/tmp/portage/iputils-021109-r3/work [32;01m*[0m Applying 021109-gcc34.patch ... [A[121G [34;01m[ [32;01mok[34;01m ][0m [32;01m*[0m Applying 021109-no-pfkey-search.patch ... [A[121G [34;01m[ [32;01mok[34;01m ][0m [32;01m*[0m Applying 021109-ipg-linux-2.6.patch ... [A[121G [34;01m[ [32;01mok[34;01m ][0m [32;01m*[0m Applying 021109-syserror.patch ... [A[121G [34;01m[ [32;01mok[34;01m ][0m [32;01m*[0m Applying 021109-uclibc-no-ether_ntohost.patch ... [A[121G [34;01m[ [32;01mok[34;01m ][0m [32;01m*[0m Applying iputils-021109-linux-udp-header.patch ... [A[121G [34;01m[ [32;01mok[34;01m ][0m >>> Source unpacked. i686-pc-linux-gnu-gcc i686-pc-linux-gnu-ar i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../include-glibc -DIPSEC_DEBUG -DIPSEC -DINET6 -Wall -c -o ipsec_dump_policy.o ipsec_dump_policy.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../include-glibc -DIPSEC_DEBUG -DIPSEC -DINET6 -Wall -c -o key_debug.o key_debug.c bison -y -d -p __libyy policy_parse.y i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../include-glibc -DIPSEC_DEBUG -DIPSEC -DINET6 -Wall -c -o ipsec_get_policylen.o ipsec_get_policylen.c mv y.tab.c policy_parse.c mv y.tab.h policy_parse.h i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../include-glibc -DIPSEC_DEBUG -DIPSEC -DINET6 -Wall -c -o pfkey.o pfkey.c lex -P__libyy policy_token.l mv lex.__libyy.c policy_token.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../include-glibc -DIPSEC_DEBUG -DIPSEC -DINET6 -Wall -c -o ipsec_strerror.o ipsec_strerror.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../include-glibc -DIPSEC_DEBUG -DIPSEC -DINET6 -Wall -c -o pfkey_dump.o pfkey_dump.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../include-glibc -DIPSEC_DEBUG -DIPSEC -DINET6 -Wall -c -o policy_parse.o policy_parse.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../include-glibc -DIPSEC_DEBUG -DIPSEC -DINET6 -Wall -c -o policy_token.o policy_token.c i686-pc-linux-gnu-ar rcs libipsec.a ipsec_dump_policy.o key_debug.o policy_parse.o ipsec_get_policylen.o pfkey.o policy_token.o ipsec_strerror.o pfkey_dump.o i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../libipsec -I../include-glibc -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wall -c -o setkey.o setkey.c bison -d parse.y -o parse.c bison -d parse.y -o parse.c lex -t token.l > token.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../libipsec -I../include-glibc -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wall -c -o pfkey.o pfkey.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../libipsec -I../include-glibc -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wall -c -o pfkey_dump.o pfkey_dump.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../libipsec -I../include-glibc -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wall -c -o key_debug.o key_debug.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../libipsec -I../include-glibc -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wall -c -o ipsec_strerror.o ipsec_strerror.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../libipsec -I../include-glibc -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wall -c -o parse.o parse.c i686-pc-linux-gnu-gcc -march=athlon-xp -O3 -pipe -fomit-frame-pointer -include ../include-glibc/glibc-bugs.h -I../libipsec -I../include-glibc -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wall -c -o token.o token.c parse.y: In function `setkeymsg': parse.y:635: warning: dereferencing type-punned pointer will break strict-aliasing rules parse.y:651: warning: dereferencing type-punned pointer will break strict-aliasing rules i686-pc-linux-gnu-gcc -o setkey setkey.o parse.o token.o pfkey.o pfkey_dump.o key_debug.o ipsec_strerror.o -L../libipsec -lipsec -lfl /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lfl collect2: ld returned 1 exit status make: *** [setkey] Error 1 rm token.c !!! ERROR: net-misc/iputils-021109-r3 failed. !!! Function src_compile, Line 77, Exitcode 2 !!! setkey failed !!! If you need support, post the topmost build error, NOT this status message. ------------------------------------------------------------------------------ and "emerge info" Gentoo Base System version 1.6.8 Portage 2.0.51-r12 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20040808-r1,glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r4 i686) ================================================================= System uname: 2.6.10-gentoo-r4 i686 mobile AMD Athlon(tm) XP 2000+ Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jan 11 2005, 18:27:07)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: [Not Present] sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: [Not Present] virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apm arts avi berkdb bitmap-fonts crypt cups encode f77 font-server foomaticdb fortran gdbm gif gpm imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl svga tcpd truetype truetype-fonts type1-fonts x86 xml2 xmms xv zlib" Unset: LDFLAGS, PORTDIR_OVERLAY
Actually, the stages have changed quite a bit. The problem is that the bootstrap.sh script needs modification to work. Also, you must run "emerge -e system" to get a running machine. The problem is that flex did not get reinstalled into stage2 from stage1 because portage already thought the version was up to date. This is due to us making changes to the stages for stage1 and stage2 to keep them from having orphaned files. The fix that I have been using locally, is to change "emerge ${STRAP_EMERGE_OPTS} ${myLIBC} ${myBASELAYOUT} ${myZLIB} || cleanup 1" to "emerge -e ${STRAP_EMERGE_OPTS} ${myLIBC} ${myBASELAYOUT} ${myZLIB} || cleanup 1" near the bottom of the bootstrap.sh script.
Looks good ... is the "emerge -e" requirement new for 2005.0, or just something that needs to be done in this pre-release testing? I didn't see it in the online documentation.
Well, the bootstrap.sh script has not been updated to take advantage of the new way the stages are built, so this will only be for the pre-release.
Sorry ... I should have been clearer in my question. It was the change from the documented "emerge system" to "emerge -e system" I was asking about. Will 2005.0 require a stage1 - stage2 transition to be started with "emerge -e system" once the 2005.0 has been released, or will "emerge system", as given in the documentation, suffice?
Honestly, we don't know yet.
I'm currently testing with x86-installcd-minimal-2005.0-rc4.iso stage3-x86-2005.0-20050110.tar.bz2 portage-20050121.tar.bz2 all downloaded about 16:00 Pacific Standard Time. The only thing I've noticed that's unusual so far is the following: After unpacking the stage3 and the portage snapshot, I took a look at the default /etc/make.conf, and it had CHOST="i386-pc-linux-gnu" However, /etc/make.conf.example had CHOST="i686-pc-linux-gnu" I wasn't sure what to do, so I decided to be conservative and used the i386 setting. Would i686 have worked with an x86 stage3, or does the make.conf.example in an x86 stage need to have CHOST set for i386?
make.conf.example is installed by portage, and it even says i686-pc-linux-gnu when you're installing on a sparc box... ;] You actually need to stick with the CHOST provided by your stage tarball, otherwise you'll have problems. When the tarball is built, catalyst inserts the proper CHOST depending on what subarch we are building.
I figured I did the right thing, given all the warnings in the documentation. Couldn't catalyst also set CHOST in "make.conf.example" as well, making it a little more bulletproof for beginners? New issue: latest minimal install CD and a stage1 install from x86-installcd-minimal-2005.0-rc5.iso stage1-x86-2005.0-20050110.tar.bz2 portage-20050121.tar.bz2 I booted the install CD, which worked fine. I unpacked the tarballs, again fine. Then I did the chroot, and following the documentation, did an "emerge --sync", thus over-writing the Portage snapshot from "/dev.gentoo.org/~wolf31o2/". Was the sync a mistake? Because not too long after that, the actual bootstrap croaked thusly: [[ (3/6) Emerging headers/binutils ]] Calculating dependencies !!! All ebuilds that could satisfy "virtual/os-headers" have been masked. !!! One of the following masked packages is required to complete your request: - sys-kernel/linux-headers-2.6.8.1-r4 (masked by: package.mask, ~x86 keyword) # <johnm@gentoo.org> (1/12/2004) # Masking all 2.6 versions of kernel packages which were originally # 2.4 only so that we can merge 2.6 with 2.4 without forcing a # mass upgrade. # this includes the headers too - sys-kernel/linux-headers-2.4.21-r1 (masked by: profile) - sys-kernel/linux-headers-2.4.26 (masked by: profile, -* keyword) - sys-kernel/linux-headers-2.4.21 (masked by: profile) - sys-kernel/linux-headers-2.4.23_p3 (masked by: profile, -* keyword) - sys-kernel/linux-headers-2.4.23 (masked by: profile, -* keyword) - sys-kernel/linux-headers-2.4.25 (masked by: profile, -* keyword) - sys-kernel/linux-headers-2.2.26 (masked by: profile, -* keyword) - sys-kernel/linux-headers-2.6.8.1-r2 (masked by: package.mask) - sys-kernel/linux-headers-2.0.40 (masked by: profile, -* keyword) - sys-kernel/linux-headers-2.4.22 (masked by: profile, ~x86 keyword) For more information, see MASKED PACKAGES section in the emerge man page or section 2.2 "Software Availability" in the Gentoo Handbook. I assume an appropriate entry in /etc/portage/package.keywords will fix this, and am going to try that.
First off, there is no way for catalyst to manage the make.conf.example since it is installed by the portage package. Second, you cannot use a snapshot and then sync. If you're going to sync, do not unpack the snapshot. That snapshot does *not* match the state of the portage tree and should not be used for anything other than stage generation. A word of warning, the stages have been generated with changes in them that will not show up in the actual portage tree until the release is completed and on the mirrors. As for the LiveCD, it has its own bug at bug #77881.
*** Bug 81937 has been marked as a duplicate of this bug. ***
Looks like a typo sneaked into the linuxrc (using x86-installcd-minimal-2005.0-rc5.iso): if [ "${DO_evms2}" -a "${USE_LVM2_NORMAL}" -eq '1' ] should be: if [ "${DO_evms}" -a "${USE_EVMS_NORMAL}" -eq '1' ] Oh, and isolinux/help.msg needs to be updated to reflect the new boot options.
Created attachment 51337 [details, diff] Patch againt livecd-functions.sh This patch correctly exports CDBOOT even if using a cdroot=/dev/foo parameter.
Argh - meant to file the last two comments to bug #77881. Sorry.
Done.
