fix clang build ImageMagic and GraphicsMagick
Hi, mm and Mark, sorry my misuse for previous mail, I found that the these two ports building failure is because the exception.sh test (for ImageMagic) and exception.sh attribute.sh (for GraphicsMagick) are vulnerable to -O2 optimization (for CXXFLAGS). So my fix is samply to lower -O2 optimization to -O1, I test is on both stable 9, but I do not know ports makefile much, can not give a patch. here is my test, #cd ports/graphics/ImageMagick; #make CC=clang CXX=clang++ CXXFLAGS=-O1 在 2011年12月21日 上午1:06，Mark Linimon lini...@lonesome.com 写道： I have recently been able to get the new build cluster on pointyhat-west set up to run full builds of ports with clang on amd64-9. I have documented the latest results on the wiki: http://wiki.freebsd.org/PortsAndClang If you are interested in working on ports being built via clang, this is your place to start. Please also note that now that we have up-to-date builds going, it is not as useful to us to report individual clang build failures. Patches to fix problems are, of course, highly welcome. mcl ___ 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 ___ 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: FreeBSD 9 recompile ports
On 13/01/2012 22:57, Andriy Gapon wrote: But if the appropriate misc/compatX port is installed, then those libraries do actually exist and the system should be fully usable... Modulo the compat libraries not working with the new kernel as Kostik has pointed out. As soon as you update or install an application after this point, you are likely to end up with an application that tries to dynamically link two different versions of the same shlib, and that is a recipe for tears-before-bedtime. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: libutempter
On Tue, 10 Jan 2012 19:58:13 -0600, Andre Goree an...@drenet.info wrote: I recently csup'd 9-STABLE and was able to get it working along with my custom kernel. I'm now in the process of rebuilding all my ports, and I've come across something when running 'portmaster -af' that I can't seem to find any information on. === Launching child to reinstall libutempter-1.1.5_1 === Port directory: /usr/ports/sysutils/libutempter === This port is marked IGNORE === is now contained in the base system === If you are sure you can build it, remove the IGNORE line in the Makefile and try again. === Update for libutempter-1.1.5_1 failed === Aborting update Terminated I figure, ok I'll just delete the package and move on. However, there are many packages I have installed that depend on libutemper. I would still just proceed with the removal given that the functionality is provided in base now, however I don't want to break all these ports and have to deal with the mess when I portmaster -af again. What is the recommended action here? Should I just force exclude that port from the upgrade? That's probably the easiest way but I'd have to deal with this at some point. Thanks in advance for any advice -- Andre Goree andre@drenetinfo So I've rebuilt everything that I could, but when I get to the ports that depend on libutempter, I get an error that they could not be reinstalled due to a failure with libutempter :/ --- Skipping 'www/opera' (opera-11.60) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) --- Skipping 'www/opera-linuxplugins' (opera-linuxplugins-11.60) because a requisite package 'opera-11.60' (www/opera) failed (specify -k to force) --- Skipping 'deskutils/kdeplasma-addons' (kdeplasma-addons-4.7.3) because a requisite package 'kdepimlibs-4.7.3' (deskutils/kdepimlibs4) failed (specify -k to force) --- Skipping 'graphics/libkdcraw-kde4' (libkdcraw-4.7.3) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) I installed misc/compat8x, however it informed my that I'd need to add to the kernel conf. When I try to do that, I'm met with this error: /usr/src/sys/amd64/conf/DESKTOPKERN9: unknown option COMPAT_FREEBSD8 *** Error code 1 Stop in /usr/src. Which is weird, because: [root@desktop src]# uname -r 9.0-STABLE Meaning I'm certainly running 9.0-STABLE. So what gives re: that error above about unknown option? I even tried to csup source and buildworld again, but to no avail -- the error remains. -- Andre Goree an...@drenet.info ___ 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
PHP-gnupg in jail - apache and tty
Hello, Currently I'm facing a wierd problem. I should have an environment in a jail where a PHP script (with pecl-gnupg) is able to sign messages with PGP. However it turned out, that PGP needs a tty in the jail, which is available if I use tmux or ssh login to the jail and signing from shell works. From the apache-php side, I got a data signing failed and nothing more useful. Of course I tried ktrace, but I couldn't find anything useful. I know that Apache should have a real login shell if php-gnupg is used, so it has one. (Yes I know it's bad, but it's a dedicated environment for this web application only.) On Linux I could do a tty with mknod in a chroot and signing worked with php-gnupg. Anyone has any idea to start with? Thanks, Andras ___ 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: FYI: 9.0-RELEASE announced...
On 01/14/2012 11:00, per...@pluto.rain.com wrote: Ken Smithkensm...@buffalo.edu wrote: The release notes were not ready at the point we started up the release builds so the online versions are the only ones that have any useful information in them. Perhaps the final version could be made MFCd to the errata/security branch, and/or added to the FTP sites alongside the ISOs. In the future, might it be useful to delay the release until the release notes are available? I would _guess_ that doing a partial build, of only the release notes, would not take all that long. ___ 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 And can we say that 9.0-RELEASE is the first FreeBSD release not including the release documentation on the distribution media ? On an another topic, as the author of PR 162190, I am afraid that this release, as built, is not able to play audio CDs with popular applications like VLC: the needed commit (r230014) has been done by mav@ in stable/9 on Jan 12. Claude Buisson ___ 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: Upgrade to 9.0 and Fan kick to high speed
On 2012-01-14 (Saturday) 04:35:31 Jeremy Chadwick wrote: On Fri, Jan 13, 2012 at 07:44:17PM -0500, benjamin adams wrote: I just upgraded from RC3 to release and now my pc fans are doing an high to low every two seconds. Ideas on why?? Lots of ideas on why, but whether or not any of them are applicable is a separate topic. :-) For starters: sysctl -a | grep freq sysctl -a | grep acpi And are you using powerd(8) at all? Hi This is happening to me, too. It starts occuring after about two hours of uptime here, and I haven't managed to get any of the sysctl data under this effect, as the system will start booting when I run sysctl. sysctl dev.cpu.x.freq runs however, showing 400-1200 MHz (with coretemp module dev.cpu.0.temperature is 30-35 C) so it's a sensor issue somewhere else - also the overheat indicator light of the affected box turns on here every ~20 seconds, causing the fans to run faster. I've attached the sysctl outputs of the system while it's is running stable. powerd is running, with performance_cx_lowest and economy_cx_lowest set to C2. Also, I've been running 9-STABLE for months (i.e. before and after RELEASE) without this issue, but enabled speedstepping only a few days ago, so I think this issue might be related to speedsteping. I'll disable it now and report back in a few hours if it helped ;) Alonso device acpi debug.acpi.acpi_ca_version: 20110527 debug.acpi.enable_debug_objects: 0 debug.acpi.interpreter_slack: 1 debug.acpi.reset_clock: 1 debug.acpi.suspend_bounce: 0 debug.acpi.ec.burst: 0 debug.acpi.ec.polled: 0 debug.acpi.ec.timeout: 750 debug.acpi.batt.batt_sleep_ms: 0 debug.acpi.resume_beep: 0 hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: NONE hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 1 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C2 machdep.acpi_timer_freq: 3579545 machdep.idle_available: spin, mwait, hlt, acpi machdep.idle: acpi machdep.acpi_root: 984144 dev.acpi.0.%desc: SUPERM SMCI--MB dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.MCH_ dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C01 _UID=10 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.SBRG.RMSC dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=16 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_sysresource.2.%desc: System Resource dev.acpi_sysresource.2.%driver: acpi_sysresource dev.acpi_sysresource.2.%location: handle=\_SB_.PCI0.SBRG.SIO1 dev.acpi_sysresource.2.%pnpinfo: _HID=PNP0C02 _UID=273 dev.acpi_sysresource.2.%parent: acpi0 dev.acpi_sysresource.3.%desc: System Resource dev.acpi_sysresource.3.%driver: acpi_sysresource dev.acpi_sysresource.3.%location: handle=\_SB_.PCI0.SBRG.SIO2 dev.acpi_sysresource.3.%pnpinfo: _HID=PNP0C02 _UID=5710 dev.acpi_sysresource.3.%parent: acpi0 dev.acpi_sysresource.4.%desc: System Resource dev.acpi_sysresource.4.%driver: acpi_sysresource dev.acpi_sysresource.4.%location: handle=\_SB_.PCI0.PCH_ dev.acpi_sysresource.4.%pnpinfo: _HID=PNP0C01 _UID=455 dev.acpi_sysresource.4.%parent: acpi0 dev.acpi_sysresource.5.%desc: System Resource dev.acpi_sysresource.5.%driver: acpi_sysresource dev.acpi_sysresource.5.%location: handle=\_SB_.PCI0.CWDT dev.acpi_sysresource.5.%pnpinfo: _HID=INT3F0D _UID=0 dev.acpi_sysresource.5.%parent: acpi0 dev.acpi_sysresource.6.%desc: System Resource dev.acpi_sysresource.6.%driver: acpi_sysresource dev.acpi_sysresource.6.%location: handle=\_SB_.RMEM dev.acpi_sysresource.6.%pnpinfo: _HID=PNP0C01 _UID=1 dev.acpi_sysresource.6.%parent: acpi0 dev.acpi_sysresource.7.%desc: System Resource dev.acpi_sysresource.7.%driver: acpi_sysresource dev.acpi_sysresource.7.%location: handle=\OMSC dev.acpi_sysresource.7.%pnpinfo: _HID=PNP0C02 _UID=3601 dev.acpi_sysresource.7.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.cpu.0.%parent: acpi0 dev.cpu.1.%parent: acpi0 dev.cpu.2.%parent: acpi0 dev.cpu.3.%parent: acpi0 dev.cpu.4.%parent: acpi0 dev.cpu.5.%parent: acpi0 dev.cpu.6.%parent: acpi0 dev.cpu.7.%parent: acpi0 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%parent: acpi0 dev.pcib.0.%parent: acpi0 dev.acpi_button.0.%desc: Power Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.PWRB
Re: FYI: 9.0-RELEASE announced...
On 01/14/2012 01:39, Claude Buisson wrote: And can we say that 9.0-RELEASE is the first FreeBSD release not including the release documentation on the distribution media ? There are a variety of things that could be improved about the release note generation process, however the actual process of doing the release takes a non-trivial amount of time, and the fact that they are available on line coincident with the release is a plus. To have re-started the process of seeding the release files out to all the mirrors (or holding it for the release docs in the first place) would have further delayed a long-overdue delivery. The release engineers made the best decision they could under the circumstances. On an another topic, as the author of PR 162190, I am afraid that this release, as built, is not able to play audio CDs with popular applications like VLC: the needed commit (r230014) has been done by mav@ in stable/9 on Jan 12. Yep, that's a known issue, and as you point out, the solution is already available. 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
Re: SVN checkout
Thx guys for all the info :-) On 14 January 2012 00:19, Andreas Nilsson andrn...@gmail.com wrote: On Fri, Jan 13, 2012 at 11:00 PM, Garrett Cooper yaneg...@gmail.com wrote: On Jan 13, 2012, at 1:55 PM, John Baldwin wrote: On Friday, January 13, 2012 4:40:08 pm Andreas Nilsson wrote: On 01/13/2012 09:51 PM, Garrett Cooper wrote: On Jan 13, 2012, at 5:53 AM, Julian Kennedy wrote: Hi All Im just joined the list. Im not sure if this is the right place to ask svn questions. I want to checkout the freebsd code to play with it a bit. What should I do and which part of the repo should I checkout? I want the 9.0 code. $ cd /usr/src $ svn co http://svn.freebsd.org/base/release/9.0.0 . Can I just ask a for a clarification then: would .../release/8.2.5 get me what after buildworld+buildkernel results in 8.2-RELEASE-p5? I ask because I have some interest in having a tree from which i easily can check out a given patch-version. I don't think we tag the patches, I think they are just committed to releng/8.2 directly. However, you could look at the logs for a given branch (e.g. svn log --stop-on-copy releng/8.2) and figure out the svn revision that would correspond to 8.2-p5. Thanks. That would be my recommendation too. Things aren't always consistent between CVS and SVN because they're two separate systems, but it should be more consistent with 9.0.0+ (or at least it appeared to have been that way because now releng is using SVN primarily for release from what I saw and not CVS, which was the way things were in the past). Thanks, -Garrett Thanks. I had some inkling of this :) Shame on my for not keeping checkouts in a more consistent way. /Andreas ___ 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 ___ 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: libutempter
On 01/14/2012 09:47, Andre Goree wrote: On Tue, 10 Jan 2012 19:58:13 -0600, Andre Goree an...@drenet.info wrote: I recently csup'd 9-STABLE and was able to get it working along with my custom kernel. I'm now in the process of rebuilding all my ports, and I've come across something when running 'portmaster -af' that I can't seem to find any information on. === Launching child to reinstall libutempter-1.1.5_1 === Port directory: /usr/ports/sysutils/libutempter === This port is marked IGNORE === is now contained in the base system === If you are sure you can build it, remove the IGNORE line in the Makefile and try again. === Update for libutempter-1.1.5_1 failed === Aborting update Terminated I figure, ok I'll just delete the package and move on. However, there are many packages I have installed that depend on libutemper. I would still just proceed with the removal given that the functionality is provided in base now, however I don't want to break all these ports and have to deal with the mess when I portmaster -af again. What is the recommended action here? Should I just force exclude that port from the upgrade? That's probably the easiest way but I'd have to deal with this at some point. Thanks in advance for any advice -- Andre Goree andre@drenetinfo So I've rebuilt everything that I could, but when I get to the ports that depend on libutempter, I get an error that they could not be reinstalled due to a failure with libutempter :/ --- Skipping 'www/opera' (opera-11.60) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) --- Skipping 'www/opera-linuxplugins' (opera-linuxplugins-11.60) because a requisite package 'opera-11.60' (www/opera) failed (specify -k to force) --- Skipping 'deskutils/kdeplasma-addons' (kdeplasma-addons-4.7.3) because a requisite package 'kdepimlibs-4.7.3' (deskutils/kdepimlibs4) failed (specify -k to force) --- Skipping 'graphics/libkdcraw-kde4' (libkdcraw-4.7.3) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) I installed misc/compat8x, however it informed my that I'd need to add to the kernel conf. When I try to do that, I'm met with this error: /usr/src/sys/amd64/conf/DESKTOPKERN9: unknown option COMPAT_FREEBSD8 *** Error code 1 Stop in /usr/src. Which is weird, because: [root@desktop src]# uname -r 9.0-STABLE Meaning I'm certainly running 9.0-STABLE. So what gives re: that error above about unknown option? I even tried to csup source and buildworld again, but to no avail -- the error remains. I upgrade my ports with portupgrade. After removing libutempter I just run `pkgdb -Fu' and then I can proceed with the update of depending ports. I don't need compat8x. Henri ___ 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: FreeBSD 9 recompile ports
On 01/14/2012 09:46, Matthew Seaman wrote: On 13/01/2012 22:57, Andriy Gapon wrote: But if the appropriate misc/compatX port is installed, then those libraries do actually exist and the system should be fully usable... Modulo the compat libraries not working with the new kernel as Kostik has pointed out. As soon as you update or install an application after this point, you are likely to end up with an application that tries to dynamically link two different versions of the same shlib, and that is a recipe for tears-before-bedtime. This /etc/libmap.conf help me greatly when I reinstall all my ports after 9.0-BETA2 and make delete-old-libs: libsbuf.so.5libsbuf.so.6 libz.so.5 libz.so.6 libutil.so.8libutil.so.9 libcam.so.5 libcam.so.6 libpcap.so.7libpcap.so.8 libufs.so.5 libufs.so.6 libbsnmp.so.5 libbsnmp.so.6 libdwarf.so.2 libdwarf.so.3 libopie.so.6libopie.so.7 librtld_db.so.1 librtld_db.so.2 libtacplus.so.4 libtacplus.so.5 Henri Cheers, Matthew ___ 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: FreeBSD 9 recompile ports
On Sat, Jan 14, 2012 at 11:29:00AM +0100, Henri Hennebert wrote: On 01/14/2012 09:46, Matthew Seaman wrote: On 13/01/2012 22:57, Andriy Gapon wrote: But if the appropriate misc/compatX port is installed, then those libraries do actually exist and the system should be fully usable... Modulo the compat libraries not working with the new kernel as Kostik has pointed out. As soon as you update or install an application after this point, you are likely to end up with an application that tries to dynamically link two different versions of the same shlib, and that is a recipe for tears-before-bedtime. This /etc/libmap.conf help me greatly when I reinstall all my ports after 9.0-BETA2 and make delete-old-libs: libsbuf.so.5 libsbuf.so.6 libz.so.5 libz.so.6 libutil.so.8 libutil.so.9 libcam.so.5 libcam.so.6 libpcap.so.7 libpcap.so.8 libufs.so.5 libufs.so.6 libbsnmp.so.5 libbsnmp.so.6 libdwarf.so.2 libdwarf.so.3 libopie.so.6 libopie.so.7 librtld_db.so.1 librtld_db.so.2 libtacplus.so.4 libtacplus.so.5 This is very, VERY, ***VERY*** dangerous. Apparently nobody has explained why, so I will: When a linked library version number (N of libfoo.so.N) increases or changes, it indicates there are API/ABI changes to the library. There is absolutely ZERO guarantee that calling semantics are the same, that function arguments (thus stack order) are the same, or that structures used internally by the library are the same. The effects of this can be devastating -- if you're lucky it'll consist of just missing symbol, but it can be a lot worse. The TL;DR version is: there is absolutely ZERO guarantee that the internal operations and calling semantics of the libraries are identical. Folks reading this thread, PLEASE do not follow the above advice and leave your system running in that kind of state. Instead of being lazy, rebuild all your ports from scratch or pull down new binary copies (pkg_add -r ...) for the version of the OS you're running. Doug and I have the same opinion when it comes to this situation, and it's based purely on experience. Schedule downtime, spend an afternoon rebuilding things, whatever -- just do it the Right Way(tm) please. Otherwise you're creating a lot of support hassle when it comes to trying to diagnose why some program on your system behaves oddly -- weeks go by, oh, libmap.conf... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9 recompile ports
On 01/14/2012 11:37, Jeremy Chadwick wrote: On Sat, Jan 14, 2012 at 11:29:00AM +0100, Henri Hennebert wrote: On 01/14/2012 09:46, Matthew Seaman wrote: On 13/01/2012 22:57, Andriy Gapon wrote: But if the appropriate misc/compatX port is installed, then those libraries do actually exist and the system should be fully usable... Modulo the compat libraries not working with the new kernel as Kostik has pointed out. As soon as you update or install an application after this point, you are likely to end up with an application that tries to dynamically link two different versions of the same shlib, and that is a recipe for tears-before-bedtime. This /etc/libmap.conf help me greatly when I reinstall all my ports --- after 9.0-BETA2 and make delete-old-libs: libsbuf.so.5 libsbuf.so.6 libz.so.5libz.so.6 libutil.so.8 libutil.so.9 libcam.so.5 libcam.so.6 libpcap.so.7 libpcap.so.8 libufs.so.5 libufs.so.6 libbsnmp.so.5libbsnmp.so.6 libdwarf.so.2libdwarf.so.3 libopie.so.6 libopie.so.7 librtld_db.so.1 librtld_db.so.2 libtacplus.so.4 libtacplus.so.5 This is very, VERY, ***VERY*** dangerous. Apparently nobody has explained why, so I will: When a linked library version number (N of libfoo.so.N) increases or changes, it indicates there are API/ABI changes to the library. There is absolutely ZERO guarantee that calling semantics are the same, that function arguments (thus stack order) are the same, or that structures used internally by the library are the same. The effects of this can be devastating -- if you're lucky it'll consist of just missing symbol, but it can be a lot worse. The TL;DR version is: there is absolutely ZERO guarantee that the internal operations and calling semantics of the libraries are identical. Folks reading this thread, PLEASE do not follow the above advice and leave your system running in that kind of state. Instead of being lazy, I don't want to argue too much, but you don't read me correctly. I just do this during the time I REINSTALL ALL PORTS and then I delete /etc/libmap.conf, of course, I'm not crazy! rebuild all your ports from scratch or pull down new binary copies (pkg_add -r ...) for the version of the OS you're running. Doug and I have the same opinion when it comes to this situation, and it's based purely on experience. Schedule downtime, spend an afternoon rebuilding things, whatever -- just do it the Right Way(tm) please. Otherwise you're creating a lot of support hassle when it comes to trying to diagnose why some program on your system behaves oddly -- weeks go by, oh, libmap.conf... ___ 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: libutempter
On 14 Jan 2012 08:48, Andre Goree an...@drenet.info wrote: On Tue, 10 Jan 2012 19:58:13 -0600, Andre Goree an...@drenet.info wrote: I recently csup'd 9-STABLE and was able to get it working along with my custom kernel. I'm now in the process of rebuilding all my ports, and I've come across something when running 'portmaster -af' that I can't seem to find any information on. === Launching child to reinstall libutempter-1.1.5_1 === Port directory: /usr/ports/sysutils/libutempter === This port is marked IGNORE === is now contained in the base system === If you are sure you can build it, remove the IGNORE line in the Makefile and try again. === Update for libutempter-1.1.5_1 failed === Aborting update Terminated I figure, ok I'll just delete the package and move on. However, there are many packages I have installed that depend on libutemper. I would still just proceed with the removal given that the functionality is provided in base now, however I don't want to break all these ports and have to deal with the mess when I portmaster -af again. What is the recommended action here? Should I just force exclude that port from the upgrade? That's probably the easiest way but I'd have to deal with this at some point. Thanks in advance for any advice -- Andre Goree andre@drenetinfo So I've rebuilt everything that I could, but when I get to the ports that depend on libutempter, I get an error that they could not be reinstalled due to a failure with libutempter :/ --- Skipping 'www/opera' (opera-11.60) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) --- Skipping 'www/opera-linuxplugins' (opera-linuxplugins-11.60) because a requisite package 'opera-11.60' (www/opera) failed (specify -k to force) --- Skipping 'deskutils/kdeplasma-addons' (kdeplasma-addons-4.7.3) because a requisite package 'kdepimlibs-4.7.3' (deskutils/kdepimlibs4) failed (specify -k to force) --- Skipping 'graphics/libkdcraw-kde4' (libkdcraw-4.7.3) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) I installed misc/compat8x, however it informed my that I'd need to add to the kernel conf. When I try to do that, I'm met with this error: /usr/src/sys/amd64/conf/DESKTOPKERN9: unknown option COMPAT_FREEBSD8 *** Error code 1 Stop in /usr/src. Which is weird, because: [root@desktop src]# uname -r 9.0-STABLE Meaning I'm certainly running 9.0-STABLE. So what gives re: that error above about unknown option? I even tried to csup source and buildworld again, but to no avail -- the error remains. Just pkg_delete -f it. Since it's in base, its absence won't cause a problem. Chris ___ 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: Upgrade to 9.0 and Fan kick to high speed
System is running well for 6 hours now. Seems like disabling speedsteping solved it (for me). Alonso ___ 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: Prevent starting network on usbus
In message cao+pfdcmxw0+g5h_ey79f_hc_13qrf8ku_krxuhjqcqyrt7...@mail.gmail.com, David Demelier (demelier.da...@gmail.com) wrote: 2012/1/13 N.J. Mann n...@njm.me.uk: In message CAO+PfDfD0nMSshpybMzKrVSBQKFyp=c6sjmmplpit1ihw_b...@mail.gmail.com, David Demelier (demelier.da...@gmail.com) wrote: Since I've updated to 9.0-RELEASE, the network rc script starts network from usbus0 to usbus7. I don't think I need them. How can I disable them ? echo hw.usb.no_pf=1 /boot/loader.conf Thanks, it works. This is the second USB tunable I know now. I know hw.usb.no_boot_wait too but I can't find any man pages that talk about them. Is it documented somewhere? I have not been able to find anything. I have been using it since June last year. The relevant commit may be viewed at: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb_pf.c.diff?r1=1.9;r2=1.10;f=h Cheers, Nick. -- ___ 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: FreeBSD 9 recompile ports
On Sat, Jan 14, 2012 at 12:46 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 13/01/2012 22:57, Andriy Gapon wrote: But if the appropriate misc/compatX port is installed, then those libraries do actually exist and the system should be fully usable... Modulo the compat libraries not working with the new kernel as Kostik has pointed out. As soon as you update or install an application after this point, you are likely to end up with an application that tries to dynamically link two different versions of the same shlib, and that is a recipe for tears-before-bedtime. I don't recall any tears, but it does become a real pain. The compat ports only work for those who only update when absolutely required. Thanks to symbol versioning, most base system libraries don't cause a problem, so the problem is far less likely to bite you than it was in the past, but the bottom line is that you should seriously consider updating all ports. Thanks to Doug Barton's work on portmaster(8), doing so with packages is pretty fast and easy. Even doing a full re-build of all ports (over 1000 of them) on the last system I upgraded to 9.0 updated with no intervention over one night. Use the multiple steps in the big example in the portmaster(8) man page for best results and run the re-install step with '-D'. The man page also provides a simple way to do the job, but it does not assure a completely clean system. I would also consider saving the files in /usr/local/etc after all ports have been removed.That can save a fair amount of reconfiguration at the slight risk of retaining some old cruft. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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
HPN-SSH question
Since it doesn't seem that the HPN-SSH patches are going to be merged upstream to OpenSSH (please correct me if I'm wrong), and since the HPN-SSH project seems to be very low on resources, is the inclusion of these patches in FreeBSD 9 a commitment by FreeBSD to maintain these patches against stock OpenSSH in the future? Is there any indication that the OpenSSH project will be more willing to consider merging if the patches survive a -STABLE generation in FreeBSD? ___ 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: libutempter
On Sat, 14 Jan 2012 04:14:38 -0600, Henri Hennebert h...@restart.be wrote: On 01/14/2012 09:47, Andre Goree wrote: On Tue, 10 Jan 2012 19:58:13 -0600, Andre Goree an...@drenet.info wrote: I recently csup'd 9-STABLE and was able to get it working along with my custom kernel. I'm now in the process of rebuilding all my ports, and I've come across something when running 'portmaster -af' that I can't seem to find any information on. === Launching child to reinstall libutempter-1.1.5_1 === Port directory: /usr/ports/sysutils/libutempter === This port is marked IGNORE === is now contained in the base system === If you are sure you can build it, remove the IGNORE line in the Makefile and try again. === Update for libutempter-1.1.5_1 failed === Aborting update Terminated I figure, ok I'll just delete the package and move on. However, there are many packages I have installed that depend on libutemper. I would still just proceed with the removal given that the functionality is provided in base now, however I don't want to break all these ports and have to deal with the mess when I portmaster -af again. What is the recommended action here? Should I just force exclude that port from the upgrade? That's probably the easiest way but I'd have to deal with this at some point. Thanks in advance for any advice -- Andre Goree andre@drenetinfo So I've rebuilt everything that I could, but when I get to the ports that depend on libutempter, I get an error that they could not be reinstalled due to a failure with libutempter :/ --- Skipping 'www/opera' (opera-11.60) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) --- Skipping 'www/opera-linuxplugins' (opera-linuxplugins-11.60) because a requisite package 'opera-11.60' (www/opera) failed (specify -k to force) --- Skipping 'deskutils/kdeplasma-addons' (kdeplasma-addons-4.7.3) because a requisite package 'kdepimlibs-4.7.3' (deskutils/kdepimlibs4) failed (specify -k to force) --- Skipping 'graphics/libkdcraw-kde4' (libkdcraw-4.7.3) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) I installed misc/compat8x, however it informed my that I'd need to add to the kernel conf. When I try to do that, I'm met with this error: /usr/src/sys/amd64/conf/DESKTOPKERN9: unknown option COMPAT_FREEBSD8 *** Error code 1 Stop in /usr/src. Which is weird, because: [root@desktop src]# uname -r 9.0-STABLE Meaning I'm certainly running 9.0-STABLE. So what gives re: that error above about unknown option? I even tried to csup source and buildworld again, but to no avail -- the error remains. I upgrade my ports with portupgrade. After removing libutempter I just run `pkgdb -Fu' and then I can proceed with the update of depending ports. I don't need compat8x. Henri ___ 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 Thanks, yeah upon further research last night I discovered that COMPAT_FREEBSD8 is not kernel option and that compat8x doesn't play a role at all in my situation. Also thanks for the suggestion, that worked perfectly! :) Just pkg_delete -f it. Since it's in base, its absence won't cause a problem. Chris Yeah I was mored concerned (erroneously, it would seem) with dependency hell rather than missing libs :pAfter just removing it then doing a pkgdb -Fu, I'm good to go. I've done this before in the past with pkg's I've removed, so kinda disheartening that I overlooked it for so long, heh. I guess I don't fully grasp the relationship between ports and pkgs which lead to all this confusion. In any case, it's resolved now, thanks everyone who replied :) -- Andre Goree an...@drenet.info ___ 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: libutempter
On Sat, Jan 14, 2012 at 12:34 PM, Chris Rees utis...@gmail.com wrote: On 14 Jan 2012 18:26, Andre Goree an...@drenet.info wrote: On Sat, 14 Jan 2012 04:14:38 -0600, Henri Hennebert h...@restart.be wrote: On 01/14/2012 09:47, Andre Goree wrote: On Tue, 10 Jan 2012 19:58:13 -0600, Andre Goree an...@drenet.info wrote: I recently csup'd 9-STABLE and was able to get it working along with my custom kernel. I'm now in the process of rebuilding all my ports, and I've come across something when running 'portmaster -af' that I can't seem to find any information on. === Launching child to reinstall libutempter-1.1.5_1 === Port directory: /usr/ports/sysutils/libutempter === This port is marked IGNORE === is now contained in the base system === If you are sure you can build it, remove the IGNORE line in the Makefile and try again. === Update for libutempter-1.1.5_1 failed === Aborting update Terminated I figure, ok I'll just delete the package and move on. However, there are many packages I have installed that depend on libutemper. I would still just proceed with the removal given that the functionality is provided in base now, however I don't want to break all these ports and have to deal with the mess when I portmaster -af again. What is the recommended action here? Should I just force exclude that port from the upgrade? That's probably the easiest way but I'd have to deal with this at some point. Thanks in advance for any advice -- Andre Goree andre@drenetinfo So I've rebuilt everything that I could, but when I get to the ports that depend on libutempter, I get an error that they could not be reinstalled due to a failure with libutempter :/ --- Skipping 'www/opera' (opera-11.60) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) --- Skipping 'www/opera-linuxplugins' (opera-linuxplugins-11.60) because a requisite package 'opera-11.60' (www/opera) failed (specify -k to force) --- Skipping 'deskutils/kdeplasma-addons' (kdeplasma-addons-4.7.3) because a requisite package 'kdepimlibs-4.7.3' (deskutils/kdepimlibs4) failed (specify -k to force) --- Skipping 'graphics/libkdcraw-kde4' (libkdcraw-4.7.3) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) I installed misc/compat8x, however it informed my that I'd need to add to the kernel conf. When I try to do that, I'm met with this error: /usr/src/sys/amd64/conf/DESKTOPKERN9: unknown option COMPAT_FREEBSD8 *** Error code 1 Stop in /usr/src. Which is weird, because: [root@desktop src]# uname -r 9.0-STABLE Meaning I'm certainly running 9.0-STABLE. So what gives re: that error above about unknown option? I even tried to csup source and buildworld again, but to no avail -- the error remains. I upgrade my ports with portupgrade. After removing libutempter I just run `pkgdb -Fu' and then I can proceed with the update of depending ports. I don't need compat8x. Henri ___ 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 Thanks, yeah upon further research last night I discovered that COMPAT_FREEBSD8 is not kernel option and that compat8x doesn't play a role at all in my situation. Also thanks for the suggestion, that worked perfectly! :) Just pkg_delete -f it. Since it's in base, its absence won't cause a problem. Chris Yeah I was mored concerned (erroneously, it would seem) with dependency hell rather than missing libs :pAfter just removing it then doing a pkgdb -Fu, I'm good to go. I've done this before in the past with pkg's I've removed, so kinda disheartening that I overlooked it for so long, heh. I guess I don't fully grasp the relationship between ports and pkgs which lead to all this confusion. In any case, it's resolved now, thanks everyone who replied :) Woah, whatever you do, don't switch TO portupgrade! It does nothing that other tools can't, is unmaintained and is unlikely to work with Ruby 1.9, and unless that is fixed it's going to die fairly soon. Chris Thanks, but I'm not switching TO anything, it's what I've been using and what I'm comfortable with. What gave the impression that I hadn't already been using portupgrade? ___ 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: libutempter
On Sat, Jan 14, 2012 at 1:05 PM, Andre Goree an...@drenet.info wrote: On Sat, Jan 14, 2012 at 12:34 PM, Chris Rees utis...@gmail.com wrote: On 14 Jan 2012 18:26, Andre Goree an...@drenet.info wrote: On Sat, 14 Jan 2012 04:14:38 -0600, Henri Hennebert h...@restart.be wrote: On 01/14/2012 09:47, Andre Goree wrote: On Tue, 10 Jan 2012 19:58:13 -0600, Andre Goree an...@drenet.info wrote: I recently csup'd 9-STABLE and was able to get it working along with my custom kernel. I'm now in the process of rebuilding all my ports, and I've come across something when running 'portmaster -af' that I can't seem to find any information on. === Launching child to reinstall libutempter-1.1.5_1 === Port directory: /usr/ports/sysutils/libutempter === This port is marked IGNORE === is now contained in the base system === If you are sure you can build it, remove the IGNORE line in the Makefile and try again. === Update for libutempter-1.1.5_1 failed === Aborting update Terminated I figure, ok I'll just delete the package and move on. However, there are many packages I have installed that depend on libutemper. I would still just proceed with the removal given that the functionality is provided in base now, however I don't want to break all these ports and have to deal with the mess when I portmaster -af again. What is the recommended action here? Should I just force exclude that port from the upgrade? That's probably the easiest way but I'd have to deal with this at some point. Thanks in advance for any advice -- Andre Goree andre@drenetinfo So I've rebuilt everything that I could, but when I get to the ports that depend on libutempter, I get an error that they could not be reinstalled due to a failure with libutempter :/ --- Skipping 'www/opera' (opera-11.60) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) --- Skipping 'www/opera-linuxplugins' (opera-linuxplugins-11.60) because a requisite package 'opera-11.60' (www/opera) failed (specify -k to force) --- Skipping 'deskutils/kdeplasma-addons' (kdeplasma-addons-4.7.3) because a requisite package 'kdepimlibs-4.7.3' (deskutils/kdepimlibs4) failed (specify -k to force) --- Skipping 'graphics/libkdcraw-kde4' (libkdcraw-4.7.3) because a requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) I installed misc/compat8x, however it informed my that I'd need to add to the kernel conf. When I try to do that, I'm met with this error: /usr/src/sys/amd64/conf/DESKTOPKERN9: unknown option COMPAT_FREEBSD8 *** Error code 1 Stop in /usr/src. Which is weird, because: [root@desktop src]# uname -r 9.0-STABLE Meaning I'm certainly running 9.0-STABLE. So what gives re: that error above about unknown option? I even tried to csup source and buildworld again, but to no avail -- the error remains. I upgrade my ports with portupgrade. After removing libutempter I just run `pkgdb -Fu' and then I can proceed with the update of depending ports. I don't need compat8x. Henri ___ 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 Thanks, yeah upon further research last night I discovered that COMPAT_FREEBSD8 is not kernel option and that compat8x doesn't play a role at all in my situation. Also thanks for the suggestion, that worked perfectly! :) Just pkg_delete -f it. Since it's in base, its absence won't cause a problem. Chris Yeah I was mored concerned (erroneously, it would seem) with dependency hell rather than missing libs :pAfter just removing it then doing a pkgdb -Fu, I'm good to go. I've done this before in the past with pkg's I've removed, so kinda disheartening that I overlooked it for so long, heh. I guess I don't fully grasp the relationship between ports and pkgs which lead to all this confusion. In any case, it's resolved now, thanks everyone who replied :) Woah, whatever you do, don't switch TO portupgrade! It does nothing that other tools can't, is unmaintained and is unlikely to work with Ruby 1.9, and unless that is fixed it's going to die fairly soon. Chris Thanks, but I'm not switching TO anything, it's what I've been using and what I'm comfortable with. What gave the impression that I hadn't already been using portupgrade? Oh I see, my original message, lol. Rest assured, all is well. I've already reconciled the differences and pains that each tool cause on each other (i.e., rebuilt my pkgdb portsdb before using portupgrade to finish upgrading all my ports). ___
Re: FreeBSD 9 recompile ports
On Sat, Jan 14, 2012 at 7:32 PM, Kevin Oberman kob6...@gmail.com wrote: On Sat, Jan 14, 2012 at 12:46 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 13/01/2012 22:57, Andriy Gapon wrote: But if the appropriate misc/compatX port is installed, then those libraries do actually exist and the system should be fully usable... Modulo the compat libraries not working with the new kernel as Kostik has pointed out. As soon as you update or install an application after this point, you are likely to end up with an application that tries to dynamically link two different versions of the same shlib, and that is a recipe for tears-before-bedtime. I don't recall any tears, but it does become a real pain. The compat ports only work for those who only update when absolutely required. Thanks to symbol versioning, most base system libraries don't cause a problem, so the problem is far less likely to bite you than it was in the past, but the bottom line is that you should seriously consider updating all ports. Thanks to Doug Barton's work on portmaster(8), doing so with packages is pretty fast and easy. Even doing a full re-build of all ports (over 1000 of them) on the last system I upgraded to 9.0 updated with no intervention over one night. Use the multiple steps in the big example in the portmaster(8) man page for best results and run the re-install step with '-D'. The man page also provides a simple way to do the job, but it does not assure a completely clean system. I would also consider saving the files in /usr/local/etc after all ports have been removed.That can save a fair amount of reconfiguration at the slight risk of retaining some old cruft. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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 I always find this a good opportunity to upgrade Perl. Given the fact that upgrading perl and all the ports that depend upon is a pain, having to rebuild all the ports is always a good excuse to do it. For the amount of ports installed on a production server combined with todays horsepower, a full rebuild doesn't take more than a couple of hours. On a desktop it is a bit more complicated but it is always a good opportunity to toss some ports that are useless. -- George Kontostanos Aicom telecoms ltd http://www.aisecure.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: HPN-SSH question
On a similar note I'm actually quite concerned by the inclusion of these patches by default in the OS version of ssh as we've seen several cases of it causing noticeable performance degradation instead of improvement. I've not tested on 9, but this was certainly the case on 8.2. Regards Steve - Original Message - From: Jeremiah Gowdy jeremiah.go...@freedomvoice.com To: freebsd-stable@freebsd.org Sent: Saturday, January 14, 2012 5:30 PM Subject: HPN-SSH question Since it doesn't seem that the HPN-SSH patches are going to be merged upstream to OpenSSH (please correct me if I'm wrong), and since the HPN-SSH project seems to be very low on resources, is the inclusion of these patches in FreeBSD 9 a commitment by FreeBSD to maintain these patches against stock OpenSSH in the future? Is there any indication that the OpenSSH project will be more willing to consider merging if the patches survive a -STABLE generation in FreeBSD? ___ 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 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 postmas...@multiplay.co.uk. ___ 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: HPN-SSH question
On 14. Jan 2012, at 23:56 , Steven Hartland wrote: On a similar note I'm actually quite concerned by the inclusion of these patches by default in the OS version of ssh as we've seen several cases of it causing noticeable performance degradation instead of improvement. I've not tested on 9, but this was certainly the case on 8.2. 8.2 did not shipped them so you had installed them yourself? What kind of performance degradations and in which kind of environment an how noticeable? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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
UFS corruption panic
Guys Is a panic **really** appropriate for a filesystem that isn't even in fstab? ie; panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry Which happened to be an file-backed md volume that got changed as I forgot to unmount it beforehand, however as a result there is now inconsistencies and probably data corruption or even missing data on other important filesystems (ie; /, /var etc) because there wasn't even a sync or any kind of other sensible behaviour. This is on a production box, which also has gmirror so I now have no idea what state it's going to be in when I can get a display attached. Surely the appropriate response here for non-critical filesystems is to warn and suggest manually inspecting it as turning a working production box into one thats dead in the water seems a little extreme. J ___ 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
UFS corruption panic
Guys Is a panic **really** appropriate for a filesystem that isn't even in fstab? ie; panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry Which happened to be an file-backed md volume that got changed as I forgot to unmount it beforehand, however as a result there is now inconsistencies and probably data corruption or even missing data on other important filesystems (ie; /, /var etc) because there wasn't even a sync or any kind of other sensible behaviour. This is on a production box, which also has gmirror so I now have no idea what state it's going to be in when I can get a display attached. Surely the appropriate response here for non-critical filesystems is to warn and suggest manually inspecting it as turning a working production box into one thats dead in the water seems a little extreme. J ___ 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: UFS corruption panic
On Sat, Jan 14, 2012 at 8:20 PM, Joe Holden jwhli...@gmail.com wrote: Guys Is a panic **really** appropriate for a filesystem that isn't even in fstab? ie; panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry Which happened to be an file-backed md volume that got changed as I forgot to unmount it beforehand, however as a result there is now inconsistencies and probably data corruption or even missing data on other important filesystems (ie; /, /var etc) because there wasn't even a sync or any kind of other sensible behaviour. This is on a production box, which also has gmirror so I now have no idea what state it's going to be in when I can get a display attached. Surely the appropriate response here for non-critical filesystems is to warn and suggest manually inspecting it as turning a working production box into one thats dead in the water seems a little extreme. That's usually the sign that something went bonkers with the underlying filesystem to the extent that it's corrupt beyond all repair. In this case though, I wouldn't necessarily say that the md-backed filesystem is the one that's corrupt -- it might be the root filesystem. What version of FreeBSD are you using and what do you have enabled in the filesystem (FFS, UFS1, UFS2, SU, SUJ..)? 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 Thu, 12 Jan 2012 08:15:50 -0500 John Baldwin j...@freebsd.org 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 Sorry for the late follow-up, just got the system up and running yesterday. It appears that choosing a different mirror did the trick. Thanks for all the positive insight from everyone who responded. I learned some valuable information, and new ways of doing things along the way. Have A Great Week! Rob -- Rob Clark rpcl...@tds.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: GENERIC make buildkernel error / fails - posix_fadvise
On Sun, Jan 15, 2012 at 02:24:41AM -0500, Rob Clark wrote: On Thu, 12 Jan 2012 08:15:50 -0500 John Baldwin j...@freebsd.org 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 Sorry for the late follow-up, just got the system up and running yesterday. It appears that choosing a different mirror did the trick. Can you please disclose what cvsup mirror you were using? This kind of problem may be affecting other people, so you may want to report it to freebsd-h...@freebsd.org to make the maintainer of the mirror aware. Otherwise, corruption (for lack of better term) between what's in /var/db/sup and what's on your filesystem is something I've seen before, particularly when changing release tags in a supfile. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 freebsd-stable-unsubscr...@freebsd.org
