Re: Problems installing JDK 1.5
Juergen Nickelsen [EMAIL PROTECTED] writes: On Tue, Feb 27, 2007 at 11:22:44AM -0500, Sam Baskinger wrote: I'm assuming that you installed linux compatibility and then the linux-jdk 1.4? I failed to do that and saw a very similar error a while back. :) That may well be the case. I assumed the port installed it as a dependency, but I didn't really look close. Thanks for the hint! I'll report back later. It was indeed the Linux compatibility bits missing [1], including, of course, the linprocfs. Why this caused syntax errors while compiling Java code is beyond me, though. Thanks for the help! -- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in. We're computer professionals. We cause accidents.-- Nathaniel Borenstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems installing JDK 1.5
Dan Nelson [EMAIL PROTECTED] writes: You could also install the native diablo-jdk15 port instead of a Linux one. I was installing the native port /usr/ports/java/jdk15, only it needs the Linux JDK 1.4.2 to compile the Java sources. But indeed I was ignorant of the diablo port. What is the relation between these two ports anyway? I do not really get the difference, in spite of http://www.freebsdfoundation.org/downloads/java.shtml. -- I object to doing things that computers can do.-- Olin Shivers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixit cd for AMD64 on 6.2-RELEASE problem?
Steven Hartland wrote: I'm currently trying to use the Fixit cd on AMD64 ( 6.2 ) and it appears it has issues. When trying to fsck a disk it reports: fsck: exec fsck_4.2bsd for in /sbin:/usr/sbin: No such file or directory When looking on the mounted volumes for fsck_4.2bsd its located under: /dist/rescue/fsck_4.2bsd /dist/sbin/fsck_4.2bsd Surely /dist/sbin and /dist/usr/sbin should be in the PATH by default? Also it seems that fsck uses a hardcoded search path so setting PATH is not good enough, I had to create a symlink it into /sbin. With fsck being one of the common things people do with fixit would be nice if it just worked. P.S. Not sure if this is limited to AMD64, I suspect not but thats what I was working on. Sometime back I needed the fixit CD and hit various problems like this (generated a 1/2 dozen items on my TODO list not all of which have been crossed off yet). This stuff gets precious little testing and could use a champion to help improve it. Seems like a chore most anyone could help with... Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
Steven Hartland wrote: I've been repartitioning some of our machines here and found that using the following method sysinstall creates corrupt filesystems. 1. Boot a machine using an nfs mounted /usr 2. Run: sysctl kern.geom.debugflags=16 to enable writing to the disk mbr 3. run sysinstall, Customise - Label 4. Delete the /usr partition e.g. /dev/da0s1f 5. Create two partitions from the space left as ufs with mount points /usr and /data 6. Write the changes. Now two strange things happen: 1. /usr ends up mounted twice once from nfs and once from the new ufs. This requires umount -f /dev/da0s1f to correct but doesnt always work properly requiring a reboot to restore system functionality. 2. The FS on both partitions is totally corrupt even fsck cant repair them, even after a reboot. So the question is why would sysinstall create two corrupt FS's with this procedure? Fixing is trivial just rerun the newfs commands and all is good but its really odd that they should be corrupt in the first place and caught me out big time when I first did this as I had restored a full dump back onto /usr and rebooted only for it to blow up horribly as the fs was so badly corrupted. There's a debug flag you can turn on somewhere in the sysinstall menus. It may help diagnose what sysinstall is doing wrong by checking the log msgs. I find sysinstall is best diagnosed inside qemu or vmware so you destructively operate on disk images w/o hosing a real system. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
Hi, [/usr/local/sbin/clamd] libpthread.so.2 libthr.so.2 libpthread.so libthr.so libc_r.so.6 libpthread.so.2 Correct, just delete the last line. I forgot to delete the only entry. The right side of that last line should probably refer to libthr.so.2. AFAICS, what you have there makes no sense. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixit cd for AMD64 on 6.2-RELEASE problem?
Sam Leffler wrote: Sometime back I needed the fixit CD and hit various problems like this (generated a 1/2 dozen items on my TODO list not all of which have been crossed off yet). This stuff gets precious little testing and could use a champion to help improve it. Seems like a chore most anyone could help with... Im not a committer but know by why around in FreeBSD and in code for the most part, so I'd be willing to do what I could to push this forward. If thats of help let me know what you want doing and I'll see what I can do. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apache13/MoinMoin/Python vs PATH? What changed?
On Thu, Mar 01, 2007 at 02:05:14PM -0500, Daniel Eischen wrote: What is the approved fix for this problem? Setting a PATH that includes /usr/local/bin in /usr/local/etc/rc.d/apache.sh? Or the shebang patch to the python script itself, that I have already made? Has anyone answered this yet? I do not know myself. Nope. All silence. Ports gurus? -- Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
Hi, Anybody tried this additionally in /etc/libmap.conf ? [/usr/local/lib/libclamav.so.1] libpthread.so.2 libthr.so.2 clamav-0.90_2 reduced CPU consumption for me on 6.2-Stable since I added the two sections in libmap.conf -Carlos 2007/3/1, Doug Barton [EMAIL PROTECTED]: Martin Blapp wrote: Hi, Clamd is currently broken with libpthread for some threading-reason. You definitly need to use libthr (which is still CPU hungry, but works better). /etc/libmap.conf [/usr/local/sbin/clamd] libpthread.so.2 libthr.so.2 libpthread.so libthr.so libc_r.so.6 libpthread.so.2 The right side of that last line should probably refer to libthr.so.2. AFAICS, what you have there makes no sense. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with portupgrade
Phillip Ledger wrote: i have been trying to get portupgrade working, however everything i try to run it im getting an error with the portsdb. now i have tryed to rebuild it as requested initaly by portupgrade but im still getting an error portupgrade -aRr [missing key: categories] [Updating the portsdb format:bdb_btree in /var/tmp ... - 16413 port entries found .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000 . done] missing key: categories: Cannot read the portsdb! /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:548:in `open_db': database file error (PortsDB::DBError) from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:702:in `port' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:890:in `all_depends_list' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:809:in `tsort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `each' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `tsort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:823:in `sort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:827:in `sort_build!' from /usr/local/sbin/portupgrade:721:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:755:in `initialize' from /usr/local/sbin/portupgrade:220:in `new' from /usr/local/sbin/portupgrade:220:in `main' from /usr/local/sbin/portupgrade:2084 any idea whats causeing the issue or how to fix it? Try removing /usr/ports/INDEX-6.db and running portsdb -u, which should rebuild it from your existing /usr/ports/INDEX-6 file. (if you're using FreeBSD 5 it would be INDEX-5 above). -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SATA: AHCI controller reset failure - After Upgrade
Hi, Good morning, my name is Rômulo Lima, I had a problem when make an upgrade in my Freebsd Server from version 6.1 to 6.2. Before upgrade my SATA disc controller was working normally: atapci1: AcerLabs M5287 SATA150 controller port 0xec00-0xec0f,0xe480-0xe487,0xe400-0xe40f,0xe080-0xe087,0xe000-0xe01f mem 0xd800-0xdbff irq 21 at device 31.1 on pci0 ad4: 78167MB Maxtor 6Y080M0 YAR51HW0 at ata2-master SATA150 But after upgrade I got the following error, and my SATA disc stops, after that I proceeded with a downgrade and may Server work fine again. atapci1: AHCI controller reset failure device_attach: atapci1 attach returned 6 I search a solution on some mail lists, but I still have no solution to this problem, if anyone can help me I will thank very much! Best Regards, Rômulo Lima Tech Manager Wavenet www.wavenet.com.br (71) 3177-6150 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
Sam Leffler wrote: There's a debug flag you can turn on somewhere in the sysinstall menus. It may help diagnose what sysinstall is doing wrong by checking the log msgs. I find sysinstall is best diagnosed inside qemu or vmware so you destructively operate on disk images w/o hosing a real system. I've got some new machines on order that will need installing so it will be easy to have a play on them. I'll have a dig and let you know what I find. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/01/07 17:42, Steven Hartland wrote: I've been repartitioning some of our machines here and found that using the following method sysinstall creates corrupt filesystems. 1. Boot a machine using an nfs mounted /usr 2. Run: sysctl kern.geom.debugflags=16 to enable writing to the disk mbr 3. run sysinstall, Customise - Label 4. Delete the /usr partition e.g. /dev/da0s1f 5. Create two partitions from the space left as ufs with mount points /usr and /data 6. Write the changes. Now two strange things happen: 1. /usr ends up mounted twice once from nfs and once from the new ufs. This requires umount -f /dev/da0s1f to correct but doesnt always work properly requiring a reboot to restore system functionality. 2. The FS on both partitions is totally corrupt even fsck cant repair them, even after a reboot. So the question is why would sysinstall create two corrupt FS's with this procedure? Fixing is trivial just rerun the newfs commands and all is good but its really odd that they should be corrupt in the first place and caught me out big time when I first did this as I had restored a full dump back onto /usr and rebooted only for it to blow up horribly as the fs was so badly corrupted. Steve I don't know about the fs corruption, but the double mounts is something you asked it to do (maybe unknowingly). When you added that partition, one of the options is to mount it. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
Eric Anderson wrote: I don't know about the fs corruption, but the double mounts is something you asked it to do (maybe unknowingly). When you added that partition, one of the options is to mount it. Clearly an easy work around in that case then but personally I would expect a mount to a directory already in use by another mount point to fail. Taking even further a mount to a directory that is not actually empty should fail. IIRC this is how solaris behaves but its been a while. Checking for an empty target directory certainly makes sence to me is there some case where it would be desirable to allow this to happen? If so maybe a force flag should created without which a mount to a none empty dir would fail. Either way allowing multiple mounts to the same location is bound to cause all manor of confusion and should be prevented. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/02/07 07:46, Steven Hartland wrote: Eric Anderson wrote: I don't know about the fs corruption, but the double mounts is something you asked it to do (maybe unknowingly). When you added that partition, one of the options is to mount it. Clearly an easy work around in that case then but personally I would expect a mount to a directory already in use by another mount point to fail. Taking even further a mount to a directory that is not actually empty should fail. IIRC this is how solaris behaves but its been a while. Checking for an empty target directory certainly makes sence to me is there some case where it would be desirable to allow this to happen? If so maybe a force flag should created without which a mount to a none empty dir would fail. Either way allowing multiple mounts to the same location is bound to cause all manor of confusion and should be prevented. Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
Eric Anderson wrote: On 03/02/07 07:46, Steven Hartland wrote: Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Interesting if that's a valid thing to do why does everything break when its done? Is it ment to be doing a union hence you get the combined contents of both? If so its not working correctly in this case :( Can you provide me with more info on how this is supposed to work eric please. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
On Fri, Mar 02, 2007 at 08:11:52AM -0600, Eric Anderson wrote: Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Are we absolutely sure overlaying NFS + local UFS filesystems like this is the cause of the filesystem corruption? If Eric's doing it and it's working fine, I'm left wondering if there's maybe sysinstall isn't handling something right. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/02/07 08:37, Steven Hartland wrote: Eric Anderson wrote: On 03/02/07 07:46, Steven Hartland wrote: Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Interesting if that's a valid thing to do why does everything break when its done? Is it ment to be doing a union hence you get the combined contents of both? If so its not working correctly in this case :( Can you provide me with more info on how this is supposed to work eric please. No, it won't do a union unless you use union. Things break because you mounted an empty /usr on top of a working /usr. That just breaks things, because you probably need binaries in /usr. The OS doesn't know whether you want to mount an empty fs on a populated one, or what. It does exactly what you ask it to do, and in this case, it was a bad thing. Think of a thin client that has just enough stuff in /usr to make it boot and run a few tools. Then, depending on a startup option, it mounts a more populated /usr from NFS (or even a local disk, doesn't really matter) over the previous /usr. The fact is this: you made a new partition, called it /usr, and told sysinstall to mount it. It did. That happened to be a problem for you, which I could imagine it would be. Now, I'm not claiming this is the cause of your file system corruption issues. I'm just saying the duplicate mount is not a bug, it's a feature. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/02/07 08:44, Jeremy Chadwick wrote: On Fri, Mar 02, 2007 at 08:11:52AM -0600, Eric Anderson wrote: Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Are we absolutely sure overlaying NFS + local UFS filesystems like this is the cause of the filesystem corruption? If Eric's doing it and it's working fine, I'm left wondering if there's maybe sysinstall isn't handling something right. No no no - I don't think there's anything wrong with that at all, and I don't think the two are related. I was merely trying to point out that the doubling of mounts is normal, expected, and a feature. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Mount on non-empty directories (Was: sysinstall creates corrupt filesystems after repartitioning)
In [EMAIL PROTECTED], Steven Hartland [EMAIL PROTECTED] typed: Eric Anderson wrote: I don't know about the fs corruption, but the double mounts is something you asked it to do (maybe unknowingly). When you added that partition, one of the options is to mount it. Clearly an easy work around in that case then but personally I would expect a mount to a directory already in use by another mount point to fail. Taking even further a mount to a directory that is not actually empty should fail. IIRC this is how solaris behaves but its been a while. Yeah, there are some system that have that annoying behavior. I've cursed at them before. Being able to create a skeleton for some mounted file system on the root is a useful thing, and I've done it in a number of cases. Mount has an option (union) specifically designed for such cases. Further, we have at least one file system (unionfs) that is explicitly designed to be mounted on top of non-empty directories that people are actively using and developing. Either way allowing multiple mounts to the same location is bound to cause all manor of confusion and should be prevented. This is just a special case of mounting on a non-empty directory. It should work right. The last mounted file system is the one you get (unless you're using a file system that's designed to behave another way). If you unmount the directory, the last mounted device is unmounted. As a general rule, deciding that something is useless and dangerous and removing it isn't the Unix way of doing things. Just because you can't see a use for something doesn't mean that no one else will. That's true even if you wrote the code. Someone doing something with your program you never thought of is a sign that you developed a generally useful tool. As for dangerous, Unix users - especially root, and mount is restricted to root by default - are assumed to know what they're doing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
Jeremy Chadwick wrote: On Fri, Mar 02, 2007 at 08:11:52AM -0600, Eric Anderson wrote: Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Are we absolutely sure overlaying NFS + local UFS filesystems like this is the cause of the filesystem corruption? If Eric's doing it and it's working fine, I'm left wondering if there's maybe sysinstall isn't handling something right. I've rerun the test just to confirm but there are definitely two seperate issues here: 1. The ufs created by sysinstall after a repartition is corrupt. This is totally unrelated to the overlay of /usr as both /usr and /data ( which didnt previously exist ) where corrupted. 2. Once the blank /usr was mounted over the working nfs /usr apps under /usr couldnt be run e.g. vim gave me no such file.. After unmounting the ufs /usr using umount -f /dev/da0s1f, without -f it gave a error due to use even know nothing was in use on it, the functionaility returned. Now this could be related to the corruption of the underlying ufs partition. If this is the case then solving #1 will also fix #2 Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
Anybody tested today released clamav-0.90.1 ?? On 3/2/07, Carlos Horowicz [EMAIL PROTECTED] wrote: Hi, Anybody tried this additionally in /etc/libmap.conf ? [/usr/local/lib/libclamav.so.1] libpthread.so.2 libthr.so.2 clamav-0.90_2 reduced CPU consumption for me on 6.2-Stable since I added the two sections in libmap.conf -Carlos 2007/3/1, Doug Barton [EMAIL PROTECTED]: Martin Blapp wrote: Hi, Clamd is currently broken with libpthread for some threading-reason. You definitly need to use libthr (which is still CPU hungry, but works better). /etc/libmap.conf [/usr/local/sbin/clamd] libpthread.so.2 libthr.so.2 libpthread.so libthr.so libc_r.so.6 libpthread.so.2 The right side of that last line should probably refer to libthr.so.2. AFAICS, what you have there makes no sense. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mount on non-empty directories (Was: sysinstall creates corruptfilesystems after repartitioning)
Mike Meyer wrote: In [EMAIL PROTECTED], Steven Hartland This is just a special case of mounting on a non-empty directory. It should work right. The last mounted file system is the one you get (unless you're using a file system that's designed to behave another way). If you unmount the directory, the last mounted device is unmounted. This makes sence but is not what happens hence the confusion. If the last mounted FS is the one you get that makes sence but in this case thats not what I observed. As a general rule, deciding that something is useless and dangerous and removing it isn't the Unix way of doing things. Just because you can't see a use for something doesn't mean that no one else will. That's true even if you wrote the code. Someone doing something with your program you never thought of is a sign that you developed a generally useful tool. As for dangerous, Unix users - especially root, and mount is restricted to root by default - are assumed to know what they're doing. Appreciated but the issue I'm trying to understand is that the result didn't make any sence i.e. ls returned the files but trying to run them didnt work. Result my head started to spin a bit :P As mentioned this seemed to easily resolved by force unmounting the second device but as has been explained this has a clear use for which I was unaware but I'd still like to understand by I saw what I did i.e. ls displayed the files yet running vim didnt. I'm going to investigate this more in an effort to determine why I got these results and report back. Thanks for everyone's feedback so far most appreciated. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/02/07 09:37, Steven Hartland wrote: Jeremy Chadwick wrote: On Fri, Mar 02, 2007 at 08:11:52AM -0600, Eric Anderson wrote: Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Are we absolutely sure overlaying NFS + local UFS filesystems like this is the cause of the filesystem corruption? If Eric's doing it and it's working fine, I'm left wondering if there's maybe sysinstall isn't handling something right. I've rerun the test just to confirm but there are definitely two seperate issues here: 1. The ufs created by sysinstall after a repartition is corrupt. This is totally unrelated to the overlay of /usr as both /usr and /data ( which didnt previously exist ) where corrupted. 2. Once the blank /usr was mounted over the working nfs /usr apps under /usr couldnt be run e.g. vim gave me no such file.. After unmounting the ufs /usr using umount -f /dev/da0s1f, without -f it gave a error due to use even know nothing was in use on it, the functionaility returned. Now this could be related to the corruption of the underlying ufs partition. If this is the case then solving #1 will also fix #2 So try the same test, with *only* the data partition, without messing with the /usr stuff.. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mount on non-empty directories (Was: sysinstall creates corruptfilesystems after repartitioning)
On 03/02/07 09:56, Steven Hartland wrote: Mike Meyer wrote: In [EMAIL PROTECTED], Steven Hartland This is just a special case of mounting on a non-empty directory. It should work right. The last mounted file system is the one you get (unless you're using a file system that's designed to behave another way). If you unmount the directory, the last mounted device is unmounted. This makes sence but is not what happens hence the confusion. If the last mounted FS is the one you get that makes sence but in this case thats not what I observed. Are you sure? In your last email, you described the above interaction exactly (you had an NFS mounted /usr, then you made a new empty /usr, and it mounted it on top, then you couldn't execute things in /usr anymore (vim was your example), then you unmounted the last mounted fs (the empty one), and your vim was accessible again.. ? As a general rule, deciding that something is useless and dangerous and removing it isn't the Unix way of doing things. Just because you can't see a use for something doesn't mean that no one else will. That's true even if you wrote the code. Someone doing something with your program you never thought of is a sign that you developed a generally useful tool. As for dangerous, Unix users - especially root, and mount is restricted to root by default - are assumed to know what they're doing. Appreciated but the issue I'm trying to understand is that the result didn't make any sence i.e. ls returned the files but trying to run them didnt work. Result my head started to spin a bit :P As mentioned this seemed to easily resolved by force unmounting the second device but as has been explained this has a clear use for which I was unaware but I'd still like to understand by I saw what I did i.e. ls displayed the files yet running vim didnt. I'm going to investigate this more in an effort to determine why I got these results and report back. Thanks for everyone's feedback so far most appreciated. Ok, at this point, you need to send df, mount, and your ls output between each step. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
In [EMAIL PROTECTED], Steven Hartland [EMAIL PROTECTED] typed: 2. Once the blank /usr was mounted over the working nfs /usr apps under /usr couldnt be run e.g. vim gave me no such file.. This is correct behavior. If you want to see the files underneath a mounted file system, you need to use the union option on the mount. sysinstall doesn't expect you to have live file systems mounted, so doesn't do that. After unmounting the ufs /usr using umount -f /dev/da0s1f, without -f it gave a error due to use even know nothing was in use on it, the functionaility returned. Are you positive nothing was in use on it? In particular, could sysinstall have opened something on it? In any case, unmounting the file system causeing that functionality to return is expected. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
On Fri, Mar 02, 2007 at 03:37:21PM -, Steven Hartland wrote: I've rerun the test just to confirm but there are definitely two seperate issues here: 1. The ufs created by sysinstall after a repartition is corrupt. This is totally unrelated to the overlay of /usr as both /usr and /data ( which didnt previously exist ) where corrupted. Pardon my ignorance, but can you give me a step-by-step on how to reproduce this? I have a couple VMware FreeBSD sessions up and want to see if I can reproduce it there. I also have an actual FreeBSD testbox at home which I can format and reinstall. (I'm not denying the problem exists, I just want to reproduce it, and I think those steps would be useful to those who can fix the problem too.) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mount on non-empty directories (Was: sysinstall creates corruptfilesystems after repartitioning)
In [EMAIL PROTECTED], Steven Hartland [EMAIL PROTECTED] typed: Mike Meyer wrote: In [EMAIL PROTECTED], Steven Hartland As a general rule, deciding that something is useless and dangerous and removing it isn't the Unix way of doing things. Just because you can't see a use for something doesn't mean that no one else will. That's true even if you wrote the code. Someone doing something with your program you never thought of is a sign that you developed a generally useful tool. As for dangerous, Unix users - especially root, and mount is restricted to root by default - are assumed to know what they're doing. Appreciated but the issue I'm trying to understand is that the result didn't make any sence i.e. ls returned the files but trying to run them didnt work. You can make that happen: # cd /usr # mount /dev/blank /usr # vim vim: not found # ls /usr/bin ls: /usr/bin: No such file or directory # ls binThis will show the contents of /usr/bin before the mount, because it looks in ./bin, and . is on the original /usr, not the new one. # bin/vim will find bin/vim # pwd This is both true and not true. The current /usr/bindirectory is /usr/bin, but you won't get there if you cd to /usr/bin. Result my head started to spin a bit :P As mentioned this seemed to easily resolved by force unmounting the second device but as has been explained this has a clear use for which I was unaware but I'd still like to understand by I saw what I did i.e. ls displayed the files yet running vim didnt. Well, without knowing exactly what you did, we can't say how you got those results. But I suspect something like the above. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
Eric Anderson wrote: So try the same test, with *only* the data partition, without messing with the /usr stuff.. Will do, will be a little while need to wait for some new machines to come in before I can test again. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mount on non-empty directories (Was: sysinstall createscorruptfilesystems after repartitioning)
Mike Meyer wrote: You can make that happen: # cd /usr # mount /dev/blank /usr # vim vim: not found # ls /usr/bin ls: /usr/bin: No such file or directory # ls bin This will show the contents of /usr/bin before the mount, because it looks in ./bin, and . is on the original /usr, not the new one. # bin/vim will find bin/vim # pwd This is both true and not true. The current /usr/bin directory is /usr/bin, but you won't get there if you cd to /usr/bin. Yes indeed this was what happend I was in /usr before I started sysinstall, did the repartition, quit and tried to run vim to edit /etc/fstab. This failed but when I did a straight ls -l ( which was still in /usr ) everything appeared normal. So the behaviour is explained by the fact that the shell still had the handle to the original /usr before the second mount and as such presented the nfs mounts details. Thanks guys for spending the time to explain that. All is clear on this front now just need to determine what is causing the FS corruption now, for which I need to wait for some machines to be delivered so I can try doing the test with just /data hence avoiding any interaction with /usr. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
Jeremy Chadwick wrote: Pardon my ignorance, but can you give me a step-by-step on how to reproduce this? I have a couple VMware FreeBSD sessions up and want to see if I can reproduce it there. I also have an actual FreeBSD testbox at home which I can format and reinstall. (I'm not denying the problem exists, I just want to reproduce it, and I think those steps would be useful to those who can fix the problem too.) No problem if you have the resources / time to test this now thats great. Here's the steps I used, if you have any questions just shout: 1. Boot a normal 6.2 install 2. dump /usr to remote location 3. restore said dump to a empty directory on the remote machine 4. share this directory over nfs to the test machine 5. edit /etc/fstab to use the nfs /usr instead of the ufs /usr 6. reboot 7. Enable mbr changes on live fs: sysctl kern.geom.debugflags=16 8. run sysinstall 8.1 delete /dev/(da|ad)0s1f ( the /usr partition ) 8.2 create a smaller /usr in the space cleared 8.3 create /data with the remaining space 8.4 Write the changes 9. quit sysinstall 10. umount -f /usr ( to restore the nfs version ) 11. umount /data 12. fsck /dev/(da|ad)0s1(f|g) both will be corrupt. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA: AHCI controller reset failure - After Upgrade
On Friday 02 March 2007 16:37, Rômulo Lima wrote:
Hi,
Good morning, my name is Rômulo Lima, I had a problem when make an upgrade
in my Freebsd Server from version 6.1 to 6.2. Before upgrade my SATA disc
controller was working normally:
atapci1: AcerLabs M5287 SATA150 controller port
0xec00-0xec0f,0xe480-0xe487,0xe400-0xe40f,0xe080-0xe087,0xe000-0xe01f mem
0xd800-0xdbff irq 21 at device 31.1 on pci0 ad4: 78167MB Maxtor
6Y080M0 YAR51HW0 at ata2-master SATA150
But after upgrade I got the following error, and my SATA disc stops, after
that I proceeded with a downgrade and may Server work fine again.
atapci1: AHCI controller reset failure
device_attach: atapci1 attach returned 6
This regression was discussed recently, see
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=71434+0+current/freebsd-stable
The problem seems to be the fact that BIOS indicates AHCI availability
when in reality it's not available.
Do you have options in BIOS for selecting in what mode SATA works, usually
the selection is something like: raid, non-raid, ahci.
If there are different modes available then does selecting others than the
current one make any difference ?
If it doesn't help then you might try the following patch as a workaround, it
will disable any attempts to try AHCI on other ALI chipsets than 5288, since
that's the only one I have personally used AHCI on and can be fairly certain
that it really works there.
Of course this is only a _workaround_ until Søren or someone else figures out
how to detect AHCI on ALi chipsets more reliably.
diff -ru sys/dev/ata_orig/ata-chipset.c sys/dev/ata/ata-chipset.c
--- sys/dev/ata_orig/ata-chipset.c Mon Feb 12 01:46:45 2007
+++ sys/dev/ata/ata-chipset.c Fri Mar 2 18:47:16 2007
@@ -952,7 +952,7 @@
struct ata_chip_id *idx;
static struct ata_chip_id ids[] =
{{ ATA_ALI_5289, 0x00, 2, ALISATA, ATA_SA150, M5289 },
- { ATA_ALI_5288, 0x00, 4, ALISATA, ATA_SA300, M5288 },
+ { ATA_ALI_5288, 0x00, 4, ALIAHCI, ATA_SA300, M5288 },
{ ATA_ALI_5287, 0x00, 4, ALISATA, ATA_SA150, M5287 },
{ ATA_ALI_5281, 0x00, 2, ALISATA, ATA_SA150, M5281 },
{ ATA_ALI_5229, 0xc5, 0, ALINEW, ATA_UDMA6, M5229 },
@@ -984,6 +984,7 @@
switch (ctlr-chip-cfg2) {
case ALISATA:
+case ALIAHCI:
ctlr-channels = ctlr-chip-cfg1;
ctlr-allocate = ata_ali_sata_allocate;
ctlr-setmode = ata_sata_setmode;
@@ -991,8 +992,9 @@
/* if we have a memory resource we can likely do AHCI */
ctlr-r_type2 = SYS_RES_MEMORY;
ctlr-r_rid2 = PCIR_BAR(5);
- if ((ctlr-r_res2 = bus_alloc_resource_any(dev, ctlr-r_type2,
- ctlr-r_rid2, RF_ACTIVE)))
+ if (ctlr-chip-cfg2 == ALIAHCI
+ (ctlr-r_res2 = bus_alloc_resource_any(dev, ctlr-r_type2,
+ctlr-r_rid2, RF_ACTIVE)))
return ata_ahci_chipinit(dev);
/* enable PCI interrupt */
diff -ru sys/dev/ata_orig/ata-pci.h sys/dev/ata/ata-pci.h
--- sys/dev/ata_orig/ata-pci.h Mon Feb 12 01:46:45 2007
+++ sys/dev/ata/ata-pci.h Fri Mar 2 18:34:23 2007
@@ -360,6 +360,7 @@
#define ALIOLD 0x01
#define ALINEW 0x02
#define ALISATA 0x04
+#define ALIAHCI0x08
#define HPT366 0
#define HPT370 1
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with portupgrade
Michael Proto wrote: Phillip Ledger wrote: i have been trying to get portupgrade working, however everything i try to run it im getting an error with the portsdb. now i have tryed to rebuild it as requested initaly by portupgrade but im still getting an error portupgrade -aRr [missing key: categories] [Updating the portsdb format:bdb_btree in /var/tmp ... - 16413 port entries found .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000 . done] missing key: categories: Cannot read the portsdb! /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:548:in `open_db': database file error (PortsDB::DBError) from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:702:in `port' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:890:in `all_depends_list' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:809:in `tsort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `each' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `tsort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:823:in `sort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:827:in `sort_build!' from /usr/local/sbin/portupgrade:721:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:755:in `initialize' from /usr/local/sbin/portupgrade:220:in `new' from /usr/local/sbin/portupgrade:220:in `main' from /usr/local/sbin/portupgrade:2084 any idea whats causeing the issue or how to fix it? Try removing /usr/ports/INDEX-6.db and running portsdb -u, which should rebuild it from your existing /usr/ports/INDEX-6 file. (if you're using FreeBSD 5 it would be INDEX-5 above). If it does not help, you should update portupgrade to the last version and rebuild the database again. -- Dixi. Sem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with portupgrade
On 3/2/07, Michael Proto [EMAIL PROTECTED] wrote: Phillip Ledger wrote: i have been trying to get portupgrade working, however everything i try to run it im getting an error with the portsdb. now i have tryed to rebuild it as requested initaly by portupgrade but im still getting an error portupgrade -aRr [missing key: categories] [Updating the portsdb format:bdb_btree in /var/tmp ... - 16413 port entries found .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000 . done] missing key: categories: Cannot read the portsdb! /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:548:in `open_db': database file error (PortsDB::DBError) from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:702:in `port' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:890:in `all_depends_list' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:809:in `tsort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `each' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `tsort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:823:in `sort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:827:in `sort_build!' from /usr/local/sbin/portupgrade:721:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:755:in `initialize' from /usr/local/sbin/portupgrade:220:in `new' from /usr/local/sbin/portupgrade:220:in `main' from /usr/local/sbin/portupgrade:2084 any idea whats causeing the issue or how to fix it? Try removing /usr/ports/INDEX-6.db and running portsdb -u, which should rebuild it from your existing /usr/ports/INDEX-6 file. (if you're using FreeBSD 5 it would be INDEX-5 above). -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] From /usr/ports/UPDATING: 20070102: AFFECTS: users of sysutils/portupgrade AUTHOR: [EMAIL PROTECTED] If you have a problem with upgrading the tools from version 2.2.1 and less, remove the package with pkg_delete portupgrade\* command and reinstall it from scratch. Remove /usr/ports/INDEX*.db and run portsdb -u. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
On Fri, Mar 02, 2007 at 05:00:24PM -, Steven Hartland wrote: No problem if you have the resources / time to test this now thats great. Here's the steps I used, if you have any questions just shout: 1. Boot a normal 6.2 install Done. Booted CD image #1, did a standard install, chose Minimal as the installation type. Also chose to install the FreeBSD boot manager and the like. 2. dump /usr to remote location Done. From the machine going to act as an NFS server, I did: icarus# ssh -c blowfish [EMAIL PROTECTED] /sbin/dump -0 -f- /usr | dd of=usr.dump bs=65536 DUMP: WARNING: should use -L when dumping live read-write filesystems! DUMP: Date of this level 0 dump: Fri Mar 2 12:49:29 2007 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/ad0s1f (/usr) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 106124 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 110621 tape blocks DUMP: finished in 35 seconds, throughput 3160 KBytes/sec DUMP: DUMP IS DONE 1+13937 records in 1+13937 records out 113274880 bytes transferred in 18.691292 secs (6060302 bytes/sec) icarus# ls -l usr.dump -rw-r--r-- 1 root wheel 113274880 Mar 2 12:55 usr.dump 3. restore said dump to a empty directory on the remote machine Done: icarus# restore -x -f usr.dump You have not read any tapes yet. If you are extracting just a few files, start with the last volume and work towards the first; restore can quickly skip tapes that have no further files to extract. Otherwise, begin with volume 1. Specify next volume #: 1 set owner/mode for '.'? [yn] n icarus# ls -l total 110750 drwxrwxr-x 2 root operator512 Mar 2 04:40 .snap drwxr-xr-x 2 root wheel 7168 Mar 2 04:40 bin drwxr-xr-x 2 root wheel 512 Mar 2 04:40 compat drwxr-xr-x 2 root wheel 512 Mar 2 04:40 games drwxr-xr-x 47 root wheel 4608 Mar 2 04:40 include drwxr-xr-x 4 root wheel 7168 Mar 2 04:40 lib drwxr-xr-x 5 root wheel 512 Mar 2 04:40 libdata drwxr-xr-x 5 root wheel 1536 Mar 2 04:40 libexec drwxr-xr-x 2 root wheel 512 Jan 11 23:38 local drwxr-xr-x 2 root wheel 512 Mar 2 04:40 obj drwxr-xr-x 2 root wheel 5120 Mar 2 04:40 sbin drwxr-xr-x 27 root wheel 512 Mar 2 04:40 share drwxr-xr-x 2 root wheel 512 Jan 11 23:38 src -rw-r--r-- 1 root wheel 113274880 Mar 2 12:55 usr.dump icarus# ls -ld . drwxr-xr-x 15 root wheel 512 Mar 2 12:58 . 4. share this directory over nfs to the test machine Done. You know the routine to get NFS to work... ;) My exports: /storage -alldirs -maproot=root -network 192.168.1.0 -mask 255.255.255.0 Verified to be working on test box via: mount -t nfs icarus.home.lan:/storage/nfs /mnt ls -l /mnt umount /mnt Worked OK. 5. edit /etc/fstab to use the nfs /usr instead of the ufs /usr Done. The test box's /etc/fstab now contains: icarus.home.lan:/storage/nfs /usr nfs rw 0 0 # old /usr, local to filesystem # /dev/ad0s1f /usrnfs rw 2 2 6. reboot Done. Rebooted test box. Box came up with an NFS mounted /usr: # df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 507630 36838430182 8%/ devfs1 1 0 100%/dev /dev/ad0s1e 50763012467008 0%/tmp /dev/ad0s1d1506190 234 1385462 0%/var icarus.home.lan:/storage/nfs 473015558 120242684 31493163028%/usr 7. Enable mbr changes on live fs: sysctl kern.geom.debugflags=16 Done. # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 - 16 8. run sysinstall 8.1 delete /dev/(da|ad)0s1f ( the /usr partition ) Done. Prior to deletion: ad0s1fnone 4645MB * 8.2 create a smaller /usr in the space cleared 8.3 create /data with the remaining space Done: ad0s1f/usr 3072MB UFS2+S Y ad0s1g/data1573MB UFS2+S Y 8.4 Write the changes Done. However, there were errors: . Message . .Unable to add /dev/ad0s1b as a swap device: Device busy . ..(100%)... . [ OK ] . .[ Press enter or space ].. . Message . .Error mounting /dev/ad0s1g on /data : No such file or directory . ..(100%)... . [ OK ] . .[ Press enter or space ].. 9. quit sysinstall Done. Did a df -k just before step 10, just to be
Re: Problem with portupgrade
Sergey Matveychuk wrote: Michael Proto wrote: Phillip Ledger wrote: i have been trying to get portupgrade working, however everything i try to run it im getting an error with the portsdb. now i have tryed to rebuild it as requested initaly by portupgrade but im still getting an error portupgrade -aRr [missing key: categories] [Updating the portsdb format:bdb_btree in /var/tmp ... - 16413 port entries found .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000 . done] missing key: categories: Cannot read the portsdb! /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:548:in `open_db': database file error (PortsDB::DBError) from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:702:in `port' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:890:in `all_depends_list' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:809:in `tsort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `each' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `tsort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:823:in `sort_build' from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:827:in `sort_build!' from /usr/local/sbin/portupgrade:721:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:755:in `initialize' from /usr/local/sbin/portupgrade:220:in `new' from /usr/local/sbin/portupgrade:220:in `main' from /usr/local/sbin/portupgrade:2084 any idea whats causeing the issue or how to fix it? Try removing /usr/ports/INDEX-6.db and running portsdb -u, which should rebuild it from your existing /usr/ports/INDEX-6 file. (if you're using FreeBSD 5 it would be INDEX-5 above). If it does not help, you should update portupgrade to the last version and rebuild the database again. Even after a complete reinstall of the toll and rebuildig the database its still giving the same error. anyumore ideas? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall creates corrupt filesystems after repartitioning
Jeremy Chadwick wrote: ... Is there something I'm missing? I can't see anything missing there from the reproduction steps. Was ad0s1g also ok? The slight differences I did here where the following but I cant seem them being significant: 1. dump -a0uL -C 32 -f /nfs/usr.dmp /usr 2. restore rf usr.dmp 3. fstab entry: /nfs/usr -maproot=root testbox Other differences which spring to mind: 1. machines where both using areca controllers on RAID6 arrays. 2. This was a real machine and not a VM One other thing of note when I first repaired this I booted from Install Disk #1 and used the same procedure for the sysinstall part from fixit and no corruption occured. As mentioned before I've got two more of these machines coming in over the next few weeks so I'll look at reproducing it on them. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some days, it doesn't pay to upgrade ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Based on the suggestion by someone on this list, I setup a screen session with top running, to watch things ... again, after 3 days, the server goes 'out of process' ... this time, of course, I could get in to look around and kill off processes ... from what I can tell, a process that all it does is: ping -c 1 host with a 300 sec timeout that runs once a minute started to 'run over top of' each other out of cron ... the host that it is pinging is on the same switch and has been running fine for 20 days now, and it wasn't until I did the last upgrade on teh server causing the problems that these problems started ... Coincidence? :) I'm going to fix the script so that it doesn't try to run over itself ... anyone konw of a problem with the fxp driver in 6-STABLE that might cause the ping to hang? - --On Thursday, March 01, 2007 09:51:13 +1100 Antony Mawer [EMAIL PROTECTED] wrote: On 27/02/2007 11:59 PM, Marc G. Fournier wrote: After 155 days of problem free uptime, I upgraded my 6-STABLE system the other day to the latest cvsup ... 3 days later, the whole thing hung solid with: Feb 27 04:32:49 mars uptimec: The server requested that we do a new login Feb 27 04:33:00 mars kernel: maxproc limit exceeded by uid 0, please see tuning(7) and login.conf(5). Feb 27 04:33:10 mars kernel: maxproc limit exceeded by uid 60, please see tuning(7) and login.conf(5). Stupid question: why isn't there some mechanism that prevents new processes from starting up, instead of locking up the whole server? I'm not asking for the evilness of Linux, where it arbitrarily kills off existing processes, but if maxproc is hit, why continue to try and start up new ones? What do you define as 'hung solid'? You are unable to get in via SSH? Or at a console via iLO/etc? I've seen this on some of our 6.0-RELEASE machines (along with maxpipekva exhausted errors), and you can't SSH in from that point... because sshd forks to handle the connection, and all available process slots are used up. I've thought about writing a background daemon to monitor the logs for signs of this (or even to just try and create a short-lived child process by fork()ing every 5 minutes or so), and dump information to disk then reboot the system when this occurs... it's a work-around for something that shouldn't happen, but it does anyway... once I'm able to identify _what_ is causing the build-up of processes, then I might be able to do something about killing them...!!! It's quite deceptive from an end-user point of view, because things like Apache that are already keep running, so all they see are strange bits and pieces that don't work... and as always, its one of those things that only happens on some clients machines, but never on any of our test machines... --Antony PS. I haven't disappeared off the face of the earth.. though close.. my fiance and I have been busy planning the wedding, and wound up buying a house at the same time..!! Will catch up shortly once I get a chance to come up for air!! - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFF6Ofd4QvfyHIvDvMRAmoqAJ9ka8ZQxq0Ciidyy4R60bTmYfxeggCeLz7i /De9C0Hmdqb22nErxhyUaZA= =Seo0 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with portupgrade
On 2007-Mar-03 10:12:53 +1100, Phillip Ledger [EMAIL PROTECTED] wrote: Even after a complete reinstall of the toll and rebuildig the database its still giving the same error. anyumore ideas? Exactly what have you re-installed? What versions of ruby* and portupgrade do you have? Have you compared your /usr/local/etc/pkgtools.conf with the sample version? -- Peter Jeremy pgp2ln9OhAsFT.pgp Description: PGP signature
Re: Some days, it doesn't pay to upgrade ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't know how critical this is, but I just thought about it ... this is my only system running gmirror ... everything seems fine according ot gmirror status, but maybe something iswron gthere I'm not seeing: Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device vm: provider mirror/vm destroyed. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device vm destroyed. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md2: provider mirror/md2 destroyed. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md2 destroyed. Mar 3 01:25:52 mars kernel: GEOM_STRIPE: Disk mirror/md2 removed from md0. Mar 3 01:25:52 mars kernel: GEOM_STRIPE: Device md0 removed. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md1: provider mirror/md1 destroyed. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md1 destroyed. Mar 3 01:25:52 mars kernel: GEOM_STRIPE: Disk mirror/md1 removed from md0. Mar 3 01:25:52 mars kernel: GEOM_STRIPE: Device md0 destroyed. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md1 created (id=2282154470). Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md1: provider da1 detected. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md1: provider da2 detected. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md1: provider da2 activated. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md1: provider da1 activated. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md1: provider mirror/md1 launched. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md2 created (id=3089402334). Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md2: provider da3 detected. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md2: provider da4 detected. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md2: provider da4 activated. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md2: provider da3 activated. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device md2: provider mirror/md2 launched. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device vm created (id=2175292049). Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device vm: provider da5 detected. Mar 3 01:25:52 mars kernel: GEOM_STRIPE: Device md0 created (id=1094782536). Mar 3 01:25:52 mars kernel: GEOM_STRIPE: Disk mirror/md1 attached to md0. Mar 3 01:25:52 mars kernel: GEOM_STRIPE: Disk mirror/md2 attached to md0. Mar 3 01:25:52 mars kernel: GEOM_STRIPE: Device md0 activated. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Force device vm start due to timeout. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device vm: provider da5 activated. Mar 3 01:25:52 mars kernel: GEOM_MIRROR: Device vm: provider mirror/vm launched. mirror/md1 COMPLETE da1 da2 mirror/md2 COMPLETE da3 da4 mirror/vm DEGRADED da5 I'm not using da5 right now, its just in there ... went with a RAID1+0 vs RAID5 configuration ... - --On Thursday, March 01, 2007 09:51:13 +1100 Antony Mawer [EMAIL PROTECTED] wrote: On 27/02/2007 11:59 PM, Marc G. Fournier wrote: After 155 days of problem free uptime, I upgraded my 6-STABLE system the other day to the latest cvsup ... 3 days later, the whole thing hung solid with: Feb 27 04:32:49 mars uptimec: The server requested that we do a new login Feb 27 04:33:00 mars kernel: maxproc limit exceeded by uid 0, please see tuning(7) and login.conf(5). Feb 27 04:33:10 mars kernel: maxproc limit exceeded by uid 60, please see tuning(7) and login.conf(5). Stupid question: why isn't there some mechanism that prevents new processes from starting up, instead of locking up the whole server? I'm not asking for the evilness of Linux, where it arbitrarily kills off existing processes, but if maxproc is hit, why continue to try and start up new ones? What do you define as 'hung solid'? You are unable to get in via SSH? Or at a console via iLO/etc? I've seen this on some of our 6.0-RELEASE machines (along with maxpipekva exhausted errors), and you can't SSH in from that point... because sshd forks to handle the connection, and all available process slots are used up. I've thought about writing a background daemon to monitor the logs for signs of this (or even to just try and create a short-lived child process by fork()ing every 5 minutes or so), and dump information to disk then reboot the system when this occurs... it's a work-around for something that shouldn't happen, but it does anyway... once I'm able to identify _what_ is causing the build-up of processes, then I might be able to do something about killing them...!!! It's quite deceptive from an end-user point of view, because things like Apache that are already keep running, so all they see are strange bits and pieces that don't work... and as always, its one of those things that only happens on some clients machines, but never on any of our test machines... --Antony PS. I haven't disappeared off the face of the earth.. though close.. my fiance and I have been busy planning the wedding, and wound up buying
