Re: zpool scrub hangs on 7.2-stable
On Sun, 20 Sep 2009 17:42 -, christof.schulze wrote: Hello, currently I am running a 7.2 stable with zfs v13. Things work nicely except that zpool scrub hangs without disk activity. I do not get any error messages in dmesg or /var/log/messages and therefore I do not know where to look further. Is this a known issue or should I investigate? If the latter is the case I would need some help doing so. % uname -a ~ FreeBSD ccschu935 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Jul 7 04:56:00 CEST 2009 r...@ccschu935:/usr/obj/usr/src/sys/GENERIC amd64 % zpool status ~ pool: tank state: ONLINE scrub: scrub in progress for 0h3m, 0,00% done, 3370h48m to go config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 ad0s6 ONLINE 0 0 0 ad0s3fONLINE 0 0 0 ad0s3eONLINE 0 0 0 cache mmcsd0UNAVAIL 0 0 0 cannot open errors: No known data errors kind Regards Christof I see you cache is disabled no available. Even though I don't think this should or might be the problem can you remove the device from the pool and re-scrub to see if that relieves the problem. -- Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ 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"
Fixup manpath.config suggestion
Fix manpath.config optional manpath of /usr/X11R6. This has not been a actual path for some time now and is just a symlink to /usr/local which is already in the manpath.config. The attached patch just deletes the referenced lines, it might be better off just commenting them out and adding a comment next to them referring to the symlink usage. -- Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1))--- manpath.config.orig 2009-09-14 06:41:11.0 -0400 +++ manpath.config 2009-09-17 17:29:37.088290738 -0400 @@ -17,14 +17,12 @@ # check if the directory exists and if it does, add it to MANPATH # OPTIONAL_MANPATH /usr/local/man -OPTIONAL_MANPATH /usr/X11R6/man # # set up PATH to MANPATH mapping # MANPATH_MAP/bin/usr/share/man MANPATH_MAP/usr/bin/usr/share/man MANPATH_MAP/usr/local/bin /usr/local/man -MANPATH_MAP/usr/X11R6/bin /usr/X11R6/man # # set man locales, if needed # ___ 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: Version nomenclature [was RELENG_7 to 8]
On Sat, 15 Aug 2009 01:48:27 -0400 grarpamp wrote: > Wanted to put in a suggestion. Users are constantly confused and > asking questions about the FreeBSD version naming scheme, somehow > not quite picking it up right, which is which, where to use it, > etc. > > And though I know what it is, it still seems silly to me. Because > we've got logical pointers _loosely_ correlating to formal repo tag > and branch names. Worst case I've seen was when FreeBSD had 4, 5, > 6 all in flux at once. STABLE and CURRENT could only point to two > things and there were about 10 potential tags involved. > > Basically, I'm proposing FreeBSD should relegate the terms STABLE > and CURRENT out to the marketing portion of the web team. You > can't check them out of any repo as tags, 4 and 5 were 'stable' when > 6 was 'current' and so on. > > CURRENT means nothing more than cvs HEAD or svn trunk or git . > So use those terms instead of leading people think they can check > out 'CURRENT' or that it has some magical command line, config file > or source properties. website: 'The latest snapshots from our > FreeBSD-STABLE and FreeBSD-CURRENT branches are also available'... > checking out those branch names gets you HEAD. There are references > to 7-STABLE, 8-CURRENT and parhaps other bastardizations on a theme > :-) in the handbook that are not valid tags. > > STABLE is pretty much the same way, only more confusing if more > than one thing is 'stable'. Back in the 4/5/6 days it could have > referred to any number of branches. And on the main page, we now > have more buzzwords... 'production' and 'legacy'. In fact, I'd > venture that the proper place for such words, > CURRENT/STABLE/production/legacy, is only on the release/download/support > related pages of the website, with little '->'s to the actual tag > they imply. More importanly, with descriptions that say something > like which trains are developed/supported when, for how long. ie: > why the deserve such words to be applied to them. > > Anyone who has a need to refer to CURRENT/STABLE is obviously getting > beyond the release iso's and into the cvs/svn/git level of things. > So just use the right terms then. Encourage people to use proper > tags and for reporting bugs and things. They could probably make it > into uname somehow. > > RELENG_x_y_RELEASE > RELENG_x_y [date/serial] > RELENG_x [date/serial] > HEAD/trunk [date/serial] > > uname: '7.2-STABLE #0 ' isn't quite the same solid > reference as RELENG_7 as of yesterdays code. Which is what it is, > not the zero-eth 7.2 errata/security/stability commit. > > And maybe figure out a way that each commit bumps a serial counter > in UPDATING or some stampfile or uname so people can report the > serial. Or maybe use the git crypto hash thing. FreeBSD needs a > crypto hash reference inside the primary source tree anyways, not > just on the n steps removed iso's. > > I dunno, just seen year after year of these questions on the lists :) > Thought I'd put at least something out there. Not meant to be a > bikeshed or anything. More like something to be addressed by doc > project or whatever. > Nice document. I believe a lot of people get confused by these situations due to a matter of not using CVS, SVN, etc... etc... and have never heard of tags and such before. While more people have heard of and used these in their own environment at one point and are not used to the scheme that FreeBSD uses. While at some point everyone should come across http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html not everyone has been pointed to it for reference. I feel this document states these very clearly and besides what else are you going to call the development trunk/tree for FreeBSD-STABLE & FreeBSD-CURRENT ? call them both trunk ?. This is really based upon a well defined method of development that is fairly easy to understand if pointed in the right direction. A key factor in the "what is RELENG_X" type of situation is a "Am I missing something ?, What branch am I running again ?, What branch should I pick ?" and a good answer to that is right in the handbook telling yo u what these are all about. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: USB mouse not detected on boot of 7-STABLE
On Thu, 13 Aug 2009 13:16:12 -0700 "Kevin Oberman" wrote: > > Date: Thu, 13 Aug 2009 14:32:48 -0500 > > From: "Paul A. Procacci" > > Sender: owner-freebsd-sta...@freebsd.org > > > > I had the exact same problem. Not only did my mouse not work on > > boot-up, neither did my usb cable connecting my machine to my modem. > > The only solution that I tried was upgrading to 8, and presto, worked fine. > > 8.0 has an all new USB stack (thank HPS and a host of others) and it > ROCKS! Hardware that simply would not work on the old stack is operating > flawlessly on 8.0-BETA2. > > One note if you want to try 8.0. You will probably need to update all of > your ports to avoid library version mis-matches. Most notably, you need > to rebuild any port that uses libusb and it is now a standard system > library. Ports linked against the old ports libusb will not work after > the upgrade. > > I suggest upgrading to 8.0, deleting libusb, and then doing a > "portupgrade -fa" (or the portmaster equivalent). > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: ober...@es.netPhone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Another workaround may be upgrading to 8.0-* and using sysutils/libchk to parse through all your binaries and libs for discrepancies using script(1) to log the output so you have a reference to look back to. If all else fails you can always resort to the method above if your confidence is not very high on this method. And you can always second guess a port and then reinstall it when or if it gives you problems. ( /usr/bin/script /root/libchk_output /usr/local/sbin/libchk ) This process could actually take much more time and intervention than what is actually needed on some minimal systems so I will let you be the judge for your self on whether this may be right for you. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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"
