Re: RELENG_8 does not build with CPUTYPE=core2
On 14/05/2011 02:38, Scott Allendorf wrote: > Dominic Fandrey wrote: >> env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 >> -pipe -march=core2 -DHAVE_CONFIG_H >> -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c >> make-roken.c >> /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: >> error: bad value (core2) for -march= switch >> /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: >> error: bad value (core2) for -mtune= switch >> make-roken.c:1: error: bad value (core2) for -march= switch >> make-roken.c:1: error: bad value (core2) for -mtune= switch >> distcc[44991] ERROR: compile make-roken.c on localhost failed >> *** Error code 1 >> ... > > I saw this too when updating systems across the compiler update. As > near as I can tell, some part of the build is not using the new > "core2"-aware compiler built as part of the toolchain and is using the > older, installed version instead. > > Commenting out the CPUTYPE definition allowed my buildworlds to complete > successfully. ... Thanks for the workaround! It still worries me, that there's a bug in the bootstrapping. You never know what kind of trouble comes from that kind of thing. I hope this is going to be fixed. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: setting usb disc to da1
I've plugged a USB disc to a FreeBSD System and it's dedected as da1: da1: Fixed Direct Access SCSI-2 device But when rebooting the machine, it becomes da0 and I cannot boot the system. What's the trick to set the USB disc to da1 permanent? You can, to some degree, wire the device with.. hint.scbus.0.at="umass-sim0" hint.da0.at="scbus0" However I would recommend using GPT IDs, UFS IDs or GEOM labels in fstab so the underlying device name is irrelevant. Daniel, I'm not sure with /boot/devices.hint. Could you give me a hint, how to set # camcontrol devlist at scbus0 target 0 lun 0 (da0,pass0) at scbus1 target 0 lun 0 (pass1,da1) the Samsung G3 permanently to da1 (the AMCC must be da0). (This is a productive system and I don't want to do tests ...) Thank you! Regards, Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Heads up: you'll need to do a fresh "config KERNEL" etc
Hi, Just a heads up that after a commit going into stable/8 in a few minutes, you'll need to do a fresh kernel build, starting at "config GENERIC", including rebuilding the NFS related modules. rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Heads up: you'll need to do a fresh "config KERNEL" etc
On Sat, May 14, 2011 at 08:05:41PM -0400, Rick Macklem wrote: > Just a heads up that after a commit going into stable/8 in a few > minutes, you'll need to do a fresh kernel build, starting at > "config GENERIC", including rebuilding the NFS related modules. Rick, Can you explain why a kernel reconfig would be required if the kernel configuration (e.g. GENERIC) hasn't been changed? http://www.freshbsd.org/?branch=RELENG_8&project=freebsd Possibly the commit site doesn't have the most recent commits? I guess what I'm asking is: why is a kernel reconfig required if only the NFS code itself changed? A buildworld/buildkernel should be sufficient, no? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELENG_8 does not build with CPUTYPE=core2
in two step you can elliminate the warning message: 1) compile and install world and kernel with commented CPUTYPE in make.conf 2) uncomment the CPUTYPE line, and recompile world and kernel the problem is, the build system based on newer (4.2.2) gcc, and when you set CPUTYPE=core2 than substitute -march=core2 in gcc parameter list, but older base system cc (4.2.1) do not knows this option or value. On 5/14/11, Dominic Fandrey wrote: > On 14/05/2011 02:38, Scott Allendorf wrote: >> Dominic Fandrey wrote: >>> env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 >>> -pipe -march=core2 -DHAVE_CONFIG_H >>> -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c >>> make-roken.c >>> /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: >>> error: bad value (core2) for -march= switch >>> /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: >>> error: bad value (core2) for -mtune= switch >>> make-roken.c:1: error: bad value (core2) for -march= switch >>> make-roken.c:1: error: bad value (core2) for -mtune= switch >>> distcc[44991] ERROR: compile make-roken.c on localhost failed >>> *** Error code 1 >>> ... >> >> I saw this too when updating systems across the compiler update. As >> near as I can tell, some part of the build is not using the new >> "core2"-aware compiler built as part of the toolchain and is using the >> older, installed version instead. >> >> Commenting out the CPUTYPE definition allowed my buildworlds to complete >> successfully. ... > > Thanks for the workaround! > > It still worries me, that there's a bug in the bootstrapping. You > never know what kind of trouble comes from that kind of thing. > > I hope this is going to be fixed. > > Regards > > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: setting usb disc to da1
On 15/05/2011, at 24:36, Thomas Krause wrote: > I'm not sure with /boot/devices.hint. Could you give me a hint, how to > set > > # camcontrol devlist > at scbus0 target 0 lun 0 (da0,pass0) > at scbus1 target 0 lun 0 (pass1,da1) > > the Samsung G3 permanently to da1 (the AMCC must be da0). > (This is a productive system and I don't want to do tests ...) I think the following will work.. hint.scbus.0.at="twa0" hint.da.0.at="scbus1" hint.scbus.1.at="umass-sim0" hint.da.1.at="scbus0" Unfortunately I can't check the system I tested this on at the moment. I would strongly suggest you use glabel & UFS IDs (or GPT IDs if you used GPT when installing) in fstab rather than wiring device nodes. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELENG_8 does not build with CPUTYPE=core2
I had discovered this method of working around the fatal error, but the question remains: Should buildworld ever use the base compiler once the bootstrap compiler is built? Much of buildworld had already completed with "-march=core2" being fed to the bootstrap compiler by the time this error occurs. -Scott Oliver Pinter wrote: in two step you can elliminate the warning message: 1) compile and install world and kernel with commented CPUTYPE in make.conf 2) uncomment the CPUTYPE line, and recompile world and kernel the problem is, the build system based on newer (4.2.2) gcc, and when you set CPUTYPE=core2 than substitute -march=core2 in gcc parameter list, but older base system cc (4.2.1) do not knows this option or value. On 5/14/11, Dominic Fandrey wrote: On 14/05/2011 02:38, Scott Allendorf wrote: Dominic Fandrey wrote: env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c make-roken.c /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -march= switch /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -mtune= switch make-roken.c:1: error: bad value (core2) for -march= switch make-roken.c:1: error: bad value (core2) for -mtune= switch distcc[44991] ERROR: compile make-roken.c on localhost failed *** Error code 1 ... I saw this too when updating systems across the compiler update. As near as I can tell, some part of the build is not using the new "core2"-aware compiler built as part of the toolchain and is using the older, installed version instead. Commenting out the CPUTYPE definition allowed my buildworlds to complete successfully. ... Thanks for the workaround! It still worries me, that there's a bug in the bootstrapping. You never know what kind of trouble comes from that kind of thing. I hope this is going to be fixed. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Scott C. Allendorf Email: scott-allend...@uiowa.edu Senior Systems Administrator Office: 216A Van Allen Hall Department of Physics and AstronomyVoice: (319) 335-0003 The University of Iowa FAX: (319) 335-1753 Iowa City, Iowa 52242-1479ICBM: 41 39 43.6 N 91 31 55.1 W smime.p7s Description: S/MIME Cryptographic Signature
Re: setting usb disc to da1
Daniel O'Connor wrote: On 15/05/2011, at 24:36, Thomas Krause wrote: I'm not sure with /boot/devices.hint. Could you give me a hint, how to set # camcontrol devlist at scbus0 target 0 lun 0 (da0,pass0) at scbus1 target 0 lun 0 (pass1,da1) the Samsung G3 permanently to da1 (the AMCC must be da0). (This is a productive system and I don't want to do tests ...) I think the following will work.. hint.scbus.0.at="twa0" hint.da.0.at="scbus1" hint.scbus.1.at="umass-sim0" hint.da.1.at="scbus0" Unfortunately I can't check the system I tested this on at the moment. I would strongly suggest you use glabel& UFS IDs (or GPT IDs if you used GPT when installing) in fstab rather than wiring device nodes. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" I think I have an answer to your problem. "man glabel". Backup all data first! glabel label -v usr /dev/da1 newfs /dev/label/usr mount /dev/label/usr /usr [...] umount /usr glabel stop usr glabel unload I got that unload is unavailable but it everything worked for me. Check the man page. Hope this helps. Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
