Re: FreeBSD Quarterly Status Report - Second Quarter 2014
On Jul 26, 2014, at 5:46 AM, Cy Schubert wrote: > In message <20140725211249.ga3...@brick.home>, Edward Tomasz > =?utf-8?Q?Napiera= > C5=82a?= writes: >> On 0725T1019, Cy Schubert wrote: >>> In message <20140724183353.gl1...@hub.freebsd.org>, Glen Barber writes: New Automounter Contact: Edward Tomasz Napieral/a Deficiencies in the current automounter, amd(8), are a recurring problem reported by many FreeBSD users. A new automounter is being developed to address these concerns. The automounter is a cleanroom implementation of functionality available in most other Unix systems, using proper kernel support implemented via an autofs filesystem. The automounter supports a standard map format, and will integrate with the Lightweight Directory Access Protocol (LDAP) service. >>> >>> Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd >>> currently integrates with NIS as well. >> and hesiod? i can help with the testing danny >> It's just a matter of testing, apart from a trivial shell script. >> Would you be able to help me with this? >> > > > Sure! Just point me in the direction of the patches. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > ___ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-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: Unreadable DVD in FreeBSD and NetBSD
Thomas Mueller wrote on 26.07.2014 10:00: I have a DVD, a data DVD rather than movie or music, from Seagate Business Storage 2-bay NAS, that is mountable with mount_cd9660 but not readable in FreeBSD and NetBSD, using current amd64 versions of FreeBSD and NetBSD. ls /cdrom showed nothing; ls -al /cdrom showed total 6 dr-xr-xr-x 2 root wheel 2048 Nov 1 2012 . drwxr-xr-x 26 root wheel 1024 Jul 25 03:31 .. df showed Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/gpt/WD2G04 121863804 52278052 5983664847%/ devfs 11 0 100%/dev /dev/gpt/WD2G05 142191228 8022016 122793916 6%/home /dev/cd0 1832610 1832610 0 100%/cdrom so it looked like something was there. Mounted under Linux (System Rescue CD 4.3.0), main directory showed autorun.inf Rally Driver Installation Instructions Resources Seagate EULA Seagate NAS Backup Seagate NAS Discovery Seagate NAS Discovery Install Package Seagate Privacy Policy Setup.exe Windows Driver Haiku R1Alpha4 (haiku-os.org) was also able to show these directories and read the DVD. Is there any way I can read this DVD in FreeBSD or NetBSD, or is this a deficiency or bug in FreeBSD and NetBSD? I tried mount -t udf (no good) and "mount_cd9660 -be /dev/cd0 /cdrom" (same result as without -be). What more details could I give? Tom You need to install sysutils/udfclient. Your cd is in UDF format, that isn't covered by standard mount_udf. -- Regards, Ruslan T.O.S. Of Reality ___ 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"
Unreadable DVD in FreeBSD and NetBSD
I have a DVD, a data DVD rather than movie or music, from Seagate Business Storage 2-bay NAS, that is mountable with mount_cd9660 but not readable in FreeBSD and NetBSD, using current amd64 versions of FreeBSD and NetBSD. ls /cdrom showed nothing; ls -al /cdrom showed total 6 dr-xr-xr-x 2 root wheel 2048 Nov 1 2012 . drwxr-xr-x 26 root wheel 1024 Jul 25 03:31 .. df showed Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/gpt/WD2G04 121863804 52278052 5983664847%/ devfs 11 0 100%/dev /dev/gpt/WD2G05 142191228 8022016 122793916 6%/home /dev/cd0 1832610 1832610 0 100%/cdrom so it looked like something was there. Mounted under Linux (System Rescue CD 4.3.0), main directory showed autorun.inf Rally Driver Installation Instructions Resources Seagate EULA Seagate NAS Backup Seagate NAS Discovery Seagate NAS Discovery Install Package Seagate Privacy Policy Setup.exe Windows Driver Haiku R1Alpha4 (haiku-os.org) was also able to show these directories and read the DVD. Is there any way I can read this DVD in FreeBSD or NetBSD, or is this a deficiency or bug in FreeBSD and NetBSD? I tried mount -t udf (no good) and "mount_cd9660 -be /dev/cd0 /cdrom" (same result as without -be). What more details could I give? 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"
Re: FreeBSD Quarterly Status Report - Second Quarter 2014
In message <20140725211249.ga3...@brick.home>, Edward Tomasz =?utf-8?Q?Napiera= C5=82a?= writes: > On 0725T1019, Cy Schubert wrote: > > In message <20140724183353.gl1...@hub.freebsd.org>, Glen Barber writes: > > > New Automounter > > > > > >Contact: Edward Tomasz Napieral/a > > > > > >Deficiencies in the current automounter, amd(8), are a recurring > > >problem reported by many FreeBSD users. A new automounter is being > > >developed to address these concerns. > > > > > >The automounter is a cleanroom implementation of functionality > > >available in most other Unix systems, using proper kernel support > > >implemented via an autofs filesystem. The automounter supports a > > >standard map format, and will integrate with the Lightweight Directory > > >Access Protocol (LDAP) service. > > > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > > currently integrates with NIS as well. > > It's just a matter of testing, apart from a trivial shell script. > Would you be able to help me with this? > Sure! Just point me in the direction of the patches. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Fri, 25 Jul 2014, Craig Rodrigues wrote: On Fri, Jul 25, 2014 at 2:26 PM, Garrett Wollman wrote: In article you write: >Writing "an article" is hard. Writing a small section on how deleting >packages is different between pkg and, say, apt, is much easier. The >scope is known. Indeed, it's pretty trivial. I think the sort of article Craig was looking for was more on the order of apt command pkg command apt-get update pkg update (*1) ... ... (*1) Explanation of differences between how apt behaves and how pkg behaves. The set of common apt operations is pretty well-known, and most of them have direct pkg(8) equivalents. Garrett is describing exactly what I am looking for. I'm not looking for a complicated article explaining the internal differences between apt and pkg. Very few people have the interest or patience to read that. Providing a simple table contrasting the basic apt/yum/rpm/pkg commands for installing/upgrading/deleting packages is mostly what is needed. This gave me a flashback to the last time somebody said "Oh, I just want a simple little program." :) We need to show people that installing packages on FreeBSD is not like the "bad old pkg_add days" which people have bad memories of. We need to show that pkg is as good as what people are used to on modern Linux distributions. The wiki should be ideal for this. Start a table, fill in what you can, and others can fill in the other parts. ___ 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: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Fri, Jul 25, 2014 at 2:26 PM, Garrett Wollman < woll...@hergotha.csail.mit.edu> wrote: > In article you write: > > >Writing "an article" is hard. Writing a small section on how deleting > >packages is different between pkg and, say, apt, is much easier. The > >scope is known. > > Indeed, it's pretty trivial. > > I think the sort of article Craig was looking for was more on the > order of > > apt command pkg command > apt-get update pkg update (*1) > ... ... > > (*1) Explanation of differences between how apt behaves and how pkg > behaves. > > The set of common apt operations is pretty well-known, and most of > them have direct pkg(8) equivalents. > Hi, Garrett is describing exactly what I am looking for. I'm not looking for a complicated article explaining the internal differences between apt and pkg. Very few people have the interest or patience to read that. Providing a simple table contrasting the basic apt/yum/rpm/pkg commands for installing/upgrading/deleting packages is mostly what is needed. We need to show people that installing packages on FreeBSD is not like the "bad old pkg_add days" which people have bad memories of. We need to show that pkg is as good as what people are used to on modern Linux distributions. I have less experience with OS X, but if we can show people that pkg is as good as (or better than) MacPorts or Homebrew for installing third-party packages, that would be great as well, but focusing on Linux first would be good. -- Craig ___ 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: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
In article you write: >Writing "an article" is hard. Writing a small section on how deleting >packages is different between pkg and, say, apt, is much easier. The >scope is known. Indeed, it's pretty trivial. I think the sort of article Craig was looking for was more on the order of apt command pkg command apt-get update pkg update (*1) ... ... (*1) Explanation of differences between how apt behaves and how pkg behaves. The set of common apt operations is pretty well-known, and most of them have direct pkg(8) equivalents. -GAWollman ___ 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: FreeBSD Quarterly Status Report - Second Quarter 2014
On 0725T1019, Cy Schubert wrote: > In message <20140724183353.gl1...@hub.freebsd.org>, Glen Barber writes: > > New Automounter > > > >Contact: Edward Tomasz Napieral/a > > > >Deficiencies in the current automounter, amd(8), are a recurring > >problem reported by many FreeBSD users. A new automounter is being > >developed to address these concerns. > > > >The automounter is a cleanroom implementation of functionality > >available in most other Unix systems, using proper kernel support > >implemented via an autofs filesystem. The automounter supports a > >standard map format, and will integrate with the Lightweight Directory > >Access Protocol (LDAP) service. > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > currently integrates with NIS as well. It's just a matter of testing, apart from a trivial shell script. Would you be able to help me with this? ___ 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: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Fri, 25 Jul 2014, Craig Rodrigues wrote: What I'd like to see is an article on freebsd.org either on the wiki or in the handbook, which compares using apt, yum, rpm, whatever to pkg. Is anyone interested in working on an article like this? I don't have the bandwidth right now. A person to write that article needs detailed knowledge of pkg and the Linux package systems. I don't have that, but would be willing to help you develop an outline for the article. Having a design like that makes it easier to write when time and resources are available. Writing "an article" is hard. Writing a small section on how deleting packages is different between pkg and, say, apt, is much easier. The scope is known. ___ 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: FreeBSD Quarterly Status Report - Second Quarter 2014
In message <20140724183353.gl1...@hub.freebsd.org>, Glen Barber writes: > New Automounter > >Contact: Edward Tomasz Napieral/a > >Deficiencies in the current automounter, amd(8), are a recurring >problem reported by many FreeBSD users. A new automounter is being >developed to address these concerns. > >The automounter is a cleanroom implementation of functionality >available in most other Unix systems, using proper kernel support >implemented via an autofs filesystem. The automounter supports a >standard map format, and will integrate with the Lightweight Directory >Access Protocol (LDAP) service. Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd currently integrates with NIS as well. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: Future of pf / firewall in FreeBSD ? - does it have one ?
Sorry for the late reply. It's a busy time right now. In message <53d0239d.1050...@a1poweruser.com>, Fbsd8 writes: > Cy Schubert wrote: > >> On 20.07.2014 18:15, Maxim Khitrov wrote: > >>> In my opinion, the way forward is to forget (at least temporarily) the > >>> SMP changes, bring pf in sync with OpenBSD, put a policy in place to > >>> follow their releases as closely as possible, and then try to > >>> reintroduce all the SMP work. I think the latter has to be done > >>> upstream, otherwise it'll always be a story of diverging codebases. > >>> Furthermore, if FreeBSD developers were willing to spend some time > >>> improving pf performance on OpenBSD, then Henning and other OpenBSD > >>> developers might be more receptive to changes that make the porting > >>> process easier. > >> Even if you just drop current PF from FreeBSD, there is nobody, who want > >> to port new PF from OpenBSD. And this is not easy task, as you may > >> think. Gleb has worked on rewriting PF more than half year. So, return > >> back all improvements after import will be hard enough and, again, > >> nobody want to do it. :) > > > > One way or another something needs to be done and agreed it would be a lot > > of work. Our options are, > > > > a) Import OpenBSD pf thereby throwing away our current investment in pf. > > All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would > > > be all for naught. We do get a new pf though. Won't be a quality port > > though. Personally, not my #1 option. > > > > b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we > > > do save the work we put into our pf. Once again a lot of work. We'd be > > introducing incompatibility. > > > > c) Do nothing. It goes without saying that pf would suffer rot and > > eventually we would need to do something. > > > > d) Yank pf from tree. An option but probably not a great one. We do have > > two other packet filters in the kernel (ipfw and ipfilter) however they are > > > different beasts with different capabilities. I think the reason we have > > the packet filters we do have is for the capabilities they bring to the > > table. I for one have run more than one in the same kernel because each has > > > different capabilities. > > > > e) We could add capability to pf on a piecemeal basis. Option (b) but as > > time permits. Remember, people have jobs and commitments. Funding would > > help address this. > > > > f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more > > compatible with our IP stack? Could this be an option? > > > > Anything we do should work with VIMAGE and be able to handle nat66 as well. > > > > > > Hello Cy; > Finally a voice I recognize. If I remember correctly you stepped up to > the plate earlier this year and did for ipfilter the same kind of things Last autumn. > this thread is talking about for pf. IE; apply upstream maintenance and > convert to FreeBSD standards. I think your work was a BSD fork of > Darrow's ipfilter which from this point on all upstream maintenance must > be hand merged into the BSD fork. I am a long time ipfilter user and Actually we did not fork ipfilter. It's simply included into our tree, with a few modifications. > thank you for your dedication and work ethics getting the updated > ipfilter into 10.0 and 9.3 so quickly. You're welcome. I too am a long time ipfilter user (Solaris and FreeBSD). > > So as someone who has been there and done that already you have unique > experience to really know the size of the task in hours to accomplish a > pf upgrade. Could you list the tasks and hours it took you to perform > the ipfilter upgrade so readers can have a real insight into what they > are asking for? The experience is not unique. Every developer pretty much follows the same process when importing code into the tree. As for tasks, the ipfilter import was relatively simple compared to some others. Remember, ipfilter was designed to be run on any of the BSDs, SunOS, Solaris, and HP/UX, IRIX, and Tru64 UNIX. That made upgrading from 4.1.28 to 5.1.2 simpler than pf which is written only for OpenBSD and its stack. > > I agree with your option "e" above, but I would re-word it this way. > Using the pf fork we already have in place, hand merge upstream > differences in piecemeal chunks as time permits. The openbsd new syntax > being the first chunk, closely followed by VIMAGE awareness. Personally I would choose option "e" because of $JOB and $FAMILY commitments. Adding the new OpenBSD syntax may be more difficult than we might think. The new syntax may be related to a new internal structure of pf. If the new pf is a rewrite (ipfilter 5.1.2 was a rewrite of large chunks of code), then you have no option but to do a wholesale import and retrofit our mods back into it, if they would even fit at all. I think the first task for anyone taking this on would be to familiarize oneself with the current pf code
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Thu, Jul 17, 2014 at 11:25 AM, Craig Rodrigues wrote: > > For (2), encouraging people to move away from Linux to FreeBSD > on the server, may be something where we can get more wins. > I think we can do this by having more HOWTO articles on > the FreeBSD web page that explain the following: > > > (1) We need a HOWTO article that explains for each command using apt > or yum for installing packages, > how can I do the same thing using "pkg". > Even if we have a web page with a table, contrasting the > apt/yum commands, and pkg commands, that would be super > useful. > > A lot of folks have moved away from FreeBSD, purely because > they are sick of pkg_add. We need to explain to folks that > we have something better, that is quite competitive to > apt/yum, and it is easy to use. > > (2) We need a HOWTO article that explains how to set up >a FreeBSD environment with some of the major cloud providers, >i.e. Amazon, Rackspace, Microsoft Azure, etc. > > > > Hi, While I appreciate the enthusiasm of the responses to this e-mail thread, especially the patches to service(8), I feel that my original e-mail was hijacked into the weeds, and none of the questions that I asked were answered. :) So, I am assuming that no one is working on the HOWTO's that I mentioned in my original e-mail. :) In the latest edition of BSDNow ( http://www.bsdnow.tv/episodes/2014_07_23-des_challenge_iv ), they refer to a blog article where someone who was used to Linux posted their experience setting up FreeBSD: http://thiagoperrotta.wordpress.com/2014/07/20/here-be-dragons-freebsd-overview-part-i/ http://thiagoperrotta.wordpress.com/2014/07/21/here-be-packages-freebsd-overview-part-ii/ The Part II article goes in-depth into installing packages, and the user had a positive experience with using pkg, which is great. What I'd like to see is an article on freebsd.org either on the wiki or in the handbook, which compares using apt, yum, rpm, whatever to pkg. Is anyone interested in working on an article like this? I don't have the bandwidth right now. -- Craig ___ 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: Several minor annoyances on Current
Hi > I use this in /etc/sysctl.conf: > kern.corefile=/tmp/cores/%N.core In rc.conf I have clear_tmp_enable="YES" I would have used tmpfs for /tmp but my zpool/tmp is on an SSD which gives about the same result as fhttp://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931773.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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: Several minor annoyances on Current
Beeblebrox wrote: > Hello. Several questions for 11-Current: > > * I keep getting .core (gedit.core, midori.core, etc) files being > created either in /home/myuser or in the folder I run the command in on > terminal emulator (for example if I'm in ~/mydocs on terminal and run "$ > gedit filename", that folder gets a gedit.core file). Any way to stop this? I use this in /etc/sysctl.conf: kern.corefile=/tmp/cores/%N.core (You need to create the directory manually) ___ 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: [make xdev, libatf]: error: cstdarg: No such file or directory
On Fri, 2014-07-25 at 20:40 +0400, Boris Samorodov wrote: > Hi All! > > Here are errors I get with sources at r269089. > I am at 269090. make xdev TARGET=mips TARGET_ARCH=mips64 just finished for me. At this point, drop the rest of the options from the build as dim, bsdimp and sjg have fixed most of the issues requiring that. There is a fatal depend bug of some kind occuring if /usr/obj/ has builds in it. Try removing /usr/obj/* and then build again. sean > - > % uname -a > FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r269019: Wed > Jul 23 23:24:47 SAMT 2014 > bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64 > > % sudo make -C /usr/src TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1 > WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 > WITHOUT_CLANG_IS_CC=1 xdev > [...] > ===> lib/atf (obj,depend,all,install) > ===> lib/atf/libatf-c (obj) > ===> lib/atf/libatf-c++ (obj) > ===> lib/atf/libatf-c (depend) > ===> lib/atf/libatf-c++ (depend) > rm -f .depend > CC='cc -isystem //usr/armv6-freebsd/usr/include > -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6-freebsd/ > -B//usr/armv6-fr > eebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin > -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a-DHAVE_CONFIG_H > -DATF_A > RCH='"arm"' -DATF_BUILD_CC='"cc -isystem //usr/armv6-freebsd/usr/include > -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- > freebsd/ -B//usr/armv6-freebsd/usr/libexec > -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' > -DATF_BUILD_CFLAGS=' > "-O -pipe "' -DATF_BUILD_CPP='"cpp -isystem > //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib > --sysroot=//usr/ar > mv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec > -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' > -DATF_BUILD_CPPF > LAGS='""' -DATF_BUILD_CXX='"c++ -isystem //usr/armv6-freebsd/usr/include > -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- > freebsd/ -B//usr/armv6-freebsd/usr/libexec > -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' > -DATF_BUILD_CXXFLAGS > ='"-O -pipe "' -DATF_CONFDIR='"/etc/atf"' > -DATF_C_TESTS_BASE='"/usr/tests/lib/atf/libatf-c"' > -DATF_INCLUDEDIR='"/usr/include" > ' -DATF_LIBDIR='"/usr/lib"' -DATF_LIBEXECDIR='"/usr/libexec"' > -DATF_MACHINE='"armv6"' -DATF_M4='"/usr/bin/m4"' -DATF_PKGDATADI > R='"/usr/share/atf"' -DATF_SHELL='"/bin/sh"' -DATF_WORKDIR='"/tmp"' > -I/usr/src/contrib/atf -I/usr/src/lib/atf/libatf-c++/../li > batf-c -I. -DHAVE_CONFIG_H > /usr/src/contrib/atf/atf-c++/detail/application.cpp > /usr/src/contrib/atf/atf-c++/build.cpp / > usr/src/contrib/atf/atf-c++/check.cpp > /usr/src/contrib/atf/atf-c++/config.cpp > /usr/src/contrib/atf/atf-c++/detail/env.cpp /usr > /src/contrib/atf/atf-c++/detail/exceptions.cpp > /usr/src/contrib/atf/atf-c++/detail/fs.cpp > /usr/src/contrib/atf/atf-c++/detail/ > process.cpp /usr/src/contrib/atf/atf-c++/tests.cpp > /usr/src/contrib/atf/atf-c++/detail/text.cpp /usr/src/contrib/atf/atf-c++/u > tils.cpp > /usr/src/contrib/atf/atf-c++/detail/application.cpp:38:19: error: > cstdarg: No such file or directory > /usr/src/contrib/atf/atf-c++/detail/application.cpp:39:18: error: > cstdio: No such file or directory > /usr/src/contrib/atf/atf-c++/detail/application.cpp:40:19: error: > cstdlib: No such file or directory > [...] > - > ___ 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: libstand modification [committed]
On Tue, 2014-07-22 at 08:45 -0700, Sean Bruno wrote: > https://phabric.freebsd.org/D443 > > the 64bit version of userboot has been screaming about bit shifting > operators for a while now. > > The short explanation, amd64 sizeof(long) != i386 sizeof(long). > > The long explanation is in the phabric diff and comments. > > I see no reason to not commit this, but thought I'd throw it here for > your commentary. > > sean This is now in head. sean ___ 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: sys/boot unbuildable [solved]
On Tue, 2014-07-22 at 10:52 -0700, Sean Bruno wrote: > I can't quite see what the difference in building sys/i386/loader and > sys/i386/zfsloader is outside of the obvious zfs loader support flag. > This is now fixed in head. Thanks to Simon for the bmake assist. sean > But, loader will build, and zfsloader will not. Clang will give me a > nice error that tells me how I could fix this, but since loader builds > fine I suspect something buildsystem related is occuring here? > > cc -O2 -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH > -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../../ficl > -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../../ficl/i386 > -DLOADER_GZIP_SUPPORT -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT > -DLOADER_MBR_SUPPORT > -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../../common -I. > -Wall -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/.. > -I/home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../btx/lib > -march=i386 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -msoft-float -m32 -std=gnu99 -Qunused-arguments > -DLOADER_PREFER_AMD64 > -c /home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../loader/main.c > /home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader/../loader/main.c:38:10: > error: 'machine/bootinfo.h' file not found with include; use > "quotes" instead > #include > ^~~~ > "machine/bootinfo.h" > 1 error generated. > *** Error code 1 > > Stop. > make: stopped in /home/sbruno/bsd/fbsd_head/sys/boot/i386/zfsloader > > > > ___ > 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: Several minor annoyances on Current
Hi > This seems like a job for ulimit. Damien pointed that out as: ulimit -c 0 > Though, I would be more curious about why your applications are > crashing so as to generate core files in the first place. Well, this MAJOR annoyance lies somewhere between Radeon-KMS and gnome3's graphics/cairo. This started some 3 months back and I can only get some level of normalcy when I build cairo using "with_debug=1". Very strange. Also, a number of apps just flat-out refuse to start; most notably mozilla's firefox & seamonkey. Monsieur Pédron is aware of the problem, although as stated it's been over 3 months. While I'm on a roll :P One major peeve is that installed apps fail to create an icon in the desktop menu structure. I know that a) maintainer must set DESKTOP_ENTRIES in the Makefile OR b) users can add appname.desktop in /usr/local/share/applications/ but as a dreamer, I know there has to be a better solution other than badgering maintainers or slogging through the task of adding menu shortcut items? - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931761.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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: Several minor annoyances on Current
On Fri, 25 Jul 2014, Beeblebrox wrote: Hello. Several questions for 11-Current: * I keep getting .core (gedit.core, midori.core, etc) files being created either in /home/myuser or in the folder I run the command in on terminal emulator (for example if I'm in ~/mydocs on terminal and run "$ gedit filename", that folder gets a gedit.core file). Any way to stop this? This seems like a job for ulimit. Though, I would be more curious about why your applications are crashing so as to generate core files in the first place. -Ben ___ 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"
[make xdev, libatf]: error: cstdarg: No such file or directory
Hi All! Here are errors I get with sources at r269089. - % uname -a FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r269019: Wed Jul 23 23:24:47 SAMT 2014 bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64 % sudo make -C /usr/src TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1 WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG_IS_CC=1 xdev [...] ===> lib/atf (obj,depend,all,install) ===> lib/atf/libatf-c (obj) ===> lib/atf/libatf-c++ (obj) ===> lib/atf/libatf-c (depend) ===> lib/atf/libatf-c++ (depend) rm -f .depend CC='cc -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6-freebsd/ -B//usr/armv6-fr eebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a-DHAVE_CONFIG_H -DATF_A RCH='"arm"' -DATF_BUILD_CC='"cc -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- freebsd/ -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' -DATF_BUILD_CFLAGS=' "-O -pipe "' -DATF_BUILD_CPP='"cpp -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/ar mv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' -DATF_BUILD_CPPF LAGS='""' -DATF_BUILD_CXX='"c++ -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib --sysroot=//usr/armv6- freebsd/ -B//usr/armv6-freebsd/usr/libexec -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib"' -DATF_BUILD_CXXFLAGS ='"-O -pipe "' -DATF_CONFDIR='"/etc/atf"' -DATF_C_TESTS_BASE='"/usr/tests/lib/atf/libatf-c"' -DATF_INCLUDEDIR='"/usr/include" ' -DATF_LIBDIR='"/usr/lib"' -DATF_LIBEXECDIR='"/usr/libexec"' -DATF_MACHINE='"armv6"' -DATF_M4='"/usr/bin/m4"' -DATF_PKGDATADI R='"/usr/share/atf"' -DATF_SHELL='"/bin/sh"' -DATF_WORKDIR='"/tmp"' -I/usr/src/contrib/atf -I/usr/src/lib/atf/libatf-c++/../li batf-c -I. -DHAVE_CONFIG_H /usr/src/contrib/atf/atf-c++/detail/application.cpp /usr/src/contrib/atf/atf-c++/build.cpp / usr/src/contrib/atf/atf-c++/check.cpp /usr/src/contrib/atf/atf-c++/config.cpp /usr/src/contrib/atf/atf-c++/detail/env.cpp /usr /src/contrib/atf/atf-c++/detail/exceptions.cpp /usr/src/contrib/atf/atf-c++/detail/fs.cpp /usr/src/contrib/atf/atf-c++/detail/ process.cpp /usr/src/contrib/atf/atf-c++/tests.cpp /usr/src/contrib/atf/atf-c++/detail/text.cpp /usr/src/contrib/atf/atf-c++/u tils.cpp /usr/src/contrib/atf/atf-c++/detail/application.cpp:38:19: error: cstdarg: No such file or directory /usr/src/contrib/atf/atf-c++/detail/application.cpp:39:18: error: cstdio: No such file or directory /usr/src/contrib/atf/atf-c++/detail/application.cpp:40:19: error: cstdlib: No such file or directory [...] - -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: Several minor annoyances on Current
> ... in retrospect I can think of > several good reasons to turn off bootp on a per-boot basis. The > attached patch provides a knob for that, I'll commit it if there are > no objections. Thanks - a knob in /boot/loader.conf as vfs.nfs.bootp_disable="YES" should do nicely. Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931753.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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: Several minor annoyances on Current
On Fri, 2014-07-25 at 05:04 -0700, Beeblebrox wrote:
> Kurt Jaeger wrote:
>
> > Can you check whether one of your ethernet-ports has a double life
> > as IPMI port and that one sends out the DHCP ?
>
> No such setup. This is my workstation, with wake-on-lan and pxe-boot
> disabled in bios.
> Checking boot messages provides a little more insight - Its not one but
> *both* NIC's that look for DHCP. Also, this is before root gets mounted, so
> what's in rc.conf is irrelevant:
>
> Sending DHCP Discover packet from interface re0 (mac#)
> Sending DHCP Discover packet from interface re1 (mac#)
> Received DHCP Offer packet on re0 from 192.168.1.1 (accepted)
> Received DHCP Offer packet on re0 from 192.168.1.1 (ignored)
> Received DHCP Offer packet on re0 from 192.168.1.1 (ignored)
> Sending DHCP Request packet from interface re0 (mac#)
> Received DHCP Ack packet on re0 from 192.168.1.1 (accepted)
> DHCP timeout for interface re1
> re0 at 192.168.1.11 server 192.168.1.1
> subnet mask 255.255.255.0 router 192.168.1.1
> Adjusted interface re0
> Shutdown interface re1
> Trying to mount root from zfs:bsd []...
>
> I compile and use the same kernel for both host and pxe-booted diskless
> clients. So my kernel config file has
> options NFSCL # Network Filesystem Client
> options NFS_ROOT# NFS usable as /, requires NFSCL
> options BOOTP # Needed for non-btx PXE
> options BOOTP_NFSROOT # Needed for non-btx PXE
> It's probably what's causing this behavior. Kernel must receive IP before it
> can try and mount an NFS volume as root. However, I would have assumed that
> the "vfs.root.mountfrom=" setting in loader.conf would be read before such
> attempt...
>
I made changes last year that allowed vfs.root.mountfrom to
unconditionally override any path provided by the bootp/dhcp server.
While it overrides the server-provided path, it doesn't prevent
contacting the server (the override may be for a different nfs path).
See http://svnweb.freebsd.org/base?view=revision&revision=253847 for
details.
I didn't consider at the time that someone might want to avoid doing any
bootp configuration at all, but in retrospect I can think of several
good reasons to turn off bootp on a per-boot basis. The attached patch
provides a knob for that, I'll commit it if there are no objections.
-- Ian
Index: sys/nfs/bootp_subr.c
===
--- sys/nfs/bootp_subr.c (revision 268986)
+++ sys/nfs/bootp_subr.c (working copy)
@@ -1551,8 +1551,11 @@ bootpc_init(void)
struct nfsv3_diskless *nd;
struct thread *td;
int timeout;
- int delay;
+ int delay, disable;
+ if (TUNABLE_INT_FETCH("vfs.nfs.bootp_disable", &disable) && disable)
+ return;
+
timeout = BOOTP_IFACE_WAIT_TIMEOUT * hz;
delay = hz / 10;
___
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: zfs send/recv: STILL invalid Backup Stream
2014-07-25 15:41, Larry Rosenman wrote: On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote: Don't know, I'd guess some network-related memory limit is being hit on the sending site. Why not try to decouple the 'zfs send' from a network copy and ssh: Login to a remote side, do a 'zfs send' to some local temporary file there, then feed that file to ssh and send it over to a home host, where it can be piped into some simple program like md5 or 'wc -c' instead of a zfs recv. I think I've done that, but it sort of defeats the purpose, Does it? If you are lucky it would fail again, but this time you'd know if it was a zfs or a network problem. as the stream becomes a big file on disk. If it's an incremental stream and you have sufficient free space available, than it's all fine and you should try that. If storage is a problem you may try piping /dev/zero or /dev/random through ssh to feed a remote consumer, simulating a huge stream, and hope that it will eventually fail. I'd like to get some help chasing what parameter(s) need to be fixed here. [...] Can I get some ideas on: 1) what MIGHT need tweaking 2) would (k|d)trace help? 3) what else could we find out what's being told no memory? Sorry, not deep enough into fs or network to be able to tell. My guess it that it's a networking issue (not zfs), and not directly related to virtual memory or swap or ARC management. To: freebsd-current@freebsd.org, Freebsd fs If you'd be able to demonstrate that this is unrelated to zfs, then the freebsd-...@freebsd.org mailing list would perhaps be a suitable place to continue this thread. Mark ___ 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: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI
On 20.07.2014 18:19, Anders Bolt-Evensen wrote: > Hello, everyone! Hi! > When I try to use the radeon driver, X exits because of BIOS errors > (since I do not use BIOS when in EFI mode), as can be seen from the > output of "dmesg -a" from a verbose boot (at the time dmesg -a was run, > I had commented out the line with the intel driver to force it to use > the radeon driver instead, since the intel driver caused the screen to > freeze). I can't comment on the Intel driver behavior, but I never tested the Radeon driver with UEFI yet. The BIOS errors you see mean that the driver failed to locate the Video BIOS. There no relation with the System BIOS or, in your case, UEFI. > info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... > info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table > info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND Those calls to get the "VFCT" ACPI table should succeed in an UEFI context. But as I said, this was never tested. > error: [drm:pid1363:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM > drmn0: error: Fatal error during GPU init > info: [drm] radeon: finishing device. > [TTM] Memory type 2 has not been initialized > device_attach: drmn0 attach returned 22 And here, without the Video BIOS, the driver misses too much information and abort the initialization of the card. I currently have no suggestion to make to debug and fix this situation. I need to study a bit what should be going on before. My laptop, which has UEFI available, doesn't boot FreeBSD for now (it fails to probe the system memory). I'll get back to you as soon as I can work on this. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI
On 23.07.2014 22:18, Lokadamus wrote: > Am 20.07.2014 18:19, schrieb Anders Bolt-Evensen: >> info: [drm] Initialized i915 1.6.0 20080730 > 1.6.0 20080730 looks old for me. > Have a look at https://wiki.freebsd.org/Graphics section "Installing KMS > Ports" 1.6.0 is the version of the kernel driver, not xf86-video-intel. He is using the latest version available in FreeBSD. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: zfs send/recv: STILL invalid Backup Stream
On 2014-07-25 09:03, Allan Jude wrote:
On 2014-07-25 09:49, Larry Rosenman wrote:
On 2014-07-25 08:41, Larry Rosenman wrote:
On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote:
Don't know, I'd guess some network-related memory limit is being hit
on the sending site.
Why not try to decouple the 'zfs send' from a network copy and ssh:
Login to a remote side, do a 'zfs send' to some local temporary file
there, then feed that file to ssh and send it over to a home host,
where it can be piped into some simple program like md5 or 'wc -c'
instead of a zfs recv.
I think I've done that, but it sort of defeats the purpose, as the
stream
becomes a big file on disk.
I'd like to get some help chasing what parameter(s) need to be fixed
here.
sysctl output and other things at:
http://www.lerctr.org/~ler/FreeBSD/
Can I get some ideas on:
1) what MIGHT need tweaking
2) would (k|d)trace help?
3) what else could we find out what's being told no memory?
I *CAN* give SSH/Root/etc access to BOTH boxes on request.
What else do you need?
Try just ssh into the 'source' host, and do:
zfs send -v -R zroot@${DATE} > /dev/null
and see if it actually finishes, or if it runs out of memory again.
that, of course, worked fine :(
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
___
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: zfs send/recv: STILL invalid Backup Stream
On 2014-07-25 09:49, Larry Rosenman wrote:
> On 2014-07-25 08:41, Larry Rosenman wrote:
>> On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote:
>>> Don't know, I'd guess some network-related memory limit is being hit
>>> on the sending site.
>>>
>>> Why not try to decouple the 'zfs send' from a network copy and ssh:
>>> Login to a remote side, do a 'zfs send' to some local temporary file
>>> there, then feed that file to ssh and send it over to a home host,
>>> where it can be piped into some simple program like md5 or 'wc -c'
>>> instead of a zfs recv.
>>>
>> I think I've done that, but it sort of defeats the purpose, as the stream
>> becomes a big file on disk.
>>
>> I'd like to get some help chasing what parameter(s) need to be fixed
>> here.
>>
> sysctl output and other things at:
>
> http://www.lerctr.org/~ler/FreeBSD/
>
>
>> Can I get some ideas on:
>> 1) what MIGHT need tweaking
>> 2) would (k|d)trace help?
>> 3) what else could we find out what's being told no memory?
>
> I *CAN* give SSH/Root/etc access to BOTH boxes on request.
>
> What else do you need?
>
>
Try just ssh into the 'source' host, and do:
zfs send -v -R zroot@${DATE} > /dev/null
and see if it actually finishes, or if it runs out of memory again.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
Re: zfs send/recv: STILL invalid Backup Stream
On 2014-07-25 08:41, Larry Rosenman wrote: On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote: Don't know, I'd guess some network-related memory limit is being hit on the sending site. Why not try to decouple the 'zfs send' from a network copy and ssh: Login to a remote side, do a 'zfs send' to some local temporary file there, then feed that file to ssh and send it over to a home host, where it can be piped into some simple program like md5 or 'wc -c' instead of a zfs recv. I think I've done that, but it sort of defeats the purpose, as the stream becomes a big file on disk. I'd like to get some help chasing what parameter(s) need to be fixed here. sysctl output and other things at: http://www.lerctr.org/~ler/FreeBSD/ Can I get some ideas on: 1) what MIGHT need tweaking 2) would (k|d)trace help? 3) what else could we find out what's being told no memory? I *CAN* give SSH/Root/etc access to BOTH boxes on request. What else do you need? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ 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: Several minor annoyances on Current
Kurt Jaeger wrote: > Can you check whether one of your ethernet-ports has a double life > as IPMI port and that one sends out the DHCP ? No such setup. This is my workstation, with wake-on-lan and pxe-boot disabled in bios. Checking boot messages provides a little more insight - Its not one but *both* NIC's that look for DHCP. Also, this is before root gets mounted, so what's in rc.conf is irrelevant: Sending DHCP Discover packet from interface re0 (mac#) Sending DHCP Discover packet from interface re1 (mac#) Received DHCP Offer packet on re0 from 192.168.1.1 (accepted) Received DHCP Offer packet on re0 from 192.168.1.1 (ignored) Received DHCP Offer packet on re0 from 192.168.1.1 (ignored) Sending DHCP Request packet from interface re0 (mac#) Received DHCP Ack packet on re0 from 192.168.1.1 (accepted) DHCP timeout for interface re1 re0 at 192.168.1.11 server 192.168.1.1 subnet mask 255.255.255.0 router 192.168.1.1 Adjusted interface re0 Shutdown interface re1 Trying to mount root from zfs:bsd []... I compile and use the same kernel for both host and pxe-booted diskless clients. So my kernel config file has options NFSCL # Network Filesystem Client options NFS_ROOT# NFS usable as /, requires NFSCL options BOOTP # Needed for non-btx PXE options BOOTP_NFSROOT # Needed for non-btx PXE It's probably what's causing this behavior. Kernel must receive IP before it can try and mount an NFS volume as root. However, I would have assumed that the "vfs.root.mountfrom=" setting in loader.conf would be read before such attempt... - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931678.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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: Several minor annoyances on Current
> Damian Weber wrote: >is there >ifconfig_em0="DHCP" >or anything like that in your rc.conf? No, network related rc.conf entries: network_interfaces="lo0 re0 re1" ifconfig_lo0="inet 127.0.0.1/24" ifconfig_re0="inet 192.168.1.10/24" ifconfig_re1="inet 192.168.2.1/24" gateway_enable="YES" defaultrouter="192.168.1.1" dhclient_enable="NO" Thanks & regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5931665.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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"
Several minor annoyances on Current
Hello. Several questions for 11-Current: * I keep getting .core (gedit.core, midori.core, etc) files being created either in /home/myuser or in the folder I run the command in on terminal emulator (for example if I'm in ~/mydocs on terminal and run "$ gedit filename", that folder gets a gedit.core file). Any way to stop this? * I noticed the system now does a dhcp lookup during boot, while in the past it did not do so (I have static IP defined in rc.conf). Any reason for this change, and how can I disable it (already have dhclient_enable="NO" in rc.conf) * Are there any tweaks (sysctl or such) for fastest possible shutdown for "poweroff"? * I have a kernel with all witness/debug code disabled, and the zfs root is on a Sata3-SSD. The boot process seems a little slow to me and I'm curious as to possible reasons. Other than disabling debug, what else can I do to speed-up boot process (CPU: AMD Phenom II X4 B60 3415.38-MHz K8-class) Thanks and Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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: zfs send/recv: STILL invalid Backup Stream
On 2014-07-24 19:56, Allan Jude wrote:
or better yet:
ssh r...@tbh.lerctr.org "zfs send ..." | mbuffer -m 16M | zfs recv
...
(The misc/mbuffer compensates for bursty zfs reads and writes.
A note to myself: I should suggest to Allan to add mbuffer
in a pipe as used in sysutils/zxfer, instead of patching zxfer
for our local use :)
zxfer can already do this, with the -D option
I actually use misc/clpbar and get a progress bar as well
-D 'bar -s %%size%% -bl 1m -bs 128m'
or in your case: -D 'mbuffer -m 16M'
Thank you Allan! It shows it's been a while since the last time
I inspected the guts of zxfer.
2014-07-25 06:43 Larry Rosenman wrote:
Ok, I did the mbuffer trick, and the SEND side is where the memory
issue is:
borg.lerctr.org /home/ler/bin $ tail zfs-send.log
23:28:12 15.7G zroot/home@2014-07-24_22:56
23:28:13 15.7G zroot/home@2014-07-24_22:56
23:28:14 15.7G zroot/home@2014-07-24_22:56
23:28:15 15.7G zroot/home@2014-07-24_22:56
23:28:16 15.7G zroot/home@2014-07-24_22:56
23:28:17 15.7G zroot/home@2014-07-24_22:56
23:28:18 15.7G zroot/home@2014-07-24_22:56
23:28:19 15.7G zroot/home@2014-07-24_22:56
23:28:20 15.8G zroot/home@2014-07-24_22:56
Write failed: Cannot allocate memory
borg.lerctr.org /home/ler/bin $
Good information. So the "Write failed: Cannot allocate memory"
on the send side is what is causing the "invalid backup stream"
on the receiving side.
borg.lerctr.org /home/ler/bin $ tail zfs-recv.log
cannot receive new filesystem stream: invalid backup stream
borg.lerctr.org /home/ler/bin $
borg.lerctr.org /home/ler/bin $ cat backup-TBH-ZFS-initial.sh
#!/bin/sh
DATE=`date "+%Y-%m-%d_%H:%M"`
#DATE2=2013-03-24
#DATE2=`date -v "-1d" "+%Y-%m-%d"`
# snap the source
ssh r...@tbh.lerctr.org zfs snapshot -r zroot@${DATE}
# zfs copy the source to here.
ssh r...@tbh.lerctr.org 2>zfs-send.log "zfs send -v -R zroot@${DATE} "
| \
mbuffer -m 16M 2>mbuffer.log | \
zfs recv -F -u -v -d zroot/backups/TBH3 2>zfs-recv.log
# make sure we NEVER allow the backup stuff to automount.
/sbin/zfs list -H -t filesystem -r zroot/backups/TBH3| \
awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh
borg.lerctr.org /home/ler/bin $
borg.lerctr.org /home/ler/bin $ ssh tbh vmstat -z
ITEM SIZE LIMIT USED FREE REQ FAIL
SLEEP
[...]
Where to now?
Don't know, I'd guess some network-related memory limit is being hit
on the sending site.
Why not try to decouple the 'zfs send' from a network copy and ssh:
Login to a remote side, do a 'zfs send' to some local temporary file
there, then feed that file to ssh and send it over to a home host,
where it can be piped into some simple program like md5 or 'wc -c'
instead of a zfs recv.
Mark
___
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: r268621: panic: shadowed tmpfs v_object [with dump]
Got the same panic, is this fix getting committed? Or has it already been committed? r269053 Thanks, confirming that it fixes the panic as well :-) ___ 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"
