FreeBSD 9 & recompile ports
Greetings all and my apologies for cross posting! There seems to be a confusion regarding the ABI change in FreeBSD 9 and if this affects the usual upgrade path which includes a full port rebuild. The relevant post is here: http://forums.freebsd.org/showthread.php?t=28831 Frankly, I am also confused because I remember a relevant discussion a few months ago in the lists. Traditionally a major RELEASE upgrade requires a full ports rebuild, however this time there is no COMPAT_FREEBSD8 in GENERIC and most upgraded systems seem to be working fine. On the other hand this is stated in UPDATING: 20110828: Bump the shared library version numbers for libraries that do not use symbol versioning, have changed the ABI compared to stable/8 and which shared library version was not bumped. Done as part of 9.0-RELEASE cycle. Your input would be appreciated! Regards, -- George Kontostanos Aicom telecoms ltd ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
On Wednesday, January 11, 2012 4:11:10 pm Rob Clark wrote: > System: Dell 600sc > Currently running: 8.2-RELEASE > > In attempting to update this system to 8-STABLE I did > what I usually do to update a system (see below). > make buildworld completes successfully, but make > buildkernel does not. I usually create a custom > kernel, but for this system I went with GENERIC as > is. > > The error message is: > /usr/src/sys/kern/init_sysent.c:568: error: invalid > application of 'sizeof' to incomplete type 'struct > posix_fadvise_args' /usr/src/sys/kern/init_sysent.c:568: > error: 'posix_fadvise' undeclared here (not in a > function) *** Error code 1 This sounds like you have an incomplete tree that only got part of a change (specifically, /usr/src/sys/sys/sysproto.h seems stale). Have you tried a different cvsup mirror? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FYI: 9.0-RELEASE announced...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JFYI for those of you who aren't subscribed to the announce@ mailing list... 9.0-RELEASE is, finally, announced. The announcement message is available here: http://www.freebsd.org/releases/9.0R/announce.html Lots of you noticed that the 9.0-RELEASE ISO and memstick images appeared on the FTP sites a while ago. But as pointed out this release turned out to be an example of why the "official policy" is that it's not truly released until the announcement email gets sent out. I had not tested using sysinstall(8) to install pre-built packages from the DVD during my initial testing since we're sorta moving away from sysinstall(8). I had just tested installing the pre-built packages using pkg_add(8). Someone noticed sysinstall(8) misbehaved before I got the images put up on Bittorrent and the fix was simply adding one file to the DVD image that the new build infrastructure omitted since bsdinstall(8) doesn't use it. So I went ahead with replacing the DVD images on the FTP site. That's also why we waited longer than normal between the images appearing on the FTP sites and the announcement - we gave extra time to try and make sure the updated images got to all the FTP mirrors. Sorry about the screw-up. If you downloaded the amd64 and/or i386 DVD images before now you might want to check the checksums with the ones posted in the release announcement. The fix to make sysinstall(8) happy about installing from the DVD images was the *only* change made to the updated images. The "bad" images were never available via Bittorrent so if you got the images that way you wouldn't have a bad image. On behalf of the Release Engineering Team and the FreeBSD Developers we hope you enjoy 9.0-RELEASE. - -- Ken Smith - - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8PcpsACgkQ/G14VSmup/aLFgCfar7x43ViPu44M3eF8MzvYhOU /z0AnRN1jXDT1fS0UA9J0Trd5sRQcwdy =oU1m -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
On Wed, 11 Jan 2012 21:52:28 -0600 Andre Goree wrote: > On Wed, Jan 11, 2012 at 3:11 PM, Rob Clark wrote: > > > System: Dell 600sc > > Currently running: 8.2-RELEASE > > > > In attempting to update this system to 8-STABLE I did > > what I usually do to update a system (see below). > > make buildworld completes successfully, but make > > buildkernel does not. I usually create a custom > > kernel, but for this system I went with GENERIC as > > is. > > > > The error message is: > > /usr/src/sys/kern/init_sysent.c:568: error: invalid > > application of 'sizeof' to incomplete type 'struct > > posix_fadvise_args' /usr/src/sys/kern/init_sysent.c:568: > > error: 'posix_fadvise' undeclared here (not in a > > function) *** Error code 1 > > > > I found this pertaining to > > posix_fadvise in /usr/src/UPDATING: > > 20120106: > > A new VOP_ADVISE() was added to support > > posix_fadvise(2). All filesystem modules must be > > recompiled. > > > > Not sure what 'filesystem modules' is or referring to > > here. Also, am I not already recompiling 'All > > filesystem modules' during make buildworld? > > > > What I did (and usually do): > > csup -L 2 /root/stable-supfile > > rm -rf /etc.old cp -Rp /etc /etc.old > > adjkerntz -i > > cd /usr/obj > > chflags -R noschg * > > rm -rf * > > cd /usr/src > > /usr/bin/time -h make buildworld || exit > > > > build world finishes successfully. > > > > Then: > > cd /usr/src > > make buildkernel KERNCONF=GENERIC > > make installkernel KERNCONF=GENERIC > > > > This fails with error: > > /usr/src/sys/kern/init_sysent.c:568: error: invalid > > application of 'sizeof' to incomplete type 'struct > > posix_fadvise_args' /usr/src/sys/kern/init_sysent.c:568: > > error: 'posix_fadvise' undeclared here (not in a > > function) *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/GENERIC. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > Following attempts: > > > > Attempt 2: > > I tried using 'make buildkernel' (without > > specifying KERNCONF) make buildkernel fails with > > same error. > > > > Attempt 3: > > Started from the beginning (same process as above) > > with new csup (sources) -- make buildkernel still > > failed with same error. > > > > Any help here would be greatly appreciated. > > In way over my head here. I have all logs from all > > attempts of the above if needed. > > > > Thanks, > > Rob Clark > > > > ___ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > > > Perhaps two 'make cleandir' inside /usr/src will help. > > Run it just after removing everything within /usr/obj. > > FWIW, I usually run this simple bash script before building world on my > machines: > > #!/bin/bash > chflags -R noschg /usr/obj/usr > rm -rf /usr/obj/usr > cd /usr/src ; make cleandir ; make cleandir > exit 0 Thanks Andre, I'll make note of that one. Rob -- Rob Clark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
On Thu, 12 Jan 2012 08:15:50 -0500 John Baldwin wrote: > On Wednesday, January 11, 2012 4:11:10 pm Rob Clark wrote: > > System: Dell 600sc > > Currently running: 8.2-RELEASE > > > > In attempting to update this system to 8-STABLE I did > > what I usually do to update a system (see below). > > make buildworld completes successfully, but make > > buildkernel does not. I usually create a custom > > kernel, but for this system I went with GENERIC as > > is. > > > > The error message is: > > /usr/src/sys/kern/init_sysent.c:568: error: invalid > > application of 'sizeof' to incomplete type 'struct > > posix_fadvise_args' /usr/src/sys/kern/init_sysent.c:568: > > error: 'posix_fadvise' undeclared here (not in a > > function) *** Error code 1 > > This sounds like you have an incomplete tree that only got part of a change > (specifically, /usr/src/sys/sys/sysproto.h seems stale). Have you tried a > different cvsup mirror? > > -- > John Baldwin Good point. Didn't try that, I'll give it a go. Rob -- Rob Clark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
>> chflags -R noschg /usr/obj/usr
>> rm -rf /usr/obj/usr
It's much faster to do:
/bin/rm -rf ${obj}/* 2> /dev/null || /bin/chflags -R 0 ${obj}/* &&
/bin/rm -rf ${obj}/*
--
You can observe a lot just by watching. -- Yogi Berra
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
On Thu, Jan 12, 2012 at 5:52 PM, Doug Barton wrote:
>
>>> chflags -R noschg /usr/obj/usr
>>> rm -rf /usr/obj/usr
>
> It's much faster to do:
>
> /bin/rm -rf ${obj}/* 2> /dev/null || /bin/chflags -R 0 ${obj}/* &&
> /bin/rm -rf ${obj}/*
+1. And it's faster yet when you can run parallel copies of rm on
different portions of the directory tree (e.g. xargs, find [..] -exec)
as rm is O(n).
Cheers,
-Garrett
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
On 01/12/2012 09:11 PM, Garrett Cooper wrote: +1. And it's faster yet when you can run parallel copies of rm on different portions of the directory tree (e.g. xargs, find [..] -exec) as rm is O(n). I have always wondered about that! I thought that the main bottleneck in "rm -r" might be deleting directories which are not in the disk cache, which then have to be copied from the disk. Copying two different parts of the disk into cache - well it has to be done one at a time whether the jobs asking for the copy of the disk are going concurrently or consecutively. And perhaps two instances of "rm -r" acting on different parts of the hard drive will cause disk thrashing, so that they might even slow each other down. But this is all guess work on my part. If I am wrong, and "rm -r" does work faster when working in parallel on different parts, then why doesn't someone write the "rm" command to fork copies of itself that work on different parts of large trees? Stephen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
On Thu, 12 Jan 2012 19:11:54 -0800
Garrett Cooper wrote:
> On Thu, Jan 12, 2012 at 5:52 PM, Doug Barton
> wrote:
> >
> >>> chflags -R noschg /usr/obj/usr
> >>> rm -rf /usr/obj/usr
> >
> > It's much faster to do:
> >
> > /bin/rm -rf ${obj}/* 2> /dev/null || /bin/chflags -R 0 ${obj}/* &&
> > /bin/rm -rf ${obj}/*
>
> +1. And it's faster yet when you can run parallel copies of rm on
> different portions of the directory tree (e.g. xargs, find [..] -exec)
> as rm is O(n).
> Cheers,
> -Garrett
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscr...@freebsd.org"
What I've been doing just before I do a make buildworld/buildkernel
is:
mdmfs -s2g md1 /usr/obj
on a clean /usr/obj . If I need to recompile before a boot, just umount
and recreate.
Provides a little performance boost too.
Regards,
--
joe
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
On Thu, Jan 12, 2012 at 7:23 PM, Stephen Montgomery-Smith wrote: > On 01/12/2012 09:11 PM, Garrett Cooper wrote: > >> +1. And it's faster yet when you can run parallel copies of rm on >> different portions of the directory tree (e.g. xargs, find [..] -exec) >> as rm is O(n). > > > I have always wondered about that! I thought that the main bottleneck in > "rm -r" might be deleting directories which are not in the disk cache, which > then have to be copied from the disk. Copying two different parts of the > disk into cache - well it has to be done one at a time whether the jobs > asking for the copy of the disk are going concurrently or consecutively. > > And perhaps two instances of "rm -r" acting on different parts of the hard > drive will cause disk thrashing, so that they might even slow each other > down. Not really. The problem is limited by the fact that rm(1) needs to dive into the kernel each time it does an unlink(1) syscall. Per Prof. McKusick's teaching and the way things are designed from libc to disk -- the process is artificially like: rm -> syscall -> top-half of the kernel -> vfs -> filesystem (in my case ZFS) -> geom -> scsi layer -> storage controller/disk driver. This is super expensive as n becomes large as the path is long, so the best to amortize the operation is to run more instances in parallel as there should be a relatively low chance of there being lock contention (assuming you're not consuming too many GIANT locks, you don't overprovision your system, etc). See the loop in .../bin/rm/rm.c:rm_tree(char**) if you're curious where things have issues. > But this is all guess work on my part. > > If I am wrong, and "rm -r" does work faster when working in parallel on > different parts, Yes. Less modifications to directory entries -> less vfs locking contention and less useless writing back to disk -> better. > then why doesn't someone write the "rm" command to fork > copies of itself that work on different parts of large trees? Perhaps. The point is that my systems can do more work in parallel with a larger number of rm's in order to improve throughput. I learned this the hard way when I started deleting a prepopulated directory with pjd's fstest: it took hours to prune directory entries the O(n) way by a small fraction (<10% of 4 mil. or 40 mil. files). When I did stuff in parallel (have 8 regular cores, 8 SMT cores), the process took less than an hour to complete. Thanks, -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
On 01/12/2012 20:10, Garrett Cooper wrote: > When I did > stuff in parallel (have 8 regular cores, 8 SMT cores), the process > took less than an hour to complete. Sounds like you should get to work figuring out how to optimize rm to take advantage of this. :) Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
