Re: Zpool surgery
On Tue, 2013-01-29 at 15:52:50 +0100, Fabian Keil wrote: Dan Nelson dnel...@allantgroup.com wrote: In the last episode (Jan 28), Fabian Keil said: Ulrich Spörlein u...@freebsd.org wrote: On Mon, 2013-01-28 at 07:11:40 +1100, Peter Jeremy wrote: On 2013-Jan-27 14:31:56 -, Steven Hartland kill...@multiplay.co.uk wrote: - Original Message - From: Ulrich Spörlein u...@freebsd.org I want to transplant my old zpool tank from a 1TB drive to a new 2TB drive, but *not* use dd(1) or any other cloning mechanism, as the pool was very full very often and is surely severely fragmented. Cant you just drop the disk in the original machine, set it as a mirror then once the mirror process has completed break the mirror and remove the 1TB disk. That will replicate any fragmentation as well. zfs send | zfs recv is the only (current) way to defragment a ZFS pool. It's not obvious to me why zpool replace (or doing it manually) would replicate the fragmentation. zpool replace essentially adds your new disk as a mirror to the parent vdev, then deletes the original disk when the resilver is done. Since mirrors are block-identical copies of each other, the new disk will contain an exact copy of the original disk, followed by 1TB of freespace. Thanks for the explanation. I was under the impression that zfs mirrors worked at a higher level than traditional mirrors like gmirror but there seems to be indeed less magic than I expected. Fabian To wrap this up, while the zpool replace worked for the disk, I played around with it some more, and using snapshots instead *did* work the second time. I'm not sure what I did wrong the first time ... So basically this: # zfs send -R oldtank@2013-01-22 | zfs recv -F -d newtank (takes ages, then do a final snapshot before unmounting and send the incremental) # zfs send -R -i 2013-01-22 oldtank@2013-01-29 | zfs recv -F -d newtank Allows me to send snapshots up to 2013-01-29 to the archive pool from either oldtank or newtank. Yay! Cheers, Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
stable/8 to HEAD
Hi, Possible stupid question, but.. Can I update my stable/8 r228757 to HEAD? sandbox# svnversion 246112 sandbox# cat /etc/src.conf WITHOUT_PROFILE=YES WITHOUT_GAMES=YES WITHOUT_BLUETOOTH=YES WITHOUT_FREEBSD_UPDATE=YES WITHOUT_LPR=YES WITHOUT_NDIS=YES WITHOUT_WPA_SUPPLICANT_EAPOL=YES WITHOUT_WIRELESS_SUPPORT=YES WITHOUT_WIRELESS=YES sandbox# cat /etc/make.conf # added by use.perl 2011-01-12 09:43:24 PERL_VERSION=5.10.1 sandbox# make buildworld [skipped] === usr.bin/lex/lib (all) cc -O2 -pipe -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bin/lex/lib/libmain.c -o libmain.o cc -O2 -pipe -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bin/lex/lib/libyywrap.c -o libyywrap.o building static ln library ranlib libln.a sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 lex /usr/obj/usr/src/tmp/legacy/usr/bin sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/usr.bin/lex/FlexLexer.h /usr/obj/usr/src/tmp/legacy/usr/include === usr.bin/lex/lib (install) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libln.a /usr/obj/usr/src/tmp/legacy/usr/lib /usr/obj/usr/src/tmp/legacy/usr/lib/libl.a - /usr/obj/usr/src/tmp/legacy/usr/lib/libln.a /usr/obj/usr/src/tmp/legacy/usr/lib/libfl.a - /usr/obj/usr/src/tmp/legacy/usr/lib/libln.a /usr/obj/usr/src/tmp/legacy/usr/bin/lex++ - /usr/obj/usr/src/tmp/legacy/usr/bin/lex /usr/obj/usr/src/tmp/legacy/usr/bin/flex - /usr/obj/usr/src/tmp/legacy/usr/bin/lex /usr/obj/usr/src/tmp/legacy/usr/bin/flex++ - /usr/obj/usr/src/tmp/legacy/usr/bin/lex === usr.bin/xinstall (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/xinstall created for /usr/src/usr.bin/xinstall rm -f .depend mkdep -f .depend -a-I/usr/src/usr.bin/xinstall/../../contrib/mtree -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd -I/usr/obj/usr/src/tmp/legacy/usr/include -std=gnu99 /usr/src/usr.bin/xinstall/xinstall.c /usr/src/usr.bin/xinstall/../../contrib/mtree/getid.c /usr/src/usr.bin/xinstall/xinstall.c:64:20: error: sha512.h: No such file or directory mkdep: compile failed *** [.depend] Error code 1 Stop in /usr/src/usr.bin/xinstall. *** [bootstrap-tools] Error code 1 Stop in /usr/src. *** [_bootstrap-tools] Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- wbr, tiger ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mounting root from NFS via ROOTDEVNAME
Hi, On Jan 30, 2013, at 10:32, Eggert, Lars l...@netapp.com wrote: On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org wrote: In src/sys/boot/common/boot.c which is part of the loader (not the kernel), if you look in the getrootmount() function, you will see that the loader will try to figure out where the root file system is by parsing /etc/fstab, and looking for the / mount. So, if your kernel is located in: /usr/home/elars/dst/boot/kernel/kernel Then create a file /usr/home/elars/dst/etc/fstab file with something like: # Device MountpointFSType Options Dump Pass 10.11.12.13:/usr/home/elars/dst/ / nfs ro00 Thanks, will try that! doesn't work. The kernel never leaves the DHCP/BOOTP timeout for server-loop unless I hand out a root-path option via DHCP. I tried your tip above, I tried setting ROOTDEVNAME in the kernel, I created a /boot.config with -r in it on the NFS root - all to no avail. Alternatively, if you don't want to create an /etc/fstab file, then you could put something like this in your loader.conf file: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Will try that too, but not sure if this works with our custom loader. Doesn't seem to work either. Lars ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: stable/8 to HEAD
On Wed, Jan 30, 2013 at 01:11:30PM +0300, Sergey V. Dyatko wrote: Hi, Possible stupid question, but.. Can I update my stable/8 r228757 to HEAD? You need at least r231588. Generally, only updates from the latest last stable branches are supported, i.e. latest stable/9. From the hand-on experience, it does work to update from even a year-old stable/8, assuming you do make all install in the _latest_ checkout of stable/8/lib/libmd and add auditdistd user. sandbox# svnversion 246112 sandbox# cat /etc/src.conf WITHOUT_PROFILE=YES WITHOUT_GAMES=YES WITHOUT_BLUETOOTH=YES WITHOUT_FREEBSD_UPDATE=YES WITHOUT_LPR=YES WITHOUT_NDIS=YES WITHOUT_WPA_SUPPLICANT_EAPOL=YES WITHOUT_WIRELESS_SUPPORT=YES WITHOUT_WIRELESS=YES sandbox# cat /etc/make.conf # added by use.perl 2011-01-12 09:43:24 PERL_VERSION=5.10.1 sandbox# make buildworld [skipped] === usr.bin/lex/lib (all) cc -O2 -pipe -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bin/lex/lib/libmain.c -o libmain.o cc -O2 -pipe -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bin/lex/lib/libyywrap.c -o libyywrap.o building static ln library ranlib libln.a sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 lex /usr/obj/usr/src/tmp/legacy/usr/bin sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/usr.bin/lex/FlexLexer.h /usr/obj/usr/src/tmp/legacy/usr/include === usr.bin/lex/lib (install) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libln.a /usr/obj/usr/src/tmp/legacy/usr/lib /usr/obj/usr/src/tmp/legacy/usr/lib/libl.a - /usr/obj/usr/src/tmp/legacy/usr/lib/libln.a /usr/obj/usr/src/tmp/legacy/usr/lib/libfl.a - /usr/obj/usr/src/tmp/legacy/usr/lib/libln.a /usr/obj/usr/src/tmp/legacy/usr/bin/lex++ - /usr/obj/usr/src/tmp/legacy/usr/bin/lex /usr/obj/usr/src/tmp/legacy/usr/bin/flex - /usr/obj/usr/src/tmp/legacy/usr/bin/lex /usr/obj/usr/src/tmp/legacy/usr/bin/flex++ - /usr/obj/usr/src/tmp/legacy/usr/bin/lex === usr.bin/xinstall (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/xinstall created for /usr/src/usr.bin/xinstall rm -f .depend mkdep -f .depend -a-I/usr/src/usr.bin/xinstall/../../contrib/mtree -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd -I/usr/obj/usr/src/tmp/legacy/usr/include -std=gnu99 /usr/src/usr.bin/xinstall/xinstall.c /usr/src/usr.bin/xinstall/../../contrib/mtree/getid.c /usr/src/usr.bin/xinstall/xinstall.c:64:20: error: sha512.h: No such file or directory mkdep: compile failed *** [.depend] Error code 1 Stop in /usr/src/usr.bin/xinstall. *** [bootstrap-tools] Error code 1 Stop in /usr/src. *** [_bootstrap-tools] Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- wbr, tiger ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org pgpal7Xu8E3tT.pgp Description: PGP signature
buildworld errors
I updated /usr/src and buildworld just now. The building process stopped at here. It's FreeBSD 10.0 === lib/clang/libllvmlinker (all) === lib/clang/libllvmmc (all) === lib/clang/libllvmmcparser (all) === lib/clang/libllvmobject (all) === lib/clang/libllvmscalaropts (all) === lib/clang/libllvmselectiondag (all) === lib/clang/libllvmsupport (all) === lib/clang/libllvmtablegen (all) === lib/clang/libllvmtarget (all) === lib/clang/libllvmtransformutils (all) === lib/clang/libllvmvectorize (all) === lib/clang/libllvmarmasmparser (all) === lib/clang/libllvmarmcodegen (all) === lib/clang/libllvmarmdesc (all) === lib/clang/libllvmarmdisassembler (all) === lib/clang/libllvmarminfo (all) === lib/clang/libllvmarminstprinter (all) === lib/clang/libllvmmipsasmparser (all) === lib/clang/libllvmmipscodegen (all) === lib/clang/libllvmmipsdesc (all) === lib/clang/libllvmmipsdisassembler (all) === lib/clang/libllvmmipsinfo (all) === lib/clang/libllvmmipsinstprinter (all) === lib/clang/libllvmpowerpccodegen (all) === lib/clang/libllvmpowerpcdesc (all) === lib/clang/libllvmpowerpcinfo (all) === lib/clang/libllvmpowerpcinstprinter (all) === lib/clang/libllvmx86asmparser (all) === lib/clang/libllvmx86codegen (all) === lib/clang/libllvmx86desc (all) === lib/clang/libllvmx86disassembler (all) === lib/clang/libllvmx86info (all) === lib/clang/libllvmx86instprinter (all) === lib/clang/libllvmx86utils (all) === lib/clang/libllvmdebuginfo (all) === lib/clang/libllvmexecutionengine (all) === lib/clang/libllvminterpreter (all) === lib/clang/libllvmjit (all) === lib/clang/libllvmmcdisassembler (all) === lib/clang/libllvmmcjit (all) === lib/clang/libllvmruntimedyld (all) === lib/clang/include (all) 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: buildworld error
On 2013-01-30 10:37, Jesse wrote: I just update /usr/src and make buildworld. The building proccess stop as errors: === lib/clang/libllvmx86asmparser (all) === lib/clang/libllvmx86codegen (all) === lib/clang/libllvmx86desc (all) === lib/clang/libllvmx86disassembler (all) === lib/clang/libllvmx86info (all) === lib/clang/libllvmx86instprinter (all) === lib/clang/libllvmx86utils (all) === lib/clang/libllvmdebuginfo (all) === lib/clang/libllvmexecutionengine (all) === lib/clang/libllvminterpreter (all) === lib/clang/libllvmjit (all) === lib/clang/libllvmmcdisassembler (all) === lib/clang/libllvmmcjit (all) === lib/clang/libllvmruntimedyld (all) === lib/clang/include (all) 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error Because you are making buildworld with -j, the actual error message is not visible. Try searching back in the log to find the actual error, and post that. Alternatively, make buildworld without -j. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mounting root from NFS via ROOTDEVNAME
On Wed, 2013-01-30 at 09:32 +, Eggert, Lars wrote: Hi, On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org wrote: What kind of architecture are you trying to do this on? Is this i386/amd64 or something else? amd64 I am not familiar with netboot compared to PXE. Is TFTP involved at all with netboot? TFTP is not involved. The kernel gets booted by our custom loader (over HTTP) and the root FS is supposed to be mounted over NFS. What does your dhcpd configuration file look like? Completely standard, with the addition of a root-path option. (Which I would like to get rid of by setting ROOTDEVNAME in the kernel.) Also, are you using the FreeBSD loader, or something else? What kinds of customizations have you done on the loader? Custom loader. If through your setup you have already managed to load the kernel over the network, then a lot of the hard work has been done. Telling the kernel where the root file system is located becomes the next tricky part. Right, that's the step I am struggeling with. In src/sys/boot/common/boot.c which is part of the loader (not the kernel), if you look in the getrootmount() function, you will see that the loader will try to figure out where the root file system is by parsing /etc/fstab, and looking for the / mount. So, if your kernel is located in: /usr/home/elars/dst/boot/kernel/kernel Then create a file /usr/home/elars/dst/etc/fstab file with something like: # Device MountpointFSType Options Dump Pass 10.11.12.13:/usr/home/elars/dst/ / nfs ro00 Thanks, will try that! Alternatively, if you don't want to create an /etc/fstab file, then you could put something like this in your loader.conf file: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Will try that too, but not sure if this works with our custom loader. Lars If you can get this to work without introducing new kernel options, that would be ideal, because the kernel options you are enabling are triggering behaviors. Just FYI, I believe the current behavior of BOOTP and BOOTP_NFSROOT is a bug, and I've entered a PR for it http://www.freebsd.org/cgi/query-pr.cgi?pr=175671 I also put a little effort into changing the behavior so that BOOTP without BOOTP_NFSROOT gets you an address and then moves on to use the ROOTDEVNAME you have configured, but I didn't have any success yet (it stays stuck in the state of waiting for the root path). I intend to get back to it after wrapping up some other work, if someone else doesn't get to it first. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
x11/nvidia-driver build fails in head @r246115
I include PORTS_MODULES=x11/nvidia-driver in /etc/src.conf in order to keep nvidia-driver in sync with my kernel. It last built OK yesterday, @r246057; @r246115, I see: === nvidia-driver-304.64 depends on file: /usr/local/libdata/pkgconfig/xorg-server.pc - found === nvidia-driver-304.64 depends on shared library: GL.1 - found === Configuring for nvidia-driver-304.64 === Building for nvidia-driver-304.64 === src (all) @ - /usr/src/sys machine - /usr/src/sys/i386/include x86 - /usr/src/sys/x86/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\304.64\ -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG -DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_ctl.c clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\304.64\ -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG -DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_dev.c clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\304.64\ -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG -DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_i2c.c clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\304.64\ -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG -DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_linux.c nvidia_linux.c:51:28: error: variable has incomplete type 'struct linux_ioctl_handler' struct linux_ioctl_handler nvidia_handler = { ^ nvidia_linux.c:51:8: note: forward declaration of 'struct linux_ioctl_handler' struct linux_ioctl_handler nvidia_handler = { ^ nvidia_linux.c:62:5: error: implicit declaration of function 'linux_ioctl_register_handler' is invalid in C99 [-Werror,-Wimplicit-function-declaration] linux_ioctl_register_handler(nvidia_handler); ^ nvidia_linux.c:69:5: error: implicit declaration of function 'linux_ioctl_unregister_handler' is invalid in C99 [-Werror,-Wimplicit-function-declaration] linux_ioctl_unregister_handler(nvidia_handler); ^ nvidia_linux.c:69:5: note: did you mean 'linux_ioctl_register_handler'? linux_ioctl_unregister_handler(nvidia_handler); ^~ linux_ioctl_register_handler nvidia_linux.c:62:5: note: 'linux_ioctl_register_handler' declared here linux_ioctl_register_handler(nvidia_handler); ^ 3 errors generated. *** [nvidia_linux.o] Error code 1 Stop in /common/S4/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-304.64/src. *** [all] Error code 1 Stop in /common/S4/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-304.64. *** [do-build] Error
Re: mounting root from NFS via ROOTDEVNAME
Lars Eggert wrote: Hi, On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org wrote: What kind of architecture are you trying to do this on? Is this i386/amd64 or something else? amd64 I am not familiar with netboot compared to PXE. Is TFTP involved at all with netboot? TFTP is not involved. The kernel gets booted by our custom loader (over HTTP) and the root FS is supposed to be mounted over NFS. What does your dhcpd configuration file look like? Completely standard, with the addition of a root-path option. (Which I would like to get rid of by setting ROOTDEVNAME in the kernel.) Also, are you using the FreeBSD loader, or something else? What kinds of customizations have you done on the loader? Custom loader. If through your setup you have already managed to load the kernel over the network, then a lot of the hard work has been done. Telling the kernel where the root file system is located becomes the next tricky part. Right, that's the step I am struggeling with. If you have options BOOTP and options BOOTP_NFSROOT, the VFS_MOUNT()/nfs_mount() call early in vfs_mountroot() calls bootpc_init(). This function and related code is in sys/nfs/bootp_subr.c. At a glance, the code in sys/nfs/bootp_subr.c tries very hard to get root-path in several places, so it will take some fiddling to get it to work without the dhcpd returning a root-path option. (I think Ian Lepore has started to work on this.) I don't have any way of testing this until at least April, so I can't really help. It should be possible to modify bootp_subr.c, so that it uses ROOTDEVNAME instead of trying to get root-path from the dhcp server when it is specified, but the change will take some work. If you want bootpc_init() to be called when options BOOTP_NFSROOT isn't specified, that is a one line change in sys/fs/nfsclient/nfs_clvfsops.c. (Just look for the bootpc_init() call, but I don't see that as being useful? I think changing bootpc_init() and friends to avoid getting root-path when it has already been specified (by ROOTDEVNAME and/or vfs.root.mountfrom) is the best approach, but will require a significant patch to bootp_subr.c. I can see two other approaches to doing this: 1 - Supply a root-path via the dhcpd, but override what it says later in the kernel boot, to use what is specified by ROOTDEVNAME or vfs.root.mountfrom. I haven't looked at what this would take, but I didn't see how it could be done with the current code, because the NFS client code expects a structure called nfsv3_diskless to be filled in by bootpc_init() OR 2 - nfs_diskless(). The call to nfs_diskless() is done when options NFS_ROOT is specified, but options BOOTP + options BOOTP_NFSROOT is not. (Just look at the calls in sys/fs/nfs/nfs_clvfsops.c or sys/nfsclient/nfs_vfsops.c.) It fills the structure in from a bunch of environment variables. These are normally filled in by pxeboot, but you could modify your custom loader to fill them in, which would be this approach. Once eithe nfs_diskless() or bootpc_init() has filled in nfsv3_diskless and set nfs_diskless_valid, then the rest of the code uses what is in that structure, so one of these 2 functions needs to be called, unless you do a major re-write of the diskless NFS booting stuff. Good luck with it, rick In src/sys/boot/common/boot.c which is part of the loader (not the kernel), if you look in the getrootmount() function, you will see that the loader will try to figure out where the root file system is by parsing /etc/fstab, and looking for the / mount. So, if your kernel is located in: /usr/home/elars/dst/boot/kernel/kernel Then create a file /usr/home/elars/dst/etc/fstab file with something like: # Device Mountpoint FSType Options Dump Pass 10.11.12.13:/usr/home/elars/dst/ / nfs ro 0 0 Thanks, will try that! Alternatively, if you don't want to create an /etc/fstab file, then you could put something like this in your loader.conf file: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Will try that too, but not sure if this works with our custom loader. Lars If you can get this to work without introducing new kernel options, that would be ideal, because the kernel options you are enabling are triggering behaviors. -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: x11/nvidia-driver build fails in head @r246115
On Wednesday, January 30, 2013 9:51:35 am David Wolfskill wrote: I include PORTS_MODULES=x11/nvidia-driver in /etc/src.conf in order to keep nvidia-driver in sync with my kernel. It last built OK yesterday, @r246057; @r246115, I see: Oof, it needs to use compat/linux/linux_ioctl.h instead of one of the foo/linux.h headers on HEAD. (and this is my fault) Alexey, can you patch the port for that? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[no subject]
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #33 r246130: Wed Jan 30 15:00:08 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 I just rebuilt the world and kernel. Then I rebuilt /usr/ports/emulators/virtualbox-ose-kmod. # kldstat Id Refs AddressSize Name 1 24 0x8020 116fac0 kernel 21 0x8137 ee74c8 nvidia.ko 33 0x82258000 1393f8 linux.ko 41 0x82412000 997d linprocfs.ko 51 0x8241c000 344b ums.ko 61 0x8242 29c3 uhid.ko 71 0x82423000 2e7b0vboxdrv.ko # pkg info |grep box virtualbox-ose-4.2.6 A general-purpose full virtualizer for x86 hardware virtualbox-ose-kmod-4.2.6_1VirtualBox kernel module for FreeBSD Virtualbox suddenly broke for me, possibly related to this: http://svnweb.FreeBSD.org/base?view=revisionrevision=246028 Fix some symbol version mismatches between libstdc++ and libsupc++/libcxxrt that were causing the runtime and STL libraries to see different versions of various classes and functions when libstdc++ is used as a filter. When I try to start Vbox it fails with: # VirtualBox VirtualBox: Error -610 in supR3HardenedMainInitRuntime! VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found With all due respect to developers, are these changes tested at all before they are added to the codebase? I understand this is a development branch. I am not a developer, but it seems to me more thought and testing should be done before changes like this are committed. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mounting root from NFS via ROOTDEVNAME
On Wed, Jan 30, 2013 at 1:32 AM, Eggert, Lars l...@netapp.com wrote: Hi, On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org wrote: TFTP is not involved. The kernel gets booted by our custom loader (over HTTP) and the root FS is supposed to be mounted over NFS. If through your setup you have already managed to load the kernel over the network, then a lot of the hard work has been done. Telling the kernel where the root file system is located becomes the next tricky part. Right, that's the step I am struggeling with. In src/sys/boot/common/boot.c which is part of the loader (not the kernel), if you look in the getrootmount() function, you will see that the loader will try to figure out where the root file system is by parsing /etc/fstab, and looking for the / mount. So, if your kernel is located in: /usr/home/elars/dst/boot/kernel/kernel Then create a file /usr/home/elars/dst/etc/fstab file with something like: # Device MountpointFSType Options Dump Pass 10.11.12.13:/usr/home/elars/dst/ / nfs ro0 0 Thanks, will try that! Alternatively, if you don't want to create an /etc/fstab file, then you could put something like this in your loader.conf file: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Will try that too, but not sure if this works with our custom loader. Hi, Thanks for the clarification. I have a better idea of what you are trying to do. As you can imagine, not too many people have been playing with this type of stuff. A lot of this root mounting/NFS code was written about 14-15 years ago, and not a lot of folks have been using it, but it is highly useful once you get it to work. Rick Macklem has been dusting off a lot of the cobwebs in the NFS code thankfully. Since your custom loader can load the kernel without using TFTP, I think that this is a very good point. Does your custom loader use any of the FreeBSD bootstrap or loader code? What you need to do is, before the FreeBSD kernel boots, your loader needs to export some environment variables. This will trigger the various behaviors in the FreeBSD mount code. So as I suggested before, you should continue with: (1) Have /usr/home/elars/dst/etc/fstab with: # Options Dump Pass 10.11.12.13:/usr/home/elars/dst/ / nfs ro00 (2) From your loader, you need to export this environment variable, so that the kernel can get it with getenv(). You need at least: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Now, there are some other environment variables you need to export from the loader. If you look in src/sys/boot/i386/libi386/pxe.c, you will see that several environment variables are set by the FreeBSD loader (which is /boot/pxeboot on a FreeBSD system): boot.netif.ip boot.netif.netmask boot.netif.gateway boot.nfsroot.server boot.nfsroot.path dchp.host-name These variables are then read by the FreeBSD kernel's NFS client root mount code in src/sys/nfsclient/nfs_diskless.c. If you can get those variables set properly in your loader, so that the FreeBSD kernel can read them, then I think this might work. :) Basically, you need to give the kernel enough basic info about the IP address, gateway, and netmask so it can NFS mount the root file system. Also, unless you really need them, I would recommend removing the BOOTP options from your kernel config (unless you really feel you need them). As others have pointed out, some of these options have not been tested for a long time and might be buggy. That is always the risk when kernel options are not part of the GENERIC config. Good luck! -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re[2]: Re[2]: AHCI timeout when using ZFS + AIO + NCQ
I once ran into a very severe AHCI timeout problem. After months of trying to figure it out and insane Hardware_ECC_Recovered error values, I found that the error was with the power connector plug / sata HDD interface. All errors disappeared after replacing that cable. Since you have error on more than 1 HDD, I suggest: 1. Check smartctl output for each AND all HDD 2. Check whether your power supply unit is still healthy or if it is supplying inconsistent power. 3. Check the main power supply line and whether it shows any voltage fluctuations or if there is a new heavy consumer of amps on the same power line as the server is plugged to. I've deliberately chose a different server that has a different chipset, and that there were no problems with the HDD. Added kernel support: device ahci # AHCI-compatible SATA controllers And now, after 2.5 days fell off one HDD. [3:14]beastie:root-/root# zpool status pool: tank state: DEGRADED status: One or more devices has been removed by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scan: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0ONLINE 0 0 0 gpt/disk2ONLINE 0 0 0 mirror-1 DEGRADED 0 0 0 gpt/disk1ONLINE 0 0 0 4931885954389536913 REMOVED 0 0 0 was /dev/gpt/disk3 errors: No known data errors Jan 30 09:49:28 beastie kernel: ahcich3: Timeout on slot 29 port 0 Jan 30 09:49:28 beastie kernel: ahcich3: is cs 2000 ss rs 2000 tfd c0 serr cmd 0004dd17 Jan 30 09:49:28 beastie kernel: (ada3:ahcich3:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 Jan 30 09:49:28 beastie kernel: (ada3:ahcich3:0:0:0): CAM status: Command timeout Jan 30 09:49:28 beastie kernel: (ada3:ahcich3:0:0:0): Retrying command Jan 30 09:51:31 beastie kernel: ahcich3: AHCI reset: device not ready after 31000ms (tfd = 0080) Jan 30 09:51:31 beastie kernel: ahcich3: Timeout on slot 29 port 0 Jan 30 09:51:31 beastie kernel: ahcich3: is cs 2000 ss rs 2000 tfd 80 serr cmd 0004dd17 Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): CAM status: Command timeout Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): Error 5, Retry was blocked Jan 30 09:51:31 beastie kernel: ahcich3: AHCI reset: device not ready after 31000ms (tfd = 0080) Jan 30 09:51:31 beastie kernel: ahcich3: Timeout on slot 29 port 0 Jan 30 09:51:31 beastie kernel: ahcich3: is cs ss rs 2000 tfd 58 serr cmd 0004dd17 Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): CAM status: Command timeout Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): Error 5, Retry was blocked Jan 30 09:51:31 beastie kernel: (ada3:ahcich3:0:0:0): lost device Jan 30 09:51:31 beastie kernel: (pass3:ahcich3:0:0:0): passdevgonecb: devfs entry is gone -- Vladislav V. Prodan System Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r246057: buildworld fails with: /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'
O. Hartmann ohart...@zedat.fu-berlin.de writes: c++ -O3 -pipe -fno-strict-aliasing -march=native -march=native -DHAVE_CONFIG_H -I/usr/src/libexec/atf/atf-check/../../../contrib/atf -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -stdlib=libc++ -std=c++11 -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++ -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c -o atf-check atf-check.o -latf-c++ -latf-c /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()' /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so: undefined reference to `std::bad_alloc::bad_alloc()' /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so: undefined reference to `std::bad_alloc::~bad_alloc()' /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()' c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [atf-check] Error code 1 Try stage binaries built with default CXXFLAGS from allbsd.org snapshot. With them installed do you see smth like the following? $ clang++ -stdlib=libc++ foo.c clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated /usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()' /usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()' /usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()' /usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()' clang++: error: linker command failed with exit code 1 (use -v to see invocation) It's different from the error when you build libc++ before libcxxrt. $ clang++ -stdlib=libc++ foo.c clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated /usr/lib/libc++.so: undefined reference to `std::uncaught_exception()@CXXABI_1.3' /usr/lib/libc++.so: undefined reference to `std::exception::~exception()@CXXRT_1.0' /usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()@CXXRT_1.0' /usr/lib/libc++.so: undefined reference to `typeinfo for std::exception@CXXRT_1.0' /usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()@CXXRT_1.0' /usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()@CXXRT_1.0' /usr/lib/libc++.so: undefined reference to `typeinfo for std::bad_cast@CXXRT_1.0' /usr/lib/libc++.so: undefined reference to `std::bad_cast::~bad_cast()@CXXRT_1.0' /usr/lib/libc++.so: undefined reference to `typeinfo for std::bad_alloc@CXXRT_1.0' /usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()@CXXRT_1.0' /usr/lib/libc++.so: undefined reference to `std::terminate()@CXXABI_1.3' clang++: error: linker command failed with exit code 1 (use -v to see invocation) -- #! /bin/sh # fetch/install stage binaries from allbsd.org snapshots TARGET=amd64 TARGET_ARCH=amd64 BRANCH=10.0-HEAD #REVISION=r245980 # works fine REVISION=r246034 # doesn't work LIBS=lib/libcxxrt/libcxxrt.so.1:/lib \ lib/libc++/libc++.so.1:/usr/lib \ gnu/lib/libsupc++/libsupc++.so.1:/usr/lib for f in $LIBS; do #chflags 0 $dir/${file##*/} fetch -o ${f#*:} https://pub.allbsd.org/FreeBSD-snapshots/${TARGET}-${TARGET_ARCH}/${BRANCH}-${REVISION}-JPSNAP/stage/usr/obj/usr/src/${f%:*} done ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mounting root from NFS via ROOTDEVNAME
On 1/30/13 1:32 AM, Eggert, Lars wrote: Hi, On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org wrote: Alternatively, if you don't want to create an /etc/fstab file, then you could put something like this in your loader.conf file: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Will try that too, but not sure if this works with our custom loader. your custom loader should have some way to set kernel environment values. it's a pretty basic requirement and, surprisingly, not that hard to do. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: buildworld error
i set these in make.conf: CXXFLAGS+=-stdlib=libc++ CXXFLAGS+=-std=c++11 i comment them and rebuild world ok but it works at previous revision. On 1/30/13, Dimitry Andric d...@freebsd.org wrote: On 2013-01-30 10:37, Jesse wrote: I just update /usr/src and make buildworld. The building proccess stop as errors: === lib/clang/libllvmx86asmparser (all) === lib/clang/libllvmx86codegen (all) === lib/clang/libllvmx86desc (all) === lib/clang/libllvmx86disassembler (all) === lib/clang/libllvmx86info (all) === lib/clang/libllvmx86instprinter (all) === lib/clang/libllvmx86utils (all) === lib/clang/libllvmdebuginfo (all) === lib/clang/libllvmexecutionengine (all) === lib/clang/libllvminterpreter (all) === lib/clang/libllvmjit (all) === lib/clang/libllvmmcdisassembler (all) === lib/clang/libllvmmcjit (all) === lib/clang/libllvmruntimedyld (all) === lib/clang/include (all) 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error Because you are making buildworld with -j, the actual error message is not visible. Try searching back in the log to find the actual error, and post that. Alternatively, make buildworld without -j. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: buildworld error
z On 1/31/13, Jesse je...@glx.me wrote: i set these in make.conf: CXXFLAGS+=-stdlib=libc++ CXXFLAGS+=-std=c++11 i comment them and rebuild world ok but it works at previous revision. On 1/30/13, Dimitry Andric d...@freebsd.org wrote: On 2013-01-30 10:37, Jesse wrote: I just update /usr/src and make buildworld. The building proccess stop as errors: === lib/clang/libllvmx86asmparser (all) === lib/clang/libllvmx86codegen (all) === lib/clang/libllvmx86desc (all) === lib/clang/libllvmx86disassembler (all) === lib/clang/libllvmx86info (all) === lib/clang/libllvmx86instprinter (all) === lib/clang/libllvmx86utils (all) === lib/clang/libllvmdebuginfo (all) === lib/clang/libllvmexecutionengine (all) === lib/clang/libllvminterpreter (all) === lib/clang/libllvmjit (all) === lib/clang/libllvmmcdisassembler (all) === lib/clang/libllvmmcjit (all) === lib/clang/libllvmruntimedyld (all) === lib/clang/include (all) 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error Because you are making buildworld with -j, the actual error message is not visible. Try searching back in the log to find the actual error, and post that. Alternatively, make buildworld without -j. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r246057: buildworld fails with: /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'
Am 01/29/13 17:35, schrieb David Wolfskill: On Tue, Jan 29, 2013 at 11:06:02AM +0100, O. Hartmann wrote: I receive this error since yesterday building world and it is still sticky on most recent sources (r246057) and I was wondering why the tinderboxes do not pick this up on the 10.0-CURRENT builds ... just for a notice for the development folks ... ... === libexec/atf/atf-check (all) ... c++ -O3 -pipe -fno-strict-aliasing -march=native -march=native -DHAVE_CONFIG_H -I/usr/src/libexec/atf/atf-check/../../../contrib/atf -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -stdlib=libc++ -std=c++11 -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++ -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c -o atf-check atf-check.o -latf-c++ -latf-c /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()' /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so: undefined reference to `std::bad_alloc::bad_alloc()' /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so: undefined reference to `std::bad_alloc::~bad_alloc()' /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()' c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [atf-check] Error code 1 Stop in /usr/src/libexec/atf/atf-check. *** [all] Error code 1 ... In contrast, I don't see a problem; most recent head build I have is: FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1057 r246057M/246068: Tue Jan 29 07:29:55 PST 2013 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 For reference, yesterday's was: FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1056 r246028M/246028: Mon Jan 28 06:49:44 PST 2013 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 That said (and this may be relevant), I'm using clang/clang++ to build FreeBSD. Peace, david First, I suspected the c++ option -std=c++11 I issued in /etc/src.conf when building the sources - I did this before without any problems. Then, leaving the build without -std=c++11 option, I get the following error below and compilation stops. Maybe this reveals the real issue. The revision of the OS I compile on and where it fails is FreeBSD 10.0-CURRENT #2 r245995: Sun Jan 27 19:56:47 CET 2013. This is maybe of any help. The sources are at Revision: 246142 Oliver [...] /usr/obj/usr/src/tmp/usr/include/c++/v1/memory:3771:14: error: default template arguments for a function template are a C++11 extension [-Werror,-Wc++11-extensions] class = typename enable_if ^ ~~ fatal error: too many errors emitted, stopping now [-ferror-limit=] In file included from /usr/src/lib/atf/libatf-c++/../../../contrib/atf/atf-c++/detail/application.cpp:42: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/iostream:38: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/string:434: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/algorithm:594: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/memory:597: /usr/obj/usr/src/tmp/usr/include/c++/v1/__functional_base:22:1: error: inline namespaces are a C++11 feature [-Werror,-Wc++11-extensions] _LIBCPP_BEGIN_NAMESPACE_STD ^ /usr/obj/usr/src/tmp/usr/include/c++/v1/__config:275:52: note: expanded from macro '_LIBCPP_BEGIN_NAMESPACE_STD' #define _LIBCPP_BEGIN_NAMESPACE_STD namespace std {inline namespace _LIBCPP_NAMESPACE { ^ /usr/obj/usr/src/tmp/usr/include/c++/v1/__config:275:52: note: expanded from macro '_LIBCPP_BEGIN_NAMESPACE_STD' #define _LIBCPP_BEGIN_NAMESPACE_STD namespace std {inline namespace _LIBCPP_NAMESPACE { ^ In file included from /usr/src/lib/atf/libatf-c++/../../../contrib/atf/atf-c++/detail/application.cpp:42: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/iostream:38: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/string:434: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/algorithm:594: /usr/obj/usr/src/tmp/usr/include/c++/v1/memory:614:1: error: inline namespaces are a C++11 feature [-Werror,-Wc++11-extensions] _LIBCPP_BEGIN_NAMESPACE_STD ^
Re: buildworld error
Am 01/31/13 05:06, schrieb Jesse: z On 1/31/13, Jesse je...@glx.me wrote: i set these in make.conf: CXXFLAGS+=-stdlib=libc++ CXXFLAGS+=-std=c++11 i comment them and rebuild world ok but it works at previous revision. On 1/30/13, Dimitry Andric d...@freebsd.org wrote: On 2013-01-30 10:37, Jesse wrote: I just update /usr/src and make buildworld. The building proccess stop as errors: === lib/clang/libllvmx86asmparser (all) === lib/clang/libllvmx86codegen (all) === lib/clang/libllvmx86desc (all) === lib/clang/libllvmx86disassembler (all) === lib/clang/libllvmx86info (all) === lib/clang/libllvmx86instprinter (all) === lib/clang/libllvmx86utils (all) === lib/clang/libllvmdebuginfo (all) === lib/clang/libllvmexecutionengine (all) === lib/clang/libllvminterpreter (all) === lib/clang/libllvmjit (all) === lib/clang/libllvmmcdisassembler (all) === lib/clang/libllvmmcjit (all) === lib/clang/libllvmruntimedyld (all) === lib/clang/include (all) 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error Because you are making buildworld with -j, the actual error message is not visible. Try searching back in the log to find the actual error, and post that. Alternatively, make buildworld without -j. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I see the very same issue and reported this already. Since I'm not a professional developer, I'm not quite sure what and how to report the issue in exactly and accurate. In my case, this issue came out of the blue. I also have set CXXFLAGS+= -stdlib=libc++ -std=c++11 but in /etc/src.conf. Commenting out -std=c++11 makes the build of world fail with something like [...] fatal error: too many errors emitted, stopping now [-ferror-limit=] In file included from /usr/src/lib/atf/libatf-c++/../../../contrib/atf/atf-c++/detail/application.cpp:42: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/iostream:38: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/string:434: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/algorithm:594: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/memory:597: /usr/obj/usr/src/tmp/usr/include/c++/v1/__functional_base:22:1: error: inline namespaces are a C++11 feature [-Werror,-Wc++11-extensions] [...] which sounds strange to me, since I completely erase /usr/obj before building and I do not use a ccache or any other similar facility. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: x220 notes
Excerpt from Andrey Fesenko f0and...@gmail.com: And other problems. 1) wi-fi standart rtl8192cu - not work change AR5B95 - work n-mode (thanks Adrian Chadd :) need hack BIOS dev.acpi_ibm.0.wlan: 1 - read only hardware switch work, not send mesage What did you try to make rtl8192cu work? Did you try NDIS? I have Hiro USB wireless adapter with rtl8191s chip, am still trying, on and off, to get it to work. OpenBSD has urtwn driver that should work, ported to NetBSD, but why not FreeBSD? ALso, there is a Linux driver. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org