Re: duration of buildworld
On Mon, Jul 27, 2015 at 08:47:04PM +0200, Matthias Apitz wrote: This pointed in the right direction. I have had 6x 1 GByte additional swap partitions to plain files mounted Swap devices are used in an interleaved fashion. By having multiple file-backed swap devices on (presumably) the same disk, you are multiplying the disk thrashing that happens when you swap. This could slow things down quite a bit. Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libarchive / bsdtar bug
Hi, I just got bit by this bug in bsdtar: https://github.com/libarchive/libarchive/issues/464 Since libarchive 3.1.2 is over 2 years old now and there have not been any more releases, what is the right way of going about reporting a fixed bug so that the FreeBSD version gets a patch downstream? Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: unbound crashes on bootup
On Fri, Feb 06, 2015 at 01:06:03PM +, Poul-Henning Kamp wrote: I just updated my -current to r278283, and unbound (still) croaks during bootup: Feb 6 13:00:54 critter dhclient: New Broadcast Address (wlan0): 192.168.60.255 Feb 6 13:00:54 critter dhclient: New Routers (wlan0): 192.168.60.1 Feb 6 13:00:54 critter kernel: pid 515 (unbound), uid 59: exited on signal 11 Feb 6 13:00:58 critter ntpd_initres[769]: host name not found: pool.ntp.org No core file... You can get unbound to leave a core in /var/unbound by setting kern.sugid_coredump=1 . I found that sometimes (like on a hup and sometimes when interfaces go up/down) unbound would crash, which I tracked down to getpwnam() not having a /etc/pwd.db to use in the chroot. The latest version of unbound appears to have made a lot of changes in that particular place, getpwnam() doesn't even appear in that file anymore. I submitted a bug report for the crash that I found, I don't know if it's related to yours. Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: unbound crashes on bootup
On Wed, Feb 11, 2015 at 07:06:04PM +0100, Jean-Sébastien Pédron wrote: On 06.02.2015 14:06, Poul-Henning Kamp wrote: I just updated my -current to r278283, and unbound (still) croaks during bootup: Hi! I have a similar problem. Also, unbound crashes each time I start/stop OpenVPN. I suppose the problem is the same in both cases. The crash happens in the config_lookup_uid() in contrib/unbound/util/config_file.c. Here's the code: struct passwd *pwd; if((pwd = getpwnam(cfg-username)) == NULL) log_err(user '%s' does not exist., cfg-username); cfg-uid = pwd-pw_uid; getpwnam(3) returns NULL: an error message is logged but the function doesn't return. Therefore, the program segfaults on pwd-pw_uid on the next line. The reason this crash happens is that unbound is chrooted and there is no /etc/pwd.db for getpwnam() to look at. A workaround is to mkdir /var/unbound/etc and put a copy of /etc/pwd.db into it (or even a reduced version that only contains the unbound user). I submitted a bug report for this yesterday. Marcus But why did getpwnam(3) return NULL in the first place? It looks for the unbound user which exists. getpwnam() calls _nsdispatch() which fails. I have the default nsswitch.conf. I didn't look at the problem more deeply yet, but could getpwnam()/_nsdispatch() be unhappy with the absence of a working DNS resolver (unbound is being (re)started)? -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Delayed atime updates (lazytime)
Hi, Looks like Linux is about to grow another solution to handling atime updates differently: http://lwn.net/SubscriberLink/621046/e59938475fd3e874/ In short, it will only write out atime changes periodically (daily), or if there is another reason to write out the inode, or if the inode is about to be pushed out of cache. This seems like a pretty good compromise. Currently, the ZFS configuration that results from using bsdinstall disables atime on all but /var/mail, which is the only example of disabling atime by default that I'm aware of outside of Gentoo Linux. I can't seem to find any information that talks about the rationale behind that, though a couple things come to mind: - some additional IO generated (but that's always been the case) - additional wear on SSD devices (enough to compel the change?) - zfs snapshot growth (but the snapshot stops growing after one full set of inode updates) - wake up otherwise idle spinning media on a laptop (the actual reason that was cited as motivation for the change) Something like lazytime would address most of those concerns, and people who are even more OCD than that could disable atime completely on their machine. Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
On Tue, Nov 04, 2014 at 06:13:44PM +, Steven Hartland wrote: On 04/11/2014 17:22, Allan Jude wrote: snip... Justin Gibbs and I were helping George from Voxer look at the same issue they are having. They had ~169GB in inact, and only ~60GB being used for ARC. Are there any further debugging steps we can recommend to him to help investigate this? The various scripts attached to the ZS ARC behavior problem and fix PR will help provide detail this. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 I've seen it here where there's been bursts of ZFS I/O specifically write bursts. What happens is that ZFS will consume large amounts of space in various UMA zones to accommodate these bursts. If you push the vmstat -z that he provided through the arc summary script, you'll see that this is not what is happening. His uma stats match up with his arc, and do not account for his inactive memory. uma script summary: Totals oused: 5.860GB, ofree: 1.547GB, ototal: 7.407GB zused: 56.166GB, zfree: 3.918GB, ztotal: 60.084GB used: 62.026GB, free: 5.465GB, total: 67.491GB His provided top stats: Mem: 19G Active, 20G Inact, 81G Wired, 59M Cache, 3308M Buf, 4918M Free ARC: 66G Total, 6926M MFU, 54G MRU, 8069K Anon, 899M Header, 5129M Other The big uma buckets (zio_buf_16384 and zio_data_buf_131072, 18.002GB and 28.802GB respectively) are nearly 0% free. Marcus The VM only triggers UMA reclaim when it sees pressure, however if the main memory consumer is ZFS ARC its possible that the require pressure will not be applied because when allocating ARC ZFS takes into account free memory. The result is it will back off its memory requirements before the reclaim is triggered leaving all the space allocated but not used. I was playing around with a patch, on that bug report, which added clear down of UMA within ZFS ARC to avoid just this behavior, but its very much me playing for testing the theory only. From what I've seen UMA needs something like the coloring which can be used to trigger clear down over time to prevent UMA zones sitting their eating large amounts of memory like they currently do. Regards Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r270287: crash
On Thu, Aug 21, 2014 at 09:26:19PM +0200, O. Hartmann wrote: FreeBSD r270287 crashes/reboots instantanously on loading the kernel. I can not see at what point (on modern systems like Ivy Bridge). On older Core2Duo systems I get a trap 12 in APIC or similar. Are you using VirtualBox? I just fixed a crash that fits your description by recompiling virtualbox-ose-kmod. Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wlan0/iwn: no upload statistics
On Sat, Jun 07, 2014 at 11:26:39AM +0200, Stefan Ehmann wrote: Network monitoring tools show download traffic, but no upload data. I have an iwn0: Intel WiFi Link 5100 and have the same problem. I was able to track it down to being some missing ifmib(4) data, secifically ifi_obytes from the if_data structure (see ifnet(9)). This was a little while back, and I seem to remember someone else with using iwn that didn't have the problem. Another thing is that if you do a 'netstat -I wlan0 -i 1', output bytes are missing, but if you look at iwn0 instead all you see is the output bytes and nothing else (except sometimes you get some numbers in the output packets column seemingly at random). Marcus systat -ifstat output: Interface Traffic PeakTotal wlan0 in 1.066 KB/s 16.155 KB/s 377.757 MB out 0.000 KB/s 0.000 KB/s0.000 KB Tested on amd64 CURRENT from few days ago. netword Card is: iwn0: Intel Centrino Ultimate-N 6300 mem 0xf200-0xf2001fff irq 17 at device 0.0 on pci3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wlan0/iwn: no upload statistics
On Wed, Jun 11, 2014 at 09:06:45PM +0800, bycn82 wrote: Just tell the command is not working cannot help in resolving the problem. Could you please provide more detail? for example. I already gave the info that I have. In this case the data provided by the sysctl that gets interface statistics is incomplete. systat -ifstat shows: wlan0 in 0.000 KB/s 0.000 KB/s 82.933 MB out 0.000 KB/s 0.000 KB/s0.000 KB In the systat case, it appears to poll each interface with a: 20966 systat SCTL net.link.generic.ifdata.3.1 netstat -I wlan0 -i 1 shows: input wlan0 output packets errs idrops bytespackets errs bytes colls 7 0 0 5010 7 0 0 0 15 0 0 10378 15 0 0 0 22 0 0 14164 18 0 0 0 21 0 0 13058 19 0 0 0 ... Note that there are output packets, but not output bytes listed. netstat appears to use netgraph for its data, so both the sysctl and netgraph methods of getting the data is affected similarly. This is where the trail went cold for me. I tried looking at the iwn driver sources but did not find the place where any counters in the kernel are updated. Maybe someone more familiar with the way network drivers are written would have better luck. I had written it off as a hardware quirk when I looked into it, but it looks like more than just my wireless card is affected. Marcus 1. Firewall can tell you the total in/out traffic 2. The systat -ifstat result. 3. Netstat information In previous email, the guy provided the below information. systat -ifstat output: Interface Traffic PeakTotal wlan0 in 1.066 KB/s 16.155 KB/s 377.757 MB out 0.000 KB/s 0.000 KB/s0.000 KB Can you please confirm whether the 377.757 MB is `in` or `out` traffic? -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Marcus Reid Sent: 11 June, 2014 18:05 To: Stefan Ehmann Cc: freebsd-current@freebsd.org Subject: Re: wlan0/iwn: no upload statistics On Sat, Jun 07, 2014 at 11:26:39AM +0200, Stefan Ehmann wrote: Network monitoring tools show download traffic, but no upload data. I have an iwn0: Intel WiFi Link 5100 and have the same problem. I was able to track it down to being some missing ifmib(4) data, secifically ifi_obytes from the if_data structure (see ifnet(9)). This was a little while back, and I seem to remember someone else with using iwn that didn't have the problem. Another thing is that if you do a 'netstat -I wlan0 -i 1', output bytes are missing, but if you look at iwn0 instead all you see is the output bytes and nothing else (except sometimes you get some numbers in the output packets column seemingly at random). Marcus systat -ifstat output: Interface Traffic PeakTotal wlan0 in 1.066 KB/s 16.155 KB/s 377.757 MB out 0.000 KB/s 0.000 KB/s0.000 KB Tested on amd64 CURRENT from few days ago. netword Card is: iwn0: Intel Centrino Ultimate-N 6300 mem 0xf200-0xf2001fff irq 17 at device 0.0 on pci3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wlan0/iwn: no upload statistics
On Thu, Jun 12, 2014 at 01:47:06AM -0400, Marcus Reid wrote: On Wed, Jun 11, 2014 at 09:06:45PM +0800, bycn82 wrote: Just tell the command is not working cannot help in resolving the problem. Could you please provide more detail? for example. I already gave the info that I have. In this case the data provided by the sysctl that gets interface statistics is incomplete. systat -ifstat shows: wlan0 in 0.000 KB/s 0.000 KB/s 82.933 MB out 0.000 KB/s 0.000 KB/s0.000 KB This was sort of a bad paste, I did it when there was no current activity. The 'in' side looks fine normally. Here's another one with activity: wlan0 in 11.364 KB/s 71.956 KB/s 95.683 MB out 0.000 KB/s 0.000 KB/s0.000 KB There's definitely output, just not accounted for on the 'wlan0' interface. If you look at iwn0, there it is: netstat -I iwn0 -i 1 shows: input iwn0 output packets errs idrops bytespackets errs bytes colls 0 0 0 0 64 0 9456 0 0 0 0 0 78 0 11354 0 0 0 0 0 54 0 8160 0 0 0 0 0 46 0 7656 0 0 0 0 0 56 0 8158 0 Marcus In the systat case, it appears to poll each interface with a: 20966 systat SCTL net.link.generic.ifdata.3.1 netstat -I wlan0 -i 1 shows: input wlan0 output packets errs idrops bytespackets errs bytes colls 7 0 0 5010 7 0 0 0 15 0 0 10378 15 0 0 0 22 0 0 14164 18 0 0 0 21 0 0 13058 19 0 0 0 ... Note that there are output packets, but not output bytes listed. netstat appears to use netgraph for its data, so both the sysctl and netgraph methods of getting the data is affected similarly. This is where the trail went cold for me. I tried looking at the iwn driver sources but did not find the place where any counters in the kernel are updated. Maybe someone more familiar with the way network drivers are written would have better luck. I had written it off as a hardware quirk when I looked into it, but it looks like more than just my wireless card is affected. Marcus 1. Firewall can tell you the total in/out traffic 2. The systat -ifstat result. 3. Netstat information In previous email, the guy provided the below information. systat -ifstat output: Interface Traffic PeakTotal wlan0 in 1.066 KB/s 16.155 KB/s 377.757 MB out 0.000 KB/s 0.000 KB/s0.000 KB Can you please confirm whether the 377.757 MB is `in` or `out` traffic? -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Marcus Reid Sent: 11 June, 2014 18:05 To: Stefan Ehmann Cc: freebsd-current@freebsd.org Subject: Re: wlan0/iwn: no upload statistics On Sat, Jun 07, 2014 at 11:26:39AM +0200, Stefan Ehmann wrote: Network monitoring tools show download traffic, but no upload data. I have an iwn0: Intel WiFi Link 5100 and have the same problem. I was able to track it down to being some missing ifmib(4) data, secifically ifi_obytes from the if_data structure (see ifnet(9)). This was a little while back, and I seem to remember someone else with using iwn that didn't have the problem. Another thing is that if you do a 'netstat -I wlan0 -i 1', output bytes are missing, but if you look at iwn0 instead all you see is the output bytes and nothing else (except sometimes you get some numbers in the output packets column seemingly at random). Marcus systat -ifstat output: Interface Traffic PeakTotal wlan0 in 1.066 KB/s 16.155 KB/s 377.757 MB out 0.000 KB/s 0.000 KB/s0.000 KB Tested on amd64 CURRENT from few days ago. netword Card is: iwn0: Intel Centrino Ultimate-N 6300 mem 0xf200-0xf2001fff irq 17 at device 0.0 on pci3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe
Re: Defaults in 10.0 ZFS through bsdinstall
On Thu, Nov 14, 2013 at 06:35:43PM +, Teske, Devin wrote: On Nov 14, 2013, at 10:21 AM, Allan Jude wrote: On 2013-11-14 9:34, Reid, Marcus wrote: Hi, I noticed a couple of things with the ZFS defaults that result from using the new installer in 10.0-BETA3. One, atime is turned off everywhere by default. There was a thread on this list on June 8 with a subject of 'Changing the default for ZFS atime to off?', and from what I can tell the idea of turning off atime by default was not a popular one. Two, and probably less controversial, is that fletcher4 is specified exlicitly on the root pool, even though it is default (wouldn't you just want to go with the default, in case it changes?) Marcus I have never heard a good argument for having atime on. Can you address some of the issues that people brought up in the thread I mentioned earlier? I'll summarize some: - breaks some software (MTAs were mentioned), and the admin should know when to turn atime on in those cases. - any mail program using mbox mail folders uses them to correctly report which mailboxes have not been read yet - Of course it can't be turned off by default. It is specified by POSIX. - If the overhead were a real problem then file systems would use a special atime cache The performance penalty on ZFS is quite large This is subjective, and if it were that bad it seems like other ZFS-based systems would have turned it off as well, or done something like caching/logging or relatime it to mitigate the performance hit. and it also makes your snapshots grow constant. This does not seem to be the case. For example, if I snapshot zroot/usr/src and then tar it up, I generate a bunch of writes and the snapshot grows to 70.5MB. However, when I tar it up a second time, there are writes but the snapshot remains 70.5MB. It seems to use the same blocks for subsequent atime updates. If you made another snapshot, you would see more space used for that one, of course. If you have a use for it, you can turn it on I guess. This would be solved by having the dataset editor we're planning for 10.1 Seems easy enough to turn on once installed. And like Allan says, the editor for 10.1 would allow changing of the default. The same case could be made for turning it off, make that an option in the installer instead. Some people don't seem to use atime on a regular basis, but I use it a lot when troubleshooting things, and I think others do to when they get to the point where they realize how useful it is. I'll add that if scripting it, you can (in current state for 10.0) change the dataset options at-will. The fletcher4 thing is a leftover, from older versions of ZFS where the default was fletcher2, I suppose we can remove it While I'm picking nits: There are some other locally set things that are default (exec set to on on zroot/var/tmp is one), that might just inherit that from zroot/var. Also, zroot doesn't appear to be mounted on /zroot, as it is on other ZFS-based systems. This has the side-effect of newly created datasets not having a mountpoint by default, instead of /zroot/dataset. I don't know of the reason behind this change either. I'm going to cross-post this to -current, this is a topic that I think warrants a wider audience. Thanks, Marcus Let me put something together. - -- Devin -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJShRf/AAoJEKrMn5R9npq5TYwH/j8RMceM4STpCAoMTAz8zkKn gpftMrdf37TnAPHxsXJaiZejlp+D85/a9lglYbB7e4WdgoDX9ZXA0QLtCEmEtN4y jz7KNa5oABq1GjDtwm2xQISDIe8yYI+znLSaHA9W18kCUZzi8AOj70C+O5gyY28c c3N3j6Y4EZP2wtQnWSgxvCwIX5p86Jvr3QvhrRuuMnKMCTAhzwIx24qcnA4EcTzn p9w25CKLtOzF23n3McodaUmibbBCHOYyraLQJ+eJGDXcsPBipls3oiWyiYuqpcQr 18QpLN1lS35RnULcb5pxnP9Oy9rAwxHKves9Mfu0UoWw3qTjSAf8gsGyu6QaMgc= =GjYk -END PGP SIGNATURE- _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT ( r249381): can't find boot partition on GPT disk
On Sat, Apr 13, 2013 at 09:14:10AM +0200, O. Hartmann wrote: Trying to boot a kernel r249381 fails and I see on the console the loader prompt at mountroot. Obviously, the bootloader doesn't find the root/boot partition. Same problem observed here. r249435, gpt zfs root. Entering zfs:zroot at the mountroot prompt allows system to continue booting. Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On Mon, Dec 12, 2011 at 04:29:14PM -0800, Doug Barton wrote: On 12/12/2011 05:47, O. Hartmann wrote: Do we have any proof at hand for such cases where SCHED_ULE performs much better than SCHED_4BSD? I complained about poor interactive performance of ULE in a desktop environment for years. I had numerous people try to help, including Jeff, with various tunables, dtrace'ing, etc. The cause of the problem was never found. The issues that I've seen with ULE on the desktop seem to be caused by X taking up a steady amount of CPU, and being demoted from being an interactive process. X then becomes the bottleneck for other processes that would otherwise be interactive. Try 'renice -20 pid_of_X' and see if that makes your problems go away. Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Vinum breakage - please update UPDATING
Hello, I just upgraded a -CURRENT box this afternoon to discover that vinum is broken. If I hadn't done dumps of my working world beforehand I would be in pretty sad shape. Should UPDATING make note of this breakage? It would have saved me some embarassment, and I'm sure others are about to clobber their machines. Marcus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vinum breakage - please update UPDATING
Hi Greg, On Sat, Nov 22, 2003 at 11:05:38AM +1030, Greg 'groggy' Lehey wrote: On Friday, 21 November 2003 at 15:42:12 -0800, Marcus Reid wrote: Hello, I just upgraded a -CURRENT box this afternoon to discover that vinum is broken. If I hadn't done dumps of my working world beforehand I would be in pretty sad shape. Should UPDATING make note of this breakage? No. UPDATING is for things that will change relatively permanently. Ah, OK. Thanks; I had no idea how long it was expected to be broken. It would have saved me some embarassment, and I'm sure others are about to clobber their machines. As far as I can tell, this breakage doesn't harm the data. Others have reported that it works on older versions of CURRENT. I hope to have it fixed this weekend. FYI, it didn't destroy any data. vinum dumpconfig reported everything was fine, but there was no mount point in /dev/vinum. When I reverted to an earlier -CURRENT snapshot, it worked without a hitch. Thanks for the response; I should not have shouted so loudly about updating UPDATING. I just wish I had read the CURRENT list before shooting myself in the foot. Sincerely, Marcus Greg -- See complete headers for address and phone numbers. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld fails
On Mon, Nov 17, 2003 at 01:04:33AM +0100, Aron H?kanson wrote: S?n 2003-11-16 klockan 21.12 skrev Peter Ulrich Kruppa: Hi! I have a problem with today's sources. At my first try make buildworld and make kernel worked all-right and the new kernel could be booted, so I didn't check closely and made installworld. This failed *somewhere* , and now I am left with a defect system: no internet connection, no XFree86 and perhaps some more things I haven't found yet. Next I deleted /usr/obj/usr and /usr/src and cvsupped fresh sources (via a a basic 4.8 -RELEASE I have got on the same machine), but now buildworld fails very soon with ... sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/us r/src/i386/legacy/usr/lib *** Signal 11 There is a problem with the old install program when you make the installworld with the new sources. You can solve this by installing the new install program from the obj-directory. Just copy the /usr/obj/usr/src/usr.bin/xinstall/xinstall to /usr/bin/install (ev. a chmod 555 too) and it should work. If you don't already have a binary to work with, do a: cd /usr/src/usr.bin/xinstall make all Then copy the resulting xinstall binary over /usr/bin/install. Marcus Aron ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mysql-client compiler error
Hello,
On Mon, Sep 15, 2003 at 11:42:29AM +1000, Mark Sergeant wrote:
I get the same problem in the same place with current as of today.
I also noticed this issue. I just got a reply from the port maintainer
Alex Dupre as follows:
MR It won't configure. Output on my machine is as below.
I'm aware of this problem...It's due to the removal of -pthread gcc
options in -current. I'll create a patch to fix it, in the meanwhile
you may replace every instance of -pthread with ${PTHREAD_LIBS} in all
configure(s).
Marcus
Cheers,
Mark
On Sat, 2003-09-13 at 20:37, Matt wrote:
After building world as of late last night I decided to portupgrade
-rRaf, mainly due to having the libintl.so.4 missing problem when I
tried to start X. Everything compiled perfectly fine (and X is now
working fine) except for databases/mysql40-client. I get this error:
checking for C compiler default output... configure: error: C compiler
cannot create executables
configure: error: could not configure Berkeley DB
I just wish to know is this something wrong with my system in general or
is this just due to the -pthread discussions that have been occuring and
that this port is one example of those that no longer works on -current?
It is not a problem as I have the previously compiled/installed version
still on the system but I just wish to confirm if the problem is likely
to be down to the pthreads changes, and if I should report it to the
port maintainer etc?
Matt.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Sergeant [EMAIL PROTECTED]
SNSOnline Technical Services
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Current issues
Hi: I made the jump to CURRENT this morning (via a fresh -RC1 install) and made the following observations. 1. Thought I toggled newfs off on the partition where /home was mounted. It went ahead and zapped it anyway. Good thing for backups.. 2. USB doesn't work with my chipset. I have an Asus A7V with VIA chipset. Kernel messages follow. Please contact me if I can assist in debugging. Otherwise, smooth sailing. I'm sure I'll break something else soon :) Marcus uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 9 at device 4.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 9 at device 4.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 uhub2: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 uhub2: 4 ports with 4 removable, self powered To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Current issues
On Wed, Dec 11, 2002 at 08:59:04AM -0800, Marcus Reid wrote: Hi: 2. USB doesn't work with my chipset. I have an Asus A7V with VIA chipset. Kernel messages follow. Please contact me if I can assist in debugging. Looks like I spoke too soon. It doesn't work with the RC1 GENERIC kernel, but after a cvsup and a build it's fine. I'll try to break something real next time. Marcus To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
