Re: ports binary upgrade question for 9.2
On Tue, Oct 01, 2013 at 06:32:37PM +0200, Zoran Kolic wrote: Due to trip to make, I will have to wait few days to upgrade my nodes to 9.2 release. But, I'd like to learn the easiest way to handle ports. You don't have to recompile all ports when switching to a new _minor_ version. Minor versions are binary compatible. So in this case you don't have to do anything. Only when changing to a new major version (e.g. from 9.x to the upcoming 10.0) it is advised to delete all ports and then re-install them, because e.g. shared library versions can change. Roland -- R.F.Smith http://rsmith.home.xs4all.nl/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpHemJxKYTRN.pgp Description: PGP signature
Re: Clang as default compiler
On Wed, Sep 19, 2012 at 02:13:41PM -0400, Gary Palmer wrote: Rxvt-unicode seemed to crash reliably whenever I was scrolling through a document with less(1). If I reached the end of the document, and pressed Page Down (keysim Next), it would crash. It was quite weird. That sounds like the bell was doing it. If you do CTRL-G (or something else that makes a beep) from the shell prompt in rxvt-unicode does it also crash? Now there's an idea. Now that you mention it, I don't recall hearing the bell at that time. I'll recompile with clang and test it over the weekend. Roland -- R.F.Smith http://rsmith.home.xs4all.nl/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpE6FRUera6D.pgp Description: PGP signature
Re: Clang as default compiler
On Tue, Sep 18, 2012 at 12:02:20AM +0200, Dimitry Andric wrote: On 2012-09-17 21:43, Roland Smith wrote: On Wed, Sep 12, 2012 at 01:04:20AM -0500, Mark Linimon wrote: ... For most of the failures, we are already aware of them, as a result of our periodic runs. So, just filing a PR to say broken on clang doesn't really help us all that much. Those are build failures. What about crashes? E.g. I've recently had crashes with x11-wm/i3 and x11/rxvt-unicode. Both problems disappeared after recompiling them with gcc46. We can't figure them all out without *your* help. :-) Please attempt to run the program in a debugger, gather core dumps, etc. Or at least, try to make it into a reproducible case, so somebody else can attempt to diagnose it. And please specify the exact version of clang you used. I was using the clang that is in base in 9.0-RELEASE-p3: FreeBSD clang version 3.0 (branches/release_30 142614) 20111021 Target: x86_64-unknown-freebsd9.0 Thread model: posix I was thinking of installing the most recent clang-devel since it seemed to have a lot of improvements, but I was wondering what is the correct way of makeing sure that it is used in preference to the one in base? I thought about moving /usr/local/bin before /usr/bin in $PATH, but I'm not sure that is a good idea. Now, most of the time this is because programs contain bugs, or undefined behavior, which happens to go unnoticed with gcc, for example because it optimized by accident in such a way to mask the bug. In a few other cases, real clang bugs are found, and most of the time, those can be fixed quickly. That said, in these cases specifically, how do the applications crash? Right at startup, or after specific inputs or user actions? Rxvt-unicode seemed to crash reliably whenever I was scrolling through a document with less(1). If I reached the end of the document, and pressed Page Down (keysim Next), it would crash. It was quite weird. I couldn't pinpoint a concrete action that crashed x11-wm/i3. Roland -- R.F.Smith http://rsmith.home.xs4all.nl/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpujqeF2YDzn.pgp Description: PGP signature
Re: Clang as default compiler
On Wed, Sep 12, 2012 at 01:04:20AM -0500, Mark Linimon wrote: On Tue, Sep 11, 2012 at 11:49:24PM +0200, Andreas Nilsson wrote: Is there a specif PR to use for ports that fails with clang and does not specify to use gcc ( devel/cdecl and deskutils/calibre so were the culprits so far) There is no specific PR. We have not yet placed the requirement on our ports maintainers to deal with clang. For most of the failures, we are already aware of them, as a result of our periodic runs. So, just filing a PR to say broken on clang doesn't really help us all that much. Those are build failures. What about crashes? E.g. I've recently had crashes with x11-wm/i3 and x11/rxvt-unicode. Both problems disappeared after recompiling them with gcc46. Roland -- R.F.Smith http://rsmith.home.xs4all.nl/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpI9WK6wuK68.pgp Description: PGP signature
Re: WITHOUT_JAIL and make delete-old{,-libs}
On Mon, Mar 21, 2011 at 08:26:19AM +0100, Alexander Leidinger wrote:
Quoting David Demelier demelier.da...@gmail.com (from Mon, 21 Mar
2011 07:04:18 +0100):
On 20/03/2011 17:31, Alexander Leidinger wrote:
On Sun, 20 Mar 2011 08:34:51 +0100 David Demelier
demelier.da...@gmail.com wrote:
Hello,
I was surprised to see there is no ${MK_JAIL} conditional to remove
old files on 8.2-RELEASE so I started to write it without watching if
-CURRENT already make it in
/usr/src/tools/build/mk/OptionalObsoleteFiles.inc.
.if ${MK_JAIL} == no
I think they should be removed too, thus can you merge it to -STABLE
if it's not already done? (sorry I'm not used to the cvs web
interface and I don't have -STABLE right now)
No I understood why, that's because a lot of userland programs that
can handle jails processes are linked to the libjail such as top,
ifconfig, ...
So it's just about merging to 8-stable.
I made a diff between -current and 8-stable, and there are a lot of
differences. Instead of merging just the entries for the jails, it
would be better to merge nearly everything. The problem is that this
requires a lot of testing (delete old files, installworld, check if
files reappear - need to be removed from the list to remove with
delete-old/-libs) and the libs need to be checked for the correct
version number too.
Some months ago, I submitted an PR with an update for
tools/build/mk/OptionalObsoleteFiles.inc;
http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/149360
I added stuff to it by looking at the options in src.conf(5) and running 'make
-n install' in the relevant kernel directory and noting what was
installed. The original file I started from (1.20.2.2.2.1 from 2010/06/14) was
1162 lines. My enhanced version is 2610 lines.
Maybe you can use this?
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpb4vDM6mb0D.pgp
Description: PGP signature
Re: Freebsd 8.1 + xorg + radeonhd hang
On Mon, Sep 13, 2010 at 10:16:48PM +0200, Oliver Fromme wrote: Eivind E eivi...@terraplane.org wrote: One of my machines has a Radeon X1550 graphics card. When first installed (then as either 7.1 or 7.1 prerelease), the radeonhd driver hung the machine hard, screen went blank, numlock and capslock didn't work, no network (so no ssh) and I couldn't do much but hard reset the machine. I had to use vesa for a while, then, after upgrading, the radeonhd driver worked up until fairly recent upgrades. Sadly I didn't try the driver very often so I don't know if upgrading src or xorg+drivers helped the problem. The machine is now running FreeBSD 8.1, but after rebuilding all packages via ports, the problem with the radeonhd driver is back, showing exactly the same behaviour as before. Did you try the normal radeon driver (not radeonhd)? It supports the RV515 chip used by the X1550, too. Keep in mind that normal radeon driver is called x11-drivers/xf86-video-ati now. If you load the drm.ko and radeon.ko (and maybe agp.ko) kernel models with this driver, you'll have accellerated 3D as well as 2D (both XAA and the newer EXA). Works like a charm on my Radeon X 1650 Pro, and should work with your card as well. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpnmE0QnXCBF.pgp Description: PGP signature
Re: Freebsd 8.1 + xorg + radeonhd hang
On Tue, Sep 14, 2010 at 12:04:16AM +0200, Eivind E wrote: On Mon, 13 Sep 2010, Roland Smith wrote: snip Did you try the normal radeon driver (not radeonhd)? It supports the RV515 chip used by the X1550, too. Keep in mind that normal radeon driver is called x11-drivers/xf86-video-ati now. If you load the drm.ko and radeon.ko (and maybe agp.ko) kernel models with this driver, you'll have accellerated 3D as well as 2D (both XAA and the newer EXA). Works like a charm on my Radeon X 1650 Pro, and should work with your card as well. Tried to substitute the driver with ati and loading radeon.ko (which automatically loaded drm.ko) and had the same results as the plain radeon driver. X starts up once in a while, but the screen goes to about half of normal brightness and the view is moved down and to the right. Do you have a modeline in your xorg.conf? If so, try taking it out. Or try running 'X -configure' from the console to generate a new basic xorg.conf. Some monitors come with a button or control to automatically tune them to the video source. If you have that it might help as well. If not, try x11/xvidtune. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp09GyYzCMIr.pgp Description: PGP signature
Re: Inconsistent IO performance
On Sun, Aug 15, 2010 at 12:37:03PM -0700, Kevin Oberman wrote: OK. It's pretty clear that disk IO is terrible on this system. I suspect it's the SATA/PATA converter that is the throttle. In any case, snip I still have no explanation for the variation. It's not vibration. Some of my best times were while the system was sitting in my trunk while commuting from my home to work. So have some of the worst. If the performance is craptastic due to the SATA/PATA convertor, could that also not be a good explanation for the variation? With the different speeds on the two busses, there might well be variation between the time it takes for commands to get through (altough one would expect that to even out over time). Of course to test that you'd have to hook up a harddisk that doesn't need the convertor... If that improves the situation, you've found the problem. I can only hope that my next laptop, which should have ACHI, will improve the situation. I'll probably be getting a new laptop in the spring, so it won't be too long. Almost time to start trying to figure out what to buy. Well, looking at my laptop's figures, it is possible to get good throughput. If you get a system with ICH9 chipset (so you can use ahci(4)), and a 7200 RPM harddisk, and you should be able to reproduce my figures, I think. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgppj3TD0PwJ9.pgp Description: PGP signature
Re: Inconsistent IO performance
On Sat, Aug 14, 2010 at 02:36:31AM +0200, Roland Smith wrote: On Fri, Aug 13, 2010 at 01:36:12PM -1000, Clifton Royston wrote: Both figures seem quite low to me? I cannot exactly reproduce your test, because I don't have an empty second disk handy, but doing dd if=/dev/zero bs=1m count=100 of=/tmp/foo With a total write size of 100MB, aren't you just testing speed of writing into cache RAM this way? I think you need to write amounts dramatically greater than the total size of the RAM to get values which appropriately measure disk speed. snip This also supports that theory - off the top of my head, maximum theoretical possible write throughput to a similarly sized 7200rpm drive should be 70MB/s (buffer to disk data transfer rate according to WDC's specs.) http://wdc.com/en/library/sata/2879-701277.pdf Ok, so I tried this; dd if=/dev/zero of=/tmp/foo bs=10M count=1000 1048576 bytes transferred in 138.304953 secs (75816229 bytes/sec) 1048576 bytes transferred in 139.125501 secs (75369073 bytes/sec) 1048576 bytes transferred in 136.149871 secs (77016305 bytes/sec) Which is around 72 MiB/s with filesystem overhead, which sounds about right. The drive was making plenty of noise. The point is that it is _way_ more than the 18-22 MiB/s on a raw disk that Kevin is getting. I'll try the same on my laptop topmorrow and see what that gets me. This desktop machine is ICH7 with ata(4), laptop is ICH9 with ahci(4). Figures from the laptop running 8.1-RELEASE amd64, ahci driver with the following harddisk; ada0: ST9320423AS 0002SDM1 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) Running the same test; dd if=/dev/zero of=/tmp/foo bs=10M count=1000 Gives the following results. 1048576 bytes transferred in 122.625997 secs (85510090 bytes/sec) 1048576 bytes transferred in 126.081170 secs (83166741 bytes/sec) 1048576 bytes transferred in 126.101845 secs (83153105 bytes/sec) Which is about 10% faster than on the desktop. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpPCf0xQAOsM.pgp Description: PGP signature
Re: Inconsistent IO performance
On Fri, Aug 13, 2010 at 09:01:09AM -0700, Kevin Oberman wrote: For some time I have seen very odd issues with IO performance on 8-Stable. Going back to November of last year when 8.0 was released, I see variations of up to 22% in identical operations. This is not a degradation as the performance moves up and down. This is a very simplistic case. I have two identical disks (Fujitsu 80G) on a ThinkPad T43 with a 2 GHz CPU and 2G RAM. I run the command: dd bs=516096 if=/dev/ad0 of=/dev/ad2 Why are you using this peculiar block size? Note the dramatic differences even on the same kernel. For the December 6 kernel, for example, I see a maximum of 23,676,086 and a minimum of just 18,304,565. Both figures seem quite low to me? I cannot exactly reproduce your test, because I don't have an empty second disk handy, but doing dd if=/dev/zero bs=1m count=100 of=/tmp/foo yields the following writing speed on 8.1-RELEASE amd64, WDC WD5001ABYS SATA harddisk @ 7200 rpm.: 1) 87263174 bytes/sec 2) 87878728 bytes/sec 3) 86397125 bytes/sec 4) 86550094 bytes/sec 5) 86524741 bytes/sec Th maximum variation in write speed is (87878728-86397125)/86397125*100% = 1.7%, which doesn't seem that much to me. This is in multi-user, with X11 running but on an otherwise idling machine, and with filesystem overhead to boot. Still the numbers are a lot higher than yours, which puzzles me. Trying only reading does yield very inconsistent results because of caching, I think; dd if=/tmp/foo bs=1m count=100 of=/dev/null 1) 1454216957 bytes/sec 2) 1003691691 bytes/sec 3) 1429956761 bytes/sec 4) 2324794646 bytes/sec 5) 1804563681 bytes/sec This is a (2324794646-1003691691)/1003691691*100% = 132% difference. OTOH, your data set should be big enough to negate caching effects, I guess. :-) What this does show is that writing seems to be the bottleneck. If I both read from and write to a file (on the same disk partition); dd if=/tmp/foo bs=1m count=100 of=/tmp/bar gives 1) 85161534 bytes/sec 2) 84978770 bytes/sec 3) 87966613 bytes/sec 4) 83036312 bytes/sec 5) 86536879 bytes/sec This is a (87966613-83036312)/83036312*100% = 5.9% difference between largest and smallest. The speed seems to be dictated by the writing. Can anyone explain what might be causing such a dramatic difference? Maybe there is a hardware component here? Are both disks on the same controller? Or if not are both controllers using the same interrupt line? You should have a look at 'systat -vmstat' with dd running in the background. That might give a clue as to where the bottleneck is. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpCIiJJ5RBhs.pgp Description: PGP signature
Re: Inconsistent IO performance
On Fri, Aug 13, 2010 at 01:36:12PM -1000, Clifton Royston wrote: Both figures seem quite low to me? I cannot exactly reproduce your test, because I don't have an empty second disk handy, but doing dd if=/dev/zero bs=1m count=100 of=/tmp/foo With a total write size of 100MB, aren't you just testing speed of writing into cache RAM this way? I think you need to write amounts dramatically greater than the total size of the RAM to get values which appropriately measure disk speed. snip This also supports that theory - off the top of my head, maximum theoretical possible write throughput to a similarly sized 7200rpm drive should be 70MB/s (buffer to disk data transfer rate according to WDC's specs.) http://wdc.com/en/library/sata/2879-701277.pdf Ok, so I tried this; dd if=/dev/zero of=/tmp/foo bs=10M count=1000 1048576 bytes transferred in 138.304953 secs (75816229 bytes/sec) 1048576 bytes transferred in 139.125501 secs (75369073 bytes/sec) 1048576 bytes transferred in 136.149871 secs (77016305 bytes/sec) Which is around 72 MiB/s with filesystem overhead, which sounds about right. The drive was making plenty of noise. The point is that it is _way_ more than the 18-22 MiB/s on a raw disk that Kevin is getting. I'll try the same on my laptop topmorrow and see what that gets me. This desktop machine is ICH7 with ata(4), laptop is ICH9 with ahci(4). Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpQcBgNGLEyA.pgp Description: PGP signature
Re: 8.0 network problem
On Tue, Jul 06, 2010 at 01:06:25AM -0500, David Warren wrote:
Hi again,
Disabling pf definitely makes samba file transfers move faster (the
speed varies quite a bit, but everything's faster than the single kilobytes
per second I was seeing previously), but I'm perplexed about what's causing
the slowdown. There's certainly some cruft in my pf.conf (below), but I'm
not sure what might be strangling my LAN. Can anyone set me straight?
In general, check which rules are matched most with 'pfctl -vvs rules|less'.
Put the rules that are matched most first in the ruleset, adding the 'quick'
keyword where possible.
There is a FAQ on the OpenBSD site about pf, but it pertains to a newer
version than is available in FreeBSD!
/etc/pf.conf:
# macros
int_if = em0
wifi_if = wlan0
ext_if = nfe0
nat_opt = 192.168.0.5 # Windows box
nat_cu = 192.168.0.1 # server
tcp_services = { 22 }
icmp_types = echoreq
priv_nets = { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
You might want to replace this by a table. It's supposed to be faster;
table priv_nets const { 127/8, 192.168/16, 172.16/12, 10/8 }
# options
You could try and use ruleset optimization;
set ruleset‐optimization profile
set block-policy return
set loginterface $ext_if
set skip on lo
# scrub
scrub in
# nat/rdr
nat on $ext_if from !($ext_if) - ($ext_if:0)
nat on $ext_if from $wifi_if:network to any - ($ext_if)
rdr on $ext_if proto tcp from any to any port 22 - $nat_cu
rdr on $ext_if proto tcp from any to any port 6881:6999 - $nat_opt
rdr on $ext_if proto tcp from any to any port 34567:34575 - $nat_cu
rdr on $ext_if proto tcp from any to any port 993 - $nat_opt
# filter rules
block in log
Try
block in log label inblock
Adding labels to your rules aids you in determining which ones are matched,
with 'pfctl -vvs labels'
pass out keep state
I think keeping state is the default now.
antispoof quick for { lo $int_if }
pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services
flags S/SA keep state
block drop in quick on $ext_if from $priv_nets to any
block drop out quick on $ext_if from any to $priv_nets
Use table syntax in combination with the table defined above;
block drop in quick on $ext_if from priv_netsto any
block drop out quick on $ext_if from any to priv_nets
pass in inet proto icmp all icmp-type $icmp_types keep state
You might want to think about added the quick keyword to the following four
rules.
pass in on $ext_if inet proto tcp from any to $nat_cu port $tcp_services
flags S/SA synproxy state
pass in on $ext_if inet proto tcp from any to $nat_cu port 34567:34575 flags
S/SA synproxy state
pass in on $ext_if inet proto tcp from any to $nat_opt port 6881:6999 flags
S/SA synproxy state
pass in on $ext_if inet proto tcp from any to $nat_opt port 993 flags S/SA
synproxy state
If you have a lot of traffic on the following two rules, put them at the top of
the filter
rules. Then they will be evaluated first and not the rest of the rules. You
might also consider adding them to 'set skip'.
pass in quick on $int_if
pass in quick on $wifi_if
Enlarging the buffer sizes for the BPF device might help as well;
sysctl net.bpf.bufsize=65536
sysctl net.bpf.maxbufsize=524288
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpLfY9Q2jj6g.pgp
Description: PGP signature
Re: 8.0 network problem
On Tue, Jul 06, 2010 at 01:32:22PM -0700, Jeremy Chadwick wrote: Back to the problem at hand: I wonder if it's lack of quick on some rules which is causing the problem; hard to say, That would stop evaluation of further rules, sure. But it seems most of the rules concern the external interface. _Assuming_ that the samba clients are on the internal interface, it would make sense to put the few rules concerning that interface as early as possible in the list of filter rules, and indeed add the quick keyword. Alternatively, one could consider adding this interface to the list of skipped interfaces. This would at least be useful for testing purposes, since it would preclude pf from processing packages on this interface. If this fixes the problem, there is some problem in the ruleset. and I'm not sure how to benchmark pf. Looking at the output of 'pfctl -vvs rules' would be a start, I think. If the rules that are matched most are at the end of the filter rules, all previous rules are evaluated, AFAIK. For more info try 'pfctl -vvs all'. In the past I found it useful to set up a point-to-point connection between two FreeBSD machines, and then do some throughput measusrements using e.g. nc(1). Start with pf disabled, then enhance the ruleset rule-by-rule and see if performance is influenced. A couple of years ago I did this, and IIRC the largest influence I could find was the type of ethernet adapter used. Can't find any notes from that experiment but I could repeat it if is deemed interesting. Furthermore, remember that the OP can move to another NIC and the problem goes away[1]. I know there have been issues in the past reported with em(4) and pf ALTQ, but that isn't in use here. There are lots of other crappy ethernet adapters out there. E.g. re(4) and rl(4) tend to suck in my experience. Of course if the hardware was changed but not the relevant filter rules, it would default to pass. :-) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpfy8AHfhPju.pgp Description: PGP signature
Re: ZFS on top of GELI
On Sun, Jan 10, 2010 at 05:08:29PM +0200, Dan Naumov wrote: Hello list. I am evaluating options for my new upcoming storage system, where for various reasons the data will be stored on 2 x 2tb SATA disk in a mirror and has to be encrypted (a 40gb Intel SSD will be used for the system disk). Right now I am considering the options of FreeBSD with GELI+ZFS and Debian Linux with MDRAID and cryptofs. Has anyone here made any benchmarks regarding how much of a performance hit is caused by using 2 geli devices as vdevs for a ZFS mirror pool in FreeBSD (a similar configuration is described here: http://blog.experimentalworks.net/2008/03/setting-up-an-encrypted-zfs-with-freebsd/)? Some direct comparisons using bonnie++ or similar, showing the number differences of this is read/write/IOPS on top of a ZFS mirror and this is read/write/IOPS on top of a ZFS mirror using GELI would be nice. I am mostly interested in benchmarks on lower end hardware, the system is an Atom 330 which is currently using Windows 2008 server with TrueCrypt in a non-raid configuration and with that setup, I am getting roughly 55mb/s reads and writes when using TrueCrypt (nonencrypted it's around 115mb/s). Although I cannot comment on ZFS, my $HOME partition is UFS2+geli. Reads (with dd) of uncached big[1] files are ~70MB/s. Reading an unchached big file from a non-encrypted UFS2 partition is ~120MB/s. Note that the vfs cache has a huge influence here; Repeating the same read will be 4 – 7 times faster! The sysctls for ZFS chaching will probably have a big impact too. Roland [1] several 100s of MiB. -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp4DdjGsXivv.pgp Description: PGP signature
Re: ntpd not removed; WITHOUT_NTP enabled in src.conf
On Sat, Jan 09, 2010 at 12:08:09PM +0100, Oliver Fromme wrote: Roland Smith wrote: Henrik Hudson wrote: Hey List, Among other things I have in my /etc/src.conf WITHOUT_NTP=yes which from my understanding should not build ntpd, etc... [...] ntpd still exists in /usr/sbin and the man pages, etc... seem to still be hanging around. Did I miss something? Adding options to `/etc/src.conf` does not remove old binaries, libraries or manpages! It just prevents the system from building newer ones. I'm afraid that's not true. When you disable something in src.conf(5), its files *will* be removed when you do make delete-old. See the file src/tools/build/mk/OptionalObsoleteFiles.inc for all the details. It's included by src/ObsoleteFiles.inc which in turn is included by src/Makefile.inc1 (after /etc/src.conf was parsed by share/mk/bsd.own.mk). Hmm, interesting. Thanks for the heads-up :-) If that doesn't work for WITHOUT_NTP, then that's a bug. Probably some entries missing in OptionalObsoleteFiles.inc. There are a actually quite a lot missing, if you compare src.conf(5) with /usr/src/tools/build/mk/OptionalObsoleteFiles.inc WITHOUT_ACCT ((or MK_ACCT) to begin with, WITHOUT_AMD, WITHOUT_APM, WITHOUT_AT, WITHOUT_BZIP2 etc. And a lot of others need to be filled in, like MK_BOOT, MK_CALENDAR, MK_CPP, MK_CRYPT, etc. I'll give improving the list a try, as soon as I can find some spare time. Got some frozen bowden calbes on my bike to sort out first. :-/ Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgppHn45d9edj.pgp Description: PGP signature
Re: ntpd not removed; WITHOUT_NTP enabled in src.conf
On Fri, Jan 08, 2010 at 01:38:49PM -0900, Henrik Hudson wrote: Hey List, Among other things I have in my /etc/src.conf WITHOUT_NTP=yes which from my understanding should not build ntpd, etc... However, after doing: make buildworld ... make installworld ... ntpd still exists in /usr/sbin and the man pages, etc... seem to still be hanging around. Did I miss something? Adding options to `/etc/src.conf` does not remove old binaries, libraries or manpages! It just prevents the system from building newer ones. The best way to deal with this is to use find(1) to locate binaries and libraries that are older than the most recent installworld. It might be a good idea to make a backup first, in case you screw up the system! Now, supposing the latest installworld (with the new options in `/etc/src.conf`) was December 3rd. Running the following command will reveal all older files; find /bin -type f -and -not -newermt 'Dec 3' -ls After checking that you've *really* only found old binaries, replace `-ls` with `-delete` to remove them. Next, repeat this for the directories `/sbin`, `/usr/bin`, `/usr/sbin`, `/lib`, `/libexec`, `/usr/lib`, `/usr/libexec`, `/usr/share/man/man*` and `/rescue`. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp4kfGyvUA6X.pgp Description: PGP signature
Re: kernel build failed
On Sat, Jan 02, 2010 at 09:55:29PM +0200, E. O. wrote: pls help me.. build kernel error.. I have to update their source code.. standart-supfile # IMPORTANT: Change the next line to use one of the CVSup mirror sites # listed at http://www.freebsd.org/doc/handbook/mirrors.html. *default host=CHANGE_THIS.FreeBSD.org What host did you really use? CHANGE_THIS.FreeBSD.org doesn't exist. GENERIC Kernel use.. FreeBSD fbsd 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Fri Jan 1 15:31:27 EET 2010 r...@fbsd:/usr/obj/usr/src/sys/GENERIC amd64 error ; make buildkernel and error.. ./pci_if.h:226: error: stray '\335' in program I think pci_if.h is a generated file. Clean out /usr/obj and try again. If that doesn't work, try updating your source again. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpHJnxYwUe8G.pgp Description: PGP signature
Re: ZFS and disappearing glabels
On Thu, Dec 31, 2009 at 12:48:28PM -0800, George Hartzell wrote: I've set up a system as described here. http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition Using the 8.0 Release DVD and then csup'ing to RELENG_8 and rebuilding. I set it up with a single drive, the only change that I made was that after creating ad10s1a I glabeled it as disk0, then added /dev/label/disk0 to the pool. That worked great. Then I added a second larger drive, giving it an MBR, a bsd label, and an s1a partition that I glabeled as disk1. I attached that to the pool and it resilvered happily. However, when I rebooted I found that the pool now consists of label/disk0 and ad12s1a. I detached ad12s1a, relabeled it as disk1, and attached disk1 to the pool again. It resilvered fine. Running strings on /boot/zfs/zpool.cache shows /dev/label/disk0 and /dev/label/disk1. How did you create the labels? See glabel(8) about the difference between the manual and automatic method. Maybe you accidentally used the manual method on the second disk? Or it could be that the GEOM metadata is overwritten. This metadata is written in the last sector, explaining the size difference you noticed. If the metadat is overwritten, GEOM will not recognize it. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpuuY6XVFwMp.pgp Description: PGP signature
Re: Using RELENG_8 to compile for older RELENG_x
On Wed, Dec 16, 2009 at 04:15:01AM -0500, grarpamp wrote: I'm on RELENG_8, works great. I've been bugged to compile some things for RELENG_4 boxes. Due to administrative fiat, I have to compile externally and ship them the results, no login. The best thing to do is to convince the guys running RELENG_4 to join the rest of us in the 21st century, and switch to 8.0 or at least 7.x. Support for the 4.x base system has ended some time ago, and the current ports tree isn't guaranteed to work on it either. So in general, how do I use my RELENG_8 boxes to compile apps that will run on RELENG_4? Create a virtual machine with RELENG_4 on it, that is probably the most foolproof way. (If you are running an i386 machine, maybe a jail will work.) Try to compile the software on it. If that software is in ports and the current port doesn't compile or run, either roll back your ports tree to a version that works, or try to patch the port to make it work. Similarly, how can I make buildworld/buildkernel/release for RELENG_4 on RELENG_8? Ditto. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp2biSdUZmah.pgp Description: PGP signature
Re: Using RELENG_8 to compile for older RELENG_x
On Wed, Dec 16, 2009 at 04:55:46AM -0600, Mark Linimon wrote: On Wed, Dec 16, 2009 at 11:28:51AM +0100, Roland Smith wrote: the current ports tree isn't guaranteed to work on [4.x] either. s/isn't guaranteed to/is guaranteed not to/ That's what I thought, but I couldn't quickly locate a reference to that event. I seem to recall a mailing list message to that event, but as I was already running a later version it didn't quite register. In the days before 5.3 or even 6.0 I could understand why people clung to 4.x. But now it seems like inviting trouble. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpOrhjP2tmvn.pgp Description: PGP signature
Re: Using RELENG_8 to compile for older RELENG_x
On Wed, Dec 16, 2009 at 03:18:17PM -0500, grarpamp wrote: I think I'll try unpacking 4.11's release tarballs into an empty jail, doing whatever else the install does and launching that. I'm guessing I should be able to compile/install world/kernel/release/apps in there. Assuming the running RELENG_8 parent kernel services don't cause issues. If it doesn't work I can always fall back to [a]. If I understand correctly, you want to use the jail to run a 4.11 userland on an 8.x kernel? If you are not running GENERIC on the host, remember to include the COMPAT_FREEBSD4..COMPAT_FREEBSD7 options in your kernel. You'll need that to run 4.x binaries. Running older binaries is possible. But on the other hand running a userland that is not in sync with the kernel not supported and known to be able to cause trouble. See e.g. §24.7 of the Handbook. It will be an interesting experiment at least. :-) I'd probably try installing 4.11 on a old spare machine first. Yeah, you could consider it 'embedded' all right. Like deep in a dusty corner, driving some critical legacy shims that they forgot about in the migration plan, oops. Oops indeed. Old+'dusty corner'+'critical' is not a good combination in my experience. If the scenario also contains the element 'no backups', its time to run for the hills. :-/ Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp4NfTbyZXxe.pgp Description: PGP signature
Re: RELENG_8 buildworld broken?
On Wed, Dec 09, 2009 at 01:09:12PM -0800, Jeremy Chadwick wrote:
snip
The problem is this:
- User installs OS
- User creates src.conf with numerous WITHOUT_xxx entries. Examples:
WITHOUT_ATM=true
snip
WITHOUT_SENDMAIL=true
snip
- User is forced to go through above said directories and cross
their fingers hoping they're deleting the right stuff.
Doing this right is not all that difficult when using find(1) and some common
sense. Maybe I'm too harsh, but someone who can't figure this out shouldn't be
messing with the system.
snip
Cons to this methodology:
- User now has binaries and/or libs on their system which may contain
security holes that could be exploited if exploits/issues are found
in the future. This is serious, and anyone who says otherwise has
their head in the sand.
Agreed. There should at least be mention of this in the src.conf manual page,
and probably in the handbook as well. Suppose I submit something like the text
below to be added to src.conf(5) or maybe the Handbook;
-
Adding options to /etc/src.conf does not remove old binaries, libraries or
manpages! It just prevents the system from buiding newer ones. The best way
to deal with this is to use find(1) to locate binaries and libraries that are
older than the most recent installworld. E.g., supposing the latest
installworld (with the new options in /etc/src.conf) was Decemer 3rd. Running
the following command will reveal all older files
find /bin -type f -and -not -newermt 'Dec 3' -ls
After checking that you've really only found old binaries, replace -ls with
-delete. Next, repeat this with /sbin, /usr/bin, /usr/sbin, /lib, /libexec,
/usr/lib, /usr/libexec, /usr/share/man/man* and /rescue.
-
This strikes me as a reasonebly easy way to fix the problem.
Of course one could be fancy about presenting the old files;
find /bin -type f -and -not -newermt 'Dec 3' -ls | \
awk '{print $11, \t, $8, , $9;}'
If someone was so inclined, it shouldn't be too hard to write a program to
more-or-less automate this; run all these commands, and append the output to a
file. The user would then be given the opportunity to tell which (if any) of
the old files to keep, and the program would then delete the others. Kind of
like mergemaster.
Basically, all this comes back to the same thing: the entire base
system concept needs to be revisited (that's a nice way of saying
nuked from orbit, but that's my opinion).
Hmm, I kind of like having a usable base system as opposed to just a
kernel. :-) It is one of the strong points of FreeBSD, IMHO. The fact that the
base system is developed as a unit keeps it working very well.
But I can see the virtue in your approach as well. I wouldn't mind turning the
current base system into ports, but it would be a good thing IMO to keep
developing these 'ports' that form the current base system as part of the
system instead of in the ports tree.
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpZLKcAF1gFK.pgp
Description: PGP signature
Re: some options in src.conf has no effect (RELENG_8)
On Tue, Dec 08, 2009 at 10:26:13PM +0200, nickolas...@gmail.com wrote: And there are options that have no effect: WITHOUT_CTM WITHOUT_CVS WITHOUT_FREEBSD_UPDATE WITHOUT_IPFW WITHOUT_PORTSNAP WITHOUT_RCS WITHOUT_ROUTED I'm using WITHOUT_CTM and WITHOUT_CVS. When building the new system, cvs and ctm* are _not_ built. But the old executables are not deleted; look at their dates. According to src.conf(5): The only purpose of src.conf is to control the compilation of the FreeBSD source code... So the fact that old executables and manual pages are not deleted is not strictly a bug. I've done make delete-old and make delete-old-libs during upgrade. Can somebody comment this? Using make delete-old includes /usr/src/ObsoleteFiles.inc into the build Makefile. This file contains the names of files that have been made obsolete by newer FreeBSD versions. It does not have anything to do with things that do not have to be installed because they are excluded by src.conf. You could write an extension to the Makefile that build e.g. a /usr/src/IgnoreFiles.inc based on the contents of /etc/src.conf. But it is probable easier to run find(1) in /usr looking for files older than your buildworld. E.g., I've rebuilt world on December 3rd. Looking for different binaries in /usb/bin with the command 'find /usr/bin -type f -and -not -mtime 6 -ls'. If you are sure this is all junk, replace -ls with -delete. If you screw something up, re-run installworld. :-) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpfOENZDde00.pgp Description: PGP signature
Re: iwn(4) 5100 - Estimation for MFC of r198429?
On Tue, Dec 01, 2009 at 07:39:37PM -0500, Glen Barber wrote: Hi, I've been using the iwn(4) driver contributed by Bernhard Schmidt with my Intel 5100 AGN card on 8-STABLE since he announced the availability. It was committed to -CURRENT as of r198429. There is no mention of MFC in the commit log. Are there plans to MFC this driver to 8-STABLE for a wider testing base? Hear, hear. I've got a 5100 AGN in a laptop. I'd like to test it as well, without switching to -CURRENT. If I just got the files mentioned in the commit* and add/replace them in my source tree, it looks like it should work. Or am I missing something? Roland * http://svn.freebsd.org/viewvc/base?view=revisionrevision=198429 -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp0N8oYyXIAE.pgp Description: PGP signature
Re: 8.0-RELEASE completed...
On Sun, Nov 29, 2009 at 11:30:18AM -0800, Gary Kline wrote: There are a couple of differences between 7.x and 8.0; * The USB stack has been rewritten. I've had to change the following in /etc/devfs.rules: replace add path 'usb*' mode 0660 group usb with add path 'usb/*' mode 0660 group usb Roland, would you please update your webpage? Coincidentally, I just did that today. :-) * The name of the tty devices has changed in /etc/ttys; ttydN - ttyuN (impacts /etc/ttys) What impact is this likely to have on my server? The more ttys we've got, the better, for a term/xterm/cmdline like me. Not a lot. If you haven't changed /etc/ttys, mergemaster will take care of it for you. I always change this file, to mark the console as insecure (meaning you have to give the root password to log into single user mode). Note that this change only affects the dialup lines. On my machines I always disable them. * There have been a lot of changes in the kernel configuration. If you want a custom kernel, start anew from the 8.0 GENERIC kernel so you don't miss anything. Could somebody who's running a 32biter send a GENERIC from 8.0 so I can diff? Go to the following URI: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/GENERIC?only_with_tag=RELENG_8_0_0_RELEASE Click on 'download' to get the file, or select it for a diff between another version. * A lot of changes as well in /etc/src.conf (the file that defines which parts of the system are built from source) * Network cards show up in dmesg and ifconfig, but not as devices in /dev (but that could be a configuration error on my part.) Sorry, you left me in the dust with /etc/src.conf. I though the entire system was built from source. Examples, please? This file contains variables that will be used during a system build from source. The main use is to have the system skip building things you don't need. E.g. if you don't have bluetooth devices in your server, you can set WITHOUT_BLUETOOTH=yes in /etc/src.conf, and the system will not build kernel modules and programs that relate to bluetooth. See src.conf(5) for a complete list of settings (with explanations) you can apply in this file. I tend to disable everything I don't need, because bugs and vulnerabilities in things that are not built and installed cannot harm me. And it cuts down on build time as well. I tend to build my own kernel for mostly the same reasons. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpUr4FCKY8WC.pgp Description: PGP signature
Re: 8.0-RELEASE completed...
On Thu, Nov 26, 2009 at 09:57:58PM -0800, Gary Kline wrote: Altho I am still some time from having my migration from the 1998 Kayak - 2009 Dell done and working, will it be possible to upgrade my 32bit 7.2-R, p4 to a 64bit 8.0? It is possible, but not easy. Upgrading from 7.x to 8.0 on the same architecture is not that hard IMHO. Upgrading from i386 to amd64 on the same release is doable but tricky; you need a spare root partition to install the amd64 binaries. Combining these two sounds like a big can of worms to me. My advice would be _not_ to do it. It would be far easier to just install 8.0 on the new machine and migrate your data and configuration files. You are going to have to build your ports from scratch anyway, because you're switching to another architecture and another major release. As far as I know, the on-disk filesystem format hasn't changed. (unless your old machine is still running UFS1. The default now is UFS2) There are a couple of differences between 7.x and 8.0; * The USB stack has been rewritten. I've had to change the following in /etc/devfs.rules: replace add path 'usb*' mode 0660 group usb with add path 'usb/*' mode 0660 group usb * The name of the tty devices has changed in /etc/ttys; ttydN - ttyuN (impacts /etc/ttys) * There have been a lot of changes in the kernel configuration. If you want a custom kernel, start anew from the 8.0 GENERIC kernel so you don't miss anything. * A lot of changes as well in /etc/src.conf (the file that defines which parts of the system are built from source) * Network cards show up in dmesg and ifconfig, but not as devices in /dev (but that could be a configuration error on my part.) All my configuration files are kept in a directory that is under revision control by git(1), so I could show you exactly what changes I've made. would get that clear as a first step. My Intell duo-core is very fast; would moving to the 64-bit system be a net gain or loss [in performance]. There is no clear gain or loss answer to that one. It depends on the workload you are running. On the plus size, amd64 has a lot more general registers available in the CPU than i386. On the other hand, the binaries are bigger. Since you're switching to another CPU, things like cache size will have a major inpact. WRT single versus multi cores, my impression has been that the individual cores in a multi-core intel CPU are somewhat slower that the core of a similarly clocked single-core CPU. (based on some informal testing I've done with povray). If your workloads are capable of running on multiple cores (e.g. make jobs, different programs running concurrently) there will be a significant speed increase. You only _need_ amd64 if you are running out of address space on the i386 architecture. Having said that, I've been running amd64 on my desktop since 5.3-RELEASE more or less because I can, and it has worked fine ever since. Be aware though that there are a few (most binary) ports that do not work on amd64. You can see that in the port Makefiles by looking for things like NOT_FOR_ARCHS and ONLY_FOR_ARCHS. HTH, Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpBcwHXv1PX9.pgp Description: PGP signature
Re: Avahi compilation help needed
On Thu, Sep 10, 2009 at 10:39:27PM +0800, Sagara Wijetunga wrote: Dimitry Andric wrote: On 2009-09-10 14:06, Sagara Wijetunga wrote: I'm trying to compile Avahi-0.6.25 (http://avahi.org/) on FreeBSD 7.2 (i386) [in fact, on Tomahawk Desktop]. It develops compilation errors. Any reason why you don't use the net/avahi port instead? This will save you most compilation and installation headaches. My thoughts exactly. Tomahawk Desktop uses FreeBSD sources, it is not based on the FreeBSD distribution. What does that mean? The FreeBSD sources by default make a complete _base_ distribution. It doesn't have a port system. Tomahawk Desktop is designed everything to be installed simply by ./configure, [g]make, [g]make install which FreeBSD is not designed to support. This is demonstrable not correct. The FreeBSD ports system _does_ use configure and friends when available in the source of the package. E.g, every port that has 'GNU_CONFIGURE= yes' in its Makefile uses it. The ports system is nothing more than a wrapper to allow unmodified sources to be built on FreeBSD. In Tomahawk Desktop, anything you compile and install, can be cleanly uninstalled without any file left out, which is not possible in FreeBSD. Again this is demonstrable false. There are plenty of ports that deinstall cleanly. One of my own ports, graphics/stl2pov, for example. If what you are saying were true, it would come as a suprise to many ports developers. Sure, there are ports with incorrect packing lists which leave files behind, but usually that is not a big problem. And the ports system (correctly, IMO) will not delete files that have been modified and non-empty directories; a ports system should _never_ delete any of the users' files. Here compile and install means you take a package, unpack, make and make install, that's it. You don't have wait until somebody prepare a port for you. But you do have to wait until somebody sorts out the compile problems... Which amount to the same thing. And which can be a royal PITA as you are dicovering. :-) IMHO, what you are doing is effectively a huge duplication of effort. I would advise you to switch over to the ports system and save yourself a lot of work. If you require applications that are currently not in ports, it is easier to submit and maintain a few ports than a complete system. Coming back to our problem, Avahi get compile errors on FreeBSD when its original build system is used. We need a help. Appreciate if somebody could give it a try to just compile (ie. download the package, unpack, ./configure and gmake). Avahi needs patches to work properly on FreeBSD. See e.g. the files/ directory in the net/avahi-app port. Applying those patches should solve most of your problem. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpgavzUoXWbc.pgp Description: PGP signature
Re: Cpufreq/ACPI problem? (basically still is: Re: Problem with IBM Thinkpad T30 shutting down due to high temperatures)
On Wed, Aug 12, 2009 at 09:47:18AM +0200, Christian Walther wrote: Hi, thank you for all your feedback. I won't answer all replies in detail, but will summarise what I did to give you some sort of report. Doug made me think about the beginning of this situation. I can't tell you for sure that I had the T30 working flawlessly, because I took the original install from another, older thinkpad. But I did change some BIOS settings, Interrupt settings, mainly, that seem to cause problems with my Wireless NIC in the past. So I restored the BIOS defaults. This seems to make the problem disappear, but to be honest: I'm not sure if I messed up the ACPI table at all, or if this is some sort of performance issue, because I now have all IO bound devices on IRQ 11: vgapci0: VGA-compatible display port 0x3000-0x30ff mem 0xe800-0xefff,0xd010-0xd010 irq 11 at device 0.0 on pci1 uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f irq 11 at device 29.2 on pci0 cbb0: TI1520 PCI-CardBus Bridge mem 0x5000-0x5fff irq 11 at device 0.0 on pci2 cbb1: TI1520 PCI-CardBus Bridge mem 0x5100-0x51000fff irq 11 at device 0.1 on pci2 fxp0: Intel 82801CAM (ICH3) Pro/100 VE Ethernet port 0x8000-0x803f mem 0xd020-0xd0200fff irq 11 at device 8.0 on pci2 pcm0: Intel ICH3 (82801CA) port 0x1c00-0x1cff,0x18c0-0x18ff irq 11 at device 31.5 on pci0 This causes screen refresh problems (e.g. urxvt isn't able to draw new lines as expected). Still, this didn't resolve the issue, so I took a look at acpi_thermal. Right now I have the following set in /etc/sysctl.conf hw.acpi.thermal.user_override=1 According to acpi_thermal(4), you should not use decimal. So it should be 84C instead of 84.0C. hw.acpi.thermal.tz0._PSV=84.0C hw.acpi.thermal.polling_rate=2 This basically gives me: # sysctl -a|egrep (temp|freq|acpi.therm|acpi_ibm.*fan) kern.acct_chkfreq: 15 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.TSC.frequency: 20 net.inet.sctp.sack_freq: 2 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.prefer_tempaddr: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 You should look at dev.cpu.N.freq_levels, where N is the number of the core. See cpufreq(4) and below. snip hw.acpi.thermal.polling_rate: 2 The polling_rate is just the number of seconds between readings of the temperature. Nothing more. hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 62.0C hw.acpi.thermal.tz0.active: 0 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 84.0C The _PSV setting means that the system will only start throttling the CPU when temperature reaches 84°C! You might want to set that a little lower. The system shuts down at 92°C. That seems to be a fine line to walk. hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 92.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 5 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 600 machdep.acpi_timer_freq: 3579545 machdep.tsc_freq: 20 machdep.i8254_freq: 1193182 dev.acpi_ibm.0.fan_speed: 4465 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.cpu.0.freq: 2000 dev.cpu.0.freq_levels: 2000/0 1750/0 1500/0 1250/0 1200/0 1050/0 900/0 750/0 600/0 450/0 300/0 dev.acpi_perf.0.freq_settings: 2000/0 1200/0 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 Active cooling doesn't seem to be supported. There is a fan of course, and I can even set a fan level via dev.acpi_ibm.0.fan, but this is not related to hw.acpi.thermal.tz0._HOT and hw.acpi.thermal.tz0._ACx (which is read only anyway). According to dev.acpi_ibm.0.fan_speed the speed of the fan is something between 4450 and 4780. The interesting bit here is cpufreq and how it behaves. Lets have a look at the output of the following loop: # while true ; do temp=$( sysctl hw.acpi.thermal.tz0.temperature ) ; freq=$( sysctl dev.cpu.0.freq ) ; printf %4s %4s\n $freq[17,$#freq] $temp[34,$#temp] ; sleep 2 ; done 2000 84.0C 2000 85.0C 2000 85.0C 2000 85.0C 2000 86.0C 300 86.0C 300 86.0C 300 86.0C 300 85.0C 300 84.0C 300 82.0C 300 81.0C It appears that cpufreq requires at least eight seconds to reduce the frequency. There are two issues I'm seeing here: Firstly hw.acpi.thermal.polling_rate: 2 Either I get this one wrong, or cpufreq doesn't react after every poll. The latter, I think. snip The interesting bit here is cpufreq: Is the behaviour normal and to be
Re: Problem with IBM Thinkpad T30 shutting down due to high temperatures
On Mon, Aug 10, 2009 at 11:53:10PM +0200, Christian Walther wrote: Hello list, for some time now my T30 shuts down due to temperatures exceeding the safe limit of 92 degrees celcius. Regardless to say that a 2GHz pentium4m powers the machine, and these chips are well known for high temperatures. But I'm unable to do anything that causes high load on the laptop: Building world or complex ports makes the system reach the limit within minutes. A few days ago I configured xcompmgr, which even seems to make the problem whorse (yes, composite extension is enabled). What I don't know is if this is a hardware error, or something caused by the kernel. I wrote a small script to monitor dev.acpi_ibm.0.fan dev.acpi_ibm.0.fan_level, hw.acpi.thermal.tz0.temperature and dev.cpu.0.freq, and it sometimes appears that the temperature of the CPU rises, but the kernel doesn't decrease the clock in time. If available, you can use acpi_thermal(4) to set the temperatures at which atcive cooling engaves. Look for the sysctl 'hw.acpi.thermal.tz%d._ACx', where %d is the core number and x is the cooling level. Or set the level manually with 'hw.acpi.thermal.tz%d.active'. Read the acpi_thermal manpage for more details. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp2DmXADZChF.pgp Description: PGP signature
Re: Monitoring tools for mfi0: Dell PERC 6?
On Sun, Aug 09, 2009 at 08:04:35PM +0200, Václav Haisman wrote: Hi, I have a server with the mfi0: Dell PERC 6 controller. Are there any monitoring tool for this? I tried camcontrol but it doesn't even list the device. Maybe sysutils/megacli does what you want? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpJk4wECUtRY.pgp Description: PGP signature
8.0-BETA2 test OK on Dell Latitude C610
This week I updated my laptop (Dell Latitude C610) to 8.0-BETA2 from 7.2-RELEASE from source. Apart from the fact that building world stopped in usbconfig (see PR bin/137180, I patched usbconfig's Makefile to link to the newly built libusb), the update went smoothly. So far I have not found further major issues. I recreated my kernel config based on the new GENERIC. I've re-built approximately 450 ports without problems, with an up-to-date ports tree. Just a heads-up to the developers. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpP2PiJKqIGg.pgp Description: PGP signature
Re: FreeBSD child process die for root
On Wed, Jul 01, 2009 at 08:23:52PM -0500, Sagara Wijetunga wrote: Roland Smith writes: On Wed, Jul 01, 2009 at 02:04:09AM -0500, Sagara Wijetunga wrote: Hi I'm Sagara Wijetunga from Tomahawk Computers from Singapore, makers of the Tomahawk Desktop, a FreeBSD based desktop operating system (http://www.tomahawkcomputers.com/) which is free for personal use. Ever since we upgraded our Tomahawk Core OS to the FreeBSD 7.2 sources, we experienced a strange issue as follows: 1. The root cannot login from the console, child process forked die with “uid 0: exited on signal 11”. 2. Normal users can log in, no issue. 3. Normal users can type “su” and become root, but “su -l” results child process forked die with “uid 0: exited on signal 11”. 4. The /var/log/messages shows “(cron), uid 0: exited on signal 11 (core dumped)” Based on your symptoms, it looks like something in the restart commands file for root causes the shell to crash... What shell are you using for root? Hi Roland, thank you for the reply. I have tested with bash, sh and csh. It seems the child process forked simply die irrespective of the shell. Ok, so it's probably not a shell problem There is no change in the dot files for root: [r...@tds sagara]# diff /root/.cshrc /usr/src/etc/root/dot.cshrc [r...@tds sagara]# diff /root/.login /usr/src/etc/root/dot.login [r...@tds sagara]# diff /root/.profile /usr/src/etc/root/dot.profile /root/.login executes the fortune program. Can you su to root and then run '/usr/games/fortune -s'? Here is the log message for su -l: Jul 2 12:38:17 tds kernel: pid 943 (su), uid 0: exited on signal 11 It could be a hardware problem. Signal 11 can be a sign of bad memory. Can you reproduce the problem on multiple machines? Btw, what is restart commands file for root? The rc in .shrc stands for restart commands. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgph7fZe1R2tn.pgp Description: PGP signature
Re: FreeBSD child process die for root
On Wed, Jul 01, 2009 at 11:17:07PM -0500, Sagara Wijetunga wrote: Roland Smith writes: I have tested with bash, sh and csh. It seems the child process forked simply die irrespective of the shell. Ok, so it's probably not a shell problem There is no change in the dot files for root: [r...@tds sagara]# diff /root/.cshrc /usr/src/etc/root/dot.cshrc [r...@tds sagara]# diff /root/.login /usr/src/etc/root/dot.login [r...@tds sagara]# diff /root/.profile /usr/src/etc/root/dot.profile /root/.login executes the fortune program. Can you su to root and then run '/usr/games/fortune -s'? /root/.login is completely commented out. You're right. I missed that. :-) Here is the log message for su -l: Jul 2 12:38:17 tds kernel: pid 943 (su), uid 0: exited on signal 11 Is there anything else from su in the logfiles? That might help narrow down where it crashes. Are you using the standard FreeBSD su? If not, check your modifications. Does the version of the userland that you are using match the version of the kernel? I've verified that 'su -l' works fine on FreeBSD 7.2-RELEASE-p2 on the amd64 architecture. What you could do is run 'su -l' under a debugger. It could be a hardware problem. Signal 11 can be a sign of bad memory. Can you reproduce the problem on multiple machines? I have taken the hard disk out and fixed on different machines, the symptoms are still the same. So it may not be a hardware error. Ok. So it is probably a software bug then. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpWyhORQODS9.pgp Description: PGP signature
Re: FreeBSD child process die for root
On Wed, Jul 01, 2009 at 02:04:09AM -0500, Sagara Wijetunga wrote: Hi I'm Sagara Wijetunga from Tomahawk Computers from Singapore, makers of the Tomahawk Desktop, a FreeBSD based desktop operating system (http://www.tomahawkcomputers.com/) which is free for personal use. Ever since we upgraded our Tomahawk Core OS to the FreeBSD 7.2 sources, we experienced a strange issue as follows: 1. The root cannot login from the console, child process forked die with “uid 0: exited on signal 11”. 2. Normal users can log in, no issue. 3. Normal users can type “su” and become root, but “su -l” results child process forked die with “uid 0: exited on signal 11”. 4. The /var/log/messages shows “(cron), uid 0: exited on signal 11 (core dumped)” Based on your symptoms, it looks like something in the restart commands file for root causes the shell to crash... What shell are you using for root? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpVYSkiCKuYM.pgp Description: PGP signature
Re: Vulnerability question
On Wed, Jul 01, 2009 at 11:05:28PM +0200, Harald Weis wrote:
How do you do that precisely ?
``WITH_REALPLAYER=no'' in /etc/make.conf ?
cd /us/ports/multimedia/mplayer
make config
Scroll down to the REALPLAYER Enable real player plugin line
SPACE to un-check the line
TABENTER
make
make deinstall
make reinstall
make clean
Or use 'portupgrade -f' AFTER the 'make config'.
That's not what I meant.
Every time I do ``portsnap fetch update'' mplayer's Makefile contains
the ``real player plugin'' option set to ``on''.
If for some reason I've got to reinstall mplayer with (my preferred)
``portmaster --force-config [-d|-D] multimedia/mplayer'', then
I would like to have the realplay option already unchecked.
snip
I thought the WITH_REALPLAYER=no line in make.conf could do this job,
The config values given in the Makefile are defaults. If you change
them, the options values are saved in /var/db/ports/portname/options. These
values override the defaults, and you will not be shown the dialog again
unless extra options have been added to the Makefile or --force-config is used.
Another method is to put variables in /etc/make.conf, but to prevent mistakes
you should only put those varialbes in /etc/make.conf that are not
supported by options. E.g. for mplayer I have the following in make.conf:
.if ${.CURDIR:M*/multimedia/mplayer}
WITH_DVD_DEVICE=/dev/cd1
WITH_CDROM_DEVICE=/dev/cd1
.endif
The if-construction is used to set these variables only when invoked in
the mplayer port directory, to prevent possible conflicts with other ports.
These particular variables have to be set in make.conf because the
options mechanism currently only supports yes/no values.
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpKEC1POl45Z.pgp
Description: PGP signature
Re: Vulnerability question
On Tue, Jun 30, 2009 at 05:08:32PM +0200, Harald Weis wrote: On Mon, Jun 29, 2009 at 08:40:52PM +0200, Roland Smith wrote: On Sun, Jun 28, 2009 at 10:56:54PM +0200, Harald Weis wrote: Building lxdvdrip stops because linux-pango has known vulnerabilities. You can ignore vulnerabilities by setting the environment variable DISABLE_VULNERABILITIES. See ports(7). Yes, I've done this already, but I've stepped back because I cannot evaluate the risk. Are you running a linux binary of mplayer? Because a native mplayer binary does not require linux-pango! It just uses the native pango. In fact, it's lxdvdrip which requires linux-pango [via linux-gtk2]. lxdvdrip is happy with the native mplayer. Looking at the port Makefile [/usr/ports/multimedia/lxdvdrip/Makefile] and Freshports entries [http://www.freshports.org/multimedia/lxdvdrip/] for lxdvdrip, there is no sign of it directly requiring pango, let alone the Linux version. It is mplayer that depends on pango: # cd /usr/ports/multimedia/lxdvdrip # make run-depends-list /usr/ports/misc/buffer /usr/ports/multimedia/dvdauthor /usr/ports/multimedia/libdvdnav /usr/ports/multimedia/libdvdread /usr/ports/multimedia/mpgtx /usr/ports/multimedia/mplayer /usr/ports/multimedia/transcode /usr/ports/sysutils/dvd+rw-tools # cd /usr/ports/multimedia/mplayer # make run-depends-list /usr/ports/accessibility/atk /usr/ports/audio/cdparanoia /usr/ports/audio/esound /usr/ports/audio/libvorbis /usr/ports/converters/libiconv /usr/ports/devel/gio-fam-backend /usr/ports/devel/glib20 /usr/ports/devel/pkg-config /usr/ports/devel/sdl12 /usr/ports/graphics/aalib /usr/ports/graphics/png /usr/ports/multimedia/libtheora /usr/ports/multimedia/mplayer-skins /usr/ports/multimedia/x264 /usr/ports/print/freetype2 /usr/ports/x11-toolkits/gtk20 /usr/ports/x11-toolkits/pango /usr/ports/x11/libX11 /usr/ports/x11/libXv /usr/ports/x11/libXxf86vm No linux-pango! I suspect that there is something wrong with your ports. Do you have the native version of pango installed? Can you post the output of 'pkg_info -rx lxdvdrip' and 'pkg_info -rx mplayer'? If you want to rip DVDs, you can simply use mplayer: mplayer dvd://N -dumpstream -dumpfile title.mpg where N is the number of the title you want. That's interesting. I will try that soon. I hope the manpage does explain how to burn it then. For burning you'll need other programs. Mplayer/mencoder don't do that. That is where dvdauthor and dvd+rw-tools come in. But what happens if the title is too long for a DVD5 ? Then you can use mencoder to re-encode it. This takes some experimenting. I tend to re-encode to the H.264 video codec, because it is a lot smaller. I don't know if DVD players support this codec. But then I tend to watch movies mostly on my PC. An example: # Ripping mplayer dvd://1 -dumpstream -dumpfile foo.mpg # Reencoding mencoder foo.mpg -aid 128 -ovc x264 \ -x264encopts subq=4:bframes=3:b_pyramid:weight_b:qp=18:threads=auto:pass=1 \ -vf crop=704:464:10:56 -idx -oac mp3lame -o /dev/null ; \ mencoder foo.mpg -aid 128 -ovc x264 \ -x264encopts subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b:qp=18:threads=auto:pass=2 \ -vf crop=704:464:10:56 -idx -oac mp3lame -o foo.avi # See the size difference! du -m foo.* 1701foo.avi 6427foo.mpg The crop numbers (to remove black bands around the movie) can vary per film. Use the -cropdetect option of mplayer to figure out the right numbers to use. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp4GfPeZSzi4.pgp Description: PGP signature
Re: Vulnerability question
On Tue, Jun 30, 2009 at 06:35:04PM -0400, Gary Palmer wrote: Are you running a linux binary of mplayer? Because a native mplayer binary does not require linux-pango! It just uses the native pango. In fact, it's lxdvdrip which requires linux-pango [via linux-gtk2]. lxdvdrip is happy with the native mplayer. Looking at the port Makefile [/usr/ports/multimedia/lxdvdrip/Makefile] and Freshports entries [http://www.freshports.org/multimedia/lxdvdrip/] for lxdvdrip, there is no sign of it directly requiring pango, let alone the Linux version. It is mplayer that depends on pango: I am not the OP, however I also ran into warnings about mplayer and linux-pango. I believe the problem comes from linux-realplayer # cd /usr/ports/multimedia/mplayer # make run-depends-list snip /usr/ports/multimedia/linux-realplayer /usr/ports/multimedia/mplayer-skins /usr/ports/multimedia/win32-codecs snip # grep REAL /var/db/ports/mplayer/options WITH_REALPLAYER=true Good catch! I think that is indeed the problem. I disabled realplayer support for mplayer ages ago, so it doesn't show up in my list. Harald, re-build mplayer with realplayer support disabled (if you can do without it), and you should probably loose the dependency on linux-pango. There may be more than one path to the linux-pango dependency however :-( I don't think so, looking at the Makefiles of the other dependencies of lxdvdrip. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpeOU543DK9Q.pgp Description: PGP signature
Re: Vulnerability question
On Sun, Jun 28, 2009 at 10:56:54PM +0200, Harald Weis wrote: Building lxdvdrip stops because linux-pango has known vulnerabilities. You can ignore vulnerabilities by setting the environment variable DISABLE_VULNERABILITIES. See ports(7). Is there a risk if mplayer (which requires linux-pango) Are you running a linux binary of mplayer? Because a native mplayer binary does not require linux-pango! It just uses the native pango. If you want to rip DVDs, you can simply use mplayer: mplayer dvd://N -dumpstream -dumpfile title.mpg where N is the number of the title you want. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpRofftbBERu.pgp Description: PGP signature
Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
On Tue, May 05, 2009 at 09:46:22AM +0200, Daniel Gerzo wrote: Manolis Kiagias wrote: I always use -iU too. I've lost motd, passwd, group and master.passwd During mergemaster -p I was asked to merge changes to some of these, and still they were replaced with the newer versions. I don't know what went wrong but have restored them from backup. (I always tar /etc before a source upgrade). Upgrading another system using freebsd-update did not cause any problem. I have the same experience while I was upgrading a few machines upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when upgrading from 7.1-R to 7.2-R. Here auth.conf, csh.cshrc, hosts, crontab, syslogd.conf, passswd, master.passwd, group, sysctl.conf motd and maybe some more got overwritten :-( I had to restore from backups. When upgrading from 7-STABLE to 7.2-RELEASE mergemaster -s -i -U overwrote all the file I'd changed without asking. Luckily I keep all config files that I've changed in a separate repository, so putting it all back was a question of running an install script. But the change is annoying. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpWWYsyTGg1G.pgp Description: PGP signature
Re: Can i add a new HDD to an encrypted array?
On Fri, May 01, 2009 at 06:12:42PM +1000, ghostcorps wrote: Hi Guys, This seems liek a really basic question, I expect a simple 'no', but I havn't found anything definative yet. I currently have a hardware RAID5 array, using the Intel Matrix RAID capability onboard, encrypted with GELI. According to ataraid(4), Intel MatrixRAID is software RAID, not real hardware RAID. I need to add 2 new discs to the array. If I add a disc to the array and have it rebuilt with the Intel Matrix Storage Manager, prior to booting FreeBSD will that destroy the encrypted data? In short, no. The long answer is that the raid array functions at a level below GELI which in turn is below the filesystem layer. GELI writes its metadata in the last sector of the device, and the ffs(7) filesystem records the size of the underlying device at creation time. Adding the two disks will make the array larger. The metadata for geli will probably not be on the last sector anymore, so geli will not recognize the enlarged device. So you'll have to save your data elsewhere, put in the extra disks, recreate the array, re-initialize and attach the geli device for the new array and newfs(8) the new geli device. If so, how can I decrypt the disk without copying the data to another partition? There are no tools for that at this time, although it should be feasable by reading a (multiple of) block(s) from the geli device and then writing it to the non-encrypted device. Note that whenever you write a block to the unencrypted device, the contents of that block on the geli device become gibberish! So you'll have to do the whole device, unless you can beforehand make a list of all the blocks that are in use by the filesystem. And if even a single block failed in transit, you're potentially screwed. And even if you could perform this in-place decryption, you should make a full backup anyway in case the procedure goes horribly wrong, which is always a possibility. :-) If you want to decrypt the device in place because you don't have enough backup capacity to store the contents of you raid array, you're aleady in trouble even if you don't know it yet. What will you do if your RAID5 fails? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpG1ojnX5EXt.pgp Description: PGP signature
Re: Can i add a new HDD to an encrypted array?
On Fri, May 01, 2009 at 09:02:46PM +1000, ghostcorps wrote: Thanks Roland, You have confirmed my worst fears. Well, there is one thing that _might_ work. It might also destroy your data, hence the first step: - Make a backup and verify it. - Remove the array from fstab, so it isn't mounted automatically. - Add the disks to the array. - Re-initialize and attach the new array as a geli(8) device, using the same password and/or key file and algorithm. - Try to grow the filesystem with growfs(8). - If that works, mount the array and restore it to fstab. Whether this works or not will depend on how the new disks are added to the array. If they are added as a continious space at the rear it will probably be fine. If the extra space shows up as patches in between or at the front it will not work because your filesystem will be hosed. :-) I'm also _assuming_ that if you initialize two geli devices with the same parameters, the on-disk data will be the same. This might not be true, in which case you've lost all your data. Alternatively, you can use dd(1) to make a copy of the geli data from the last sector of the old array, and write it to the last sector of the new array. Again, this might blow up in your face if some of the metadata isn't correct for the new array. So don't try this without a solid backup, for obvious reasons. If this works, you can write it up and submit it as a new section for the Handbook, gaining eternal glory. ;-) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpAFtB6kSu2F.pgp Description: PGP signature
Re: cd ripping to flac
On Sat, Mar 07, 2009 at 08:12:28AM +0100, Zoran Kolic wrote:
Howdy!
I'd like to rip my cd-s to flac files using some
command line app, like cdda2wav or cdparanoia.
Using pipe to flac utility would be nice and the
way I'd take. What program acts in that matter?
It won't work if you want the songs to have the right metadata; You'd
have to supply that to the pipe in some way...
For ripping I use cdparanoia: 'cdparanoia -B 1' rips all tracks.
The following perl scripts reads a text file containing the metadata
(artist, album name, track data) and calls flac:
- make-flac -
#!/usr/bin/perl
#
# Compiles a list of wav files into flac files.
#
# Author: R.F. Smith rsm...@xs4all.nl
# Time-stamp: 2008-07-30 23:53:00 rsmith
#
# I, the copyright holder of this work, hereby release it into
# the public domain. This applies worldwide.
#
# In case this is not legally possible, I grant any entity the right to use
# this work for any purpose, without any conditions, unless such conditions
# are required by law.
# Check for programs that this script needs.
chomp($flac = `which flac 2/dev/null`);
-x $flac || die Cannot find flac: $!\n;
#chomp($norm = `which normalize 2/dev/null`);
#-x $norm || die Cannot find normalize: $!\n;
# Get the name of the file containing the titles.
if ($ARGV[0] ne ) {
$fname = $ARGV[0];
} else {
$fname = titles;
}
# open the list of song titles
open (TITELS, $fname) || die cannot open $fname: $!\n;
# The titles file format is as follows:
#
# album title
# artist
# 01 title of 1st song
# ..
# 14 title of 14th song
# ..
# get the album title and performer name
chomp($album = TITELS);
$album ne || die cannot read album name;
chomp($artist = TITELS);
$artist ne || die cannot read artist name;
# Normalize the wav files.
#printf(Normalizing .wav files...\n);
#`$norm -b track*.cdda.wav`;
# go over all the songs
while(TITELS) {
chomp;
($num, $title) = split (' ', $_, 2);
printf (Encoding \%s\ as %s\n, $title, track.$num..flac);
# invoke the flac encoder.
do {
$rc = system ($flac, -8, -TARTIST=.$artist, -TALBUM=.$album,
-TTITLE=.$title, -TTRACKNUMBER=.$num,
-o, track.$num..flac, track.$num..cdda.wav);
if ($rc != 0) {print \nError,, $rc, starting again;}
} until $rc == 0;
}
- make-flac -
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgp0JdhWd6Ore.pgp
Description: PGP signature
Re: devd question
On Mon, Mar 02, 2009 at 03:23:46PM +0200, Andriy Gapon wrote:
on 28/02/2009 16:34 Kostik Belousov said the following:
On Sat, Feb 28, 2009 at 02:13:10PM +0100, Michael Sperber wrote:
I'm trying to make devd run an stty command whenever a USB serial device
is attached. Unfortunately, $device-name is ucom[0-9] and the device
names are /dev/cuaU[0-9] - how do I get the correct name in the device
action? I haven't found a way to extract the number by itself, so I'm
stuck with specifying a separate rule for each number, like so:
attach 100 {
device-name ucom0;
action stty -f /dev/cuaU0.init raw;
};
Help would be much appreciated!
There are some other notifications that are send through devctl when
cdev is created. They have system set to DEVFS, subsystem to CDEV,
and type CREATE. The data is the /dev node name. I am not sure how
to assign the action in the devd.
A tested example:
notify 1000 {
match systemDEVFS;
match subsystem CDEV;
match cdev ^da[0-9]+$;
action echo 't120o3l32 bc+f+16' /dev/speaker;
};
This system is missing from the devd.conf manual page, nor is DEVFS
mentioned in /usr/share/examples/etc/devd.conf. Is it documented
somewhere else?
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpVl6yd6oKjy.pgp
Description: PGP signature
Re: devd question
On Mon, Mar 02, 2009 at 08:48:53PM +0200, Kostik Belousov wrote:
snip
This system is missing from the devd.conf manual page, nor is DEVFS
mentioned in /usr/share/examples/etc/devd.conf. Is it documented
somewhere else?
No, it is not documented anywhere.
Feel free to send me the documentation patch.
After some digging, I found the function devctl_notify in the kernel
sources (/usr/src/sys/kern/subr_bus.c). Is looks like the only way that events
are sent to devd, correct? If so, I can just use grep -A 1 -R 'devctl_notify('
from /usr/src/sys to find all types of events.
I'll go and pull the source for devd.conf from HEAD and 7-STABLE, and
incorporate what I find. Should I file a PR when I'm done?
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpvRCspLf3U1.pgp
Description: PGP signature
Re: g_vfs_done()...errors
On Sat, Jan 17, 2009 at 01:00:03AM +0100, barbara wrote: Hello, while reading/writing dvd on 6-STABLE (can't remember on 7-STABLE right now), I'm getting the message buffer filled by errors. This is my dvd-rw $ sysctl dev.acd.0.%desc dev.acd.0.%desc: PIONEER DVD-RW DVR-109/1.58 attached to $ sysctl dev.atapci.1.%desc dev.atapci.1.%desc: VIA 8237A UDMA133 controller And the followings are some examples of the error: g_vfs_done():cd0[READ(offset=3533693165190270976, length=2048)]error = 5 g_vfs_done():cd0[READ(offset=8751655366962446336, length=2048)]error = 5 g_vfs_done():cd0[READ(offset=8751655370713257984, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=3533693165190270976, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=8751655366962446336, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=8751655370713257984, length=2048)]error = 5 Is it possible such a value for offset (DVD-SL)? The offset is rediculously large. Does anyone know the reason of the error? I had this problem once with a harddisk. It turned out that the (S)ATA data cable wasn't connected properly. It had probably come somewhat loose when I was putting in a PCI card. Pulling the cable from the drive and re-attaching it again solved the problem in that case. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpEmoZSYc8Em.pgp Description: PGP signature
Re: [HEADS UP] drm merged to -STABLE
On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. Do cards on the PCIE bus still need the agp device? It seems my r535 (radeon X1650Pro) on the PCIE bus can allocate a GART without it. I have the agp module loaded, but there is no /dev/agpgart device. But if I try to unload the module, it says 'can't unload file: Device busy'. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgplE1fFuEAZp.pgp Description: PGP signature
Re: Pending MFC of drm updates
On Tue, Jan 06, 2009 at 12:36:20PM -0500, Robert Noland wrote: I have a patch available for testing at http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2 Excellent! Thanks for your hard work on this, Robert! After updating my source to 7.1-RELEASE, I applied this patch and built and installed a new kernel and world. This went without problems. Starting X on a Sapphire Radeon X1650Pro works OK. XAA 2D accelleration works OK. The X logfile says that direct rendering is enabled, as is Xv. Mplayer works with Xv. But whenever I try to start a program that uses OpenGL (i.e. glxgears) I get the following message: unknown chip id 0x71c1, can't guess. libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering :-( The same number shows in Xorg.0.log: snip (--) PCI:*(1:0:0) ATI Technologies Inc unknown chipset (0x71c1) rev 158, Mem @ 0xe000/28, 0xfe9e/16, I/O @ 0xd000/8, BIOS @ 0xfe9c/17 snip (II) Loading extension XFree86-DGA snip (--) Chipset RV535 found snip (II) RADEONHD(0): Unknown card detected: 0x71C1:0x174B:0x0880. If - and only if - your card does not work or does not work optimally please contact radeo...@opensuse.org to help rectify this. Use the subject: 0x71C1:0x174B:0x0880: name of board and *please* describe the problems you are seeing in your message. (--) RADEONHD(0): Detected an RV535 on an unidentified card (==) RADEONHD(0): Write-combining range (0xfe9e,0x1) was already clear (II) RADEONHD(0): Mapped IO @ 0xfe9e to 0x8006a2000 (size 0x0001) (II) RADEONHD(0): PCIE Card Detected (II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location (II) RADEONHD(0): ATOM BIOS Rom: SubsystemVendorID: 0x174b SubsystemID: 0x0880 IOBaseAddress: 0xd000 Filename: 8C88GCSA.003 BIOS Bootup Message: A67120 RV535XT VO BIOS GDDR3 600E/700M snip (II) RADEONHD(0): Found libdri 5.4.0. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) RADEONHD(0): Found libdrm 1.3.0. (II) RADEONHD(0): Found radeon drm 1.29.0. snip (II) RADEONHD(0): Output DVI-I_2/digital using initial mode 1280x1024 (II) RADEONHD(0): RandR 1.2 support enabled (==) RADEONHD(0): RGB weight 888 (==) RADEONHD(0): Default visual is TrueColor (==) RADEONHD(0): Using gamma correction (1.0, 1.0, 1.0) (II) RADEONHD(0): Using 1280x1280 Framebuffer with 1280 pitch (II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x8000 (size = 0x0064) (**) RADEONHD(0): Display dimensions: (376, 301) mm (**) RADEONHD(0): DPI set to (86, 108) snip (II) RADEONHD(0): On Crtc 0 Setting 60.0 Hz Mode: Modeline 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync I wonder if the framebuffer size is OK? The screen is 1280x1024. That is probably why the DPI is wacky (should both be 86). Should I write the card in to opensuse.org? The card is a Sapphire Radeon X1650Pro. Additionally (but maybe unrelated), when I try to start tyr-glquake, it bombs with an X error: Callback: in_dgamouse ON X Error of failed request: XF86DGANoDirectVideoMode Major opcode of failed request: 137 (XFree86-DGA) Minor opcode of failed request: 2 (XF86DGADirectVideo) Serial number of failed request: 117 Current serial number in output stream: 118 The library libXxf86dga-1.0.2 is installed. I see Xorg loading the extension. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpi4zSgaW1tj.pgp Description: PGP signature
Re: Samsung SCX-4200 printer
On Tue, Jan 06, 2009 at 12:23:54AM +0100, Luigi Rizzo wrote: On Mon, Jan 05, 2009 at 11:26:23PM +0100, Roland Smith wrote: On Mon, Jan 05, 2009 at 05:44:03PM +0100, Erwan David wrote: On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen torfinn.ingolf...@broadpark.no said: On Sun, 04 Jan 2009 23:14:22 +0100 Harald Weis ha...@free.fr wrote: Is there a way to install the SCX-4200 printer on a FreeBSD box ? The printer is delivered with the install software required for Linux. And CUPS does not seem to know it. ... It is not always sufficient. My Brother DCP-540 CN is said to work perfectly, but only with brother binary linux drivers, under linux. I did not find any way to make it work under freeBSD. This should be a FAQ: do yourself a favor and get a printer that supports postscript. It will work with little effort with most UNIX-based program (because they usually support postscript output) and with most spoolers. Actually, this is debatable. If everybody were following your suggestion we wouldn't have support for a lot of devices (printers, disk controllers, scanners, wireless and network devices, embedded systems) that now do work with FreeBSD or other Open Source systems. There is actually one crucial difference between printers and the other classes of hardware you mention. Printers are usually driven by a kind of page/job description language (postscript, pcl, esc2p etc) whereas the others are not. So a printing system that generates e.g. postscript can work with scores of printers. IMHO it is actually a waste of resources to reverse engineer or write drivers for printer manufacturers that need to reinvent the wheel with every model. We are talking about a 70euro laser printer here While I agree that is not a lot of money, it is still a pretty expensive doorstop. it is not unreasonable to take a bit of a risk and try it out, and it is also good for the community to have people willing to test new hardware and report success or failure. That is true enough. But the OP didn't sound like someone who bought a printer to test it. I would not expect those people to need to ask for assistence on freebsd-questions. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpGgD1JSMU3U.pgp Description: PGP signature
Re: Samsung SCX-4200 printer
On Mon, Jan 05, 2009 at 05:44:03PM +0100, Erwan David wrote: On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen torfinn.ingolf...@broadpark.no said: On Sun, 04 Jan 2009 23:14:22 +0100 Harald Weis ha...@free.fr wrote: Is there a way to install the SCX-4200 printer on a FreeBSD box ? The printer is delivered with the install software required for Linux. And CUPS does not seem to know it. As always, check OpenPrinting.org first: http://openprinting.org/show_printer.cgi?recnum=Samsung-SCX-4200 It is not always sufficient. My Brother DCP-540 CN is said to work perfectly, but only with brother binary linux drivers, under linux. I did not find any way to make it work under freeBSD. This should be a FAQ: do yourself a favor and get a printer that supports postscript. It will work with little effort with most UNIX-based program (because they usually support postscript output) and with most spoolers. A postscript printer is probably a bit more expensive than others, but if your printer doesn't work it doesn't matter how affordable is was; it is just an expensive paperweight. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpVr3Hom4c7i.pgp Description: PGP signature
Re: GELI partition mount on boot fails after 7.0 - 7.1-PRERELEASE upgrade
On Tue, Sep 30, 2008 at 02:54:45PM +0300, Kyryll A Mirnenko aka Mirya wrote: I was using a GELI partition for /usr/home on 7.0, so it attaches and mounts on boot. The problem is it stopped working after the system was upgraded to RELENG_7/7.1-PRERELEASE. My GELI encrypted home partition works fine on amd64 7.1-PRERELEASE (updated september 25th). I've been tracking stable since 7.0-RELEASE without problems. My custom kernel includes GEOM_ELI, GEOM_LABEL, GEOM_MIRROR and GEOM_PART_GPT and uses SCHED_ULE. Filesystem options are FFS, SOFTUPDATES, UFS_ACL and UFS_DIRHASH. The ADAPTIVE_GIANT and VFS_AIO options are also part of the kernel. As far as I can see, the geli scripts in /etc/rc.d haven't changed in over a year. HTH, Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp0Y0NMpYN0Y.pgp Description: PGP signature
Re: Temperature monitoring on old desktop - Dell OptiPlex SX270?
On Sun, Aug 03, 2008 at 01:52:51PM +0200, Torfinn Ingolfsen wrote: On Sat, 02 Aug 2008 20:19:12 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: On Sun, Aug 03, 2008 at 01:50:53AM +0200, Torfinn Ingolfsen wrote: The first questions to ask are: 1) does this machine even have a H/W monitoring IC on it, and 2) is it enabled/wired to thermistors and fans? Yes, but so far I haven't found out anything by searching. What processor is in it? Not a Core2Duo. I'm guessing since it's circa 2004, probably a Pentium 3 or 4, or possibly an older AMD. Pentium 4. From dmesg: CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2593.51-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNXT-ID,xTPR Logical CPUs per core: 2 Have you tried sysutils/mbmon? Or running 'sysctl hw.acpi|grep tz'? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpfX4GqhVQRw.pgp Description: PGP signature
Re: how to get more logging from GEOM?
On Wed, Jul 16, 2008 at 02:41:28PM -0700, Jo Rhett wrote: On Jul 11, 2008, at 8:58 AM, Roland Smith wrote: After about 2 weeks of watching it carefully I've learned almost nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now running healthd without complaints) it's not based on any given network traffic... however it does appear to accompany heavy cpu/ disk activity. It usually dies when indexing my websites at night (but not always) and it sometimes dies when compiling programs. Just heavy disk isn't enough to do the job, as backups proceed without problems. Heavy cpu by itself isn't enough to do it either. But if I start compiling things and keep going a while, it will eventually hang. Is there anything else I should be looking at? Power supply or motherboard would be my first guess. If the system went offline, I agree. But it's clearly a kernel deadlock, since the system remains pingable, answers TCP connections, etc etcc but doesn't respond. Ah. Well, you did said the system 'dies', not 'becomes unresponsive'. No TCP negotiation, no response on the console, etc. It's higher level activity which isn't working... Try compiling a kernel with debugging options e.g. WITNESS(4), MUTEX_DEBUG, LOCK_PROFILING, DIAGNOSTIC and INVARIANTS. See /usr/src/sys/conf/NOTES This will create a lot of messages in the dmesg output. If you can hook the system up to another machine via serial console, you might be able to debug the kernel. Read the kernel debugging chapter in the Developers' Handbook. Another tip is to create a cron job that makes log entries every couple of minutes with logger. This might help you pinpoint the exact time of the mishap, to correlate it to other system activity. Be _really_ sure that it isn't hardware though. Otherwise you'll be led on a merry goose chase looking for software errors that aren't there. If you can restore a backup of this machine's software to a similar one, do so and see if the hangs persist. If they don't, it's hardware. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpOV7PD8PdJ6.pgp Description: PGP signature
Re: Failure building apache22 and mysql51
On Wed, Jul 16, 2008 at 11:20:13PM +0100, Chris Rees wrote: 2008/7/14 Sorin Pânca [EMAIL PROTECTED]: I'm sorry for my late response, I was on vacation. I think this was the case (although I thought we have only amd64 machines). Is there a way to recover from this situation by ssh access only? Thank you! Sorin. Chris Rees wrote: Date: Mon, 23 Jun 2008 18:43:04 +0300 From: Sorin P?nca [EMAIL PROTECTED] Hello people! I recently upgraded a amd64 machine from FreeBSD-6.2-RELEASE-p11 to FreeBSD-7.0-RELEASE-p2 using the tutorial found at http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html All went well with the base system. I don't want to patronise, but are you sure you were running FreeBSD/amd64-6.2 before? Looks kinda like you've tried to upgrade from 6.2/i386 to 7.0/amd64. In case you have, you can't do that. Check you haven't disabled and processor-specific extensions in your BIOS, like SSE, that would also create problems if you have optimised your ports. Chris I thought devel/linuxthreads was using some old library so I tried to rebuild it: # cd ../../devel/linuxthreads make install clean # portupgrade -f wouldn't do anything === linuxthreads-2.2.3_23 is only for i386, while you are running amd64. *** Error code 1 Stop in /usr/ports/devel/linuxthreads. Any ideas what to do next? Thank you! Sorin. If I understand you correctly, you want to revert to FreeBSD/i386; in which case I'd advise that you are *extremely* careful, and make sure that everything important is recompiled in i386; FreeBSD/amd64 can run binaries from FreeBSD/i386, but not vice-versa. I *think* that you should be ok running a source update (csup sources, make buildworld installworld kernel) with arch as i386, then reboot, pkg_delete -f portupgrade\*, pkg_add -r portupgrade, portupgrade -faP etc Installworld is supposed to be done after a reboot, in this case (cross-build) you'll have a 32-bit kernel stuck with a 64-bit userland. That won't work. If you do the installworld before the reboot with a cross-buils, it will be the other way around. I'm not sure if the installworld will even complete; every system binary that is replaced will be of the wrong architecture. Don't take my word for it, it is beyond my expertise, I've deliberately made it obtuse; get someone with more knowledge to elucidate :P If you have a spare partition, you could install the new kernel and userland there, and then switch partitions. If that's not an option, make backups of your data and re-install with the i386 version. It's quicker and probably less painfull. :) For changing architectures you'll also have to remove all ports/packages and re-compile/install them for the new architecture. But you should do that anyway when going from 6.x to 7. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpjysPQNzeuU.pgp Description: PGP signature
Re: how to get more logging from GEOM?
On Fri, Jul 11, 2008 at 12:59:33AM -0700, Jo Rhett wrote: About 10 days ago one of my personal machines started hanging at random. This is the first bit of instability I've ever experienced on this machine (2+ years running) FreeBSD triceratops.netconsonance.com 6.2-RELEASE-p11 FreeBSD 6.2- RELEASE-p11 #0: Wed Feb 13 06:44:57 UTC 2008 [EMAIL PROTECTED] :/usr/obj/usr/src/sys/GENERIC i386 After about 2 weeks of watching it carefully I've learned almost nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now running healthd without complaints) it's not based on any given network traffic... however it does appear to accompany heavy cpu/disk activity. It usually dies when indexing my websites at night (but not always) and it sometimes dies when compiling programs. Just heavy disk isn't enough to do the job, as backups proceed without problems. Heavy cpu by itself isn't enough to do it either. But if I start compiling things and keep going a while, it will eventually hang. Is there anything else I should be looking at? Power supply or motherboard would be my first guess. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpYH4pn00ZAc.pgp Description: PGP signature
7-STABLE and Intel G33
My PC has built-in intel G33 graphics, which I'm trying to get to work
in something better then vesa.
Following the instructions in
http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039638.html
I have compiled and installed the driver and kernel modules from the git
trees for drm and the xf86-video-intel driver from today.
I also patched agp_i810.c to remove the comments from the chipset
identifiers and rebuilt the kernel.
After loading the i915.ko kernel module, and starting X with a config
file using the intel driver, I still get;
(II) intel(0): xf86BindGARTMemory: bind key 1 at 0x006ff000 (pgoffset 1791)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 1
at offset 0x6ff000 failed (Invalid argument)
Fatal server error:
Couldn't bind memory for front buffer
In dmesg output I see:
agp0: trying to bind into stolen memory
Looking at the Xorg.0.log, the xf86-video-intel driver and the drm and
dri drivers seem to initialize OK.
Grepping through the source, this error seems to originate in
/usr/src/sys/pci/agp_i810.c;
if ( sc-chiptype != CHIP_I810 ) {
if ( (offset AGP_PAGE_SHIFT) sc-stolen ) {
device_printf(dev, trying to bind into stolen memory);
return EINVAL;
}
[disclaimer: I'm not a software engineer by education or trade, just a
mechanical engineer who likes to tinker with computers and software]
I've been reading the agp code, the intel driver code and I've skimmed
the intel docs. I find the code quite hard to understand, and the intel
docs nigh-on unreadable.
Would modifying the if-statement to not produce this error on the
CHIP_G33 fix this problem? Or would it horribly blow up in my face?
Any help to get this to work would be very much appreciated!
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpNuC3SyiDBc.pgp
Description: PGP signature
Re: cpufreq broken on core2duo (was: powerd is doing nothing?)
On Thu, Jun 05, 2008 at 08:33:24AM +1000, Andrew Snow wrote: Evren Yurtesen wrote: When you say that it doesnt work, does it give an error or? In my case it doesnt give any errors just says it set it but I see that nothing is set. Here's one box: CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a49200600091a device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 Here's another one: CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 I had this on a new core2 quad. Updating to a recent 7-STABLE fixed the issue for me. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpi5G9rM9GtN.pgp Description: PGP signature
Re: g_vfs_done error third part--PLEASE HELP!
On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ar0s1a 20308398 230438 18453290 1%/ devfs 11 0 100%/dev /dev/ar0s1d 21321454 3814482 1580125619%/usr /dev/ar0s1e 50777034 5331686 4138318611%/var /dev/ar0s1f 101554150 18813760 7461605820%/home /dev/ar0s1g 274977824 34564876 21841472414%/share pretty normal I would say. Yes. Did you notice any file corruption in the filesystem on ar0s1g? No the two disks are brand new and I did not encounter any noticeable file corruption. However I assume that nowadays bad sectors on HD are handled by the hardware and do not need any user interaction to correct this. But maybe I'm totally wrong. Every ATA disk has spare sectors, and they usually don't report bad blocks untill the spares are exhausted. In which case it is prudent to replace the disk. Unmount the filesystem and run fsck(8) on it. Does it report any errors? sun# fsck /dev/ar0s1g ** /dev/ar0s1g ** Last Mounted on /share ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=34788357 (272 should be 264) CORRECT? [yn] y INCORRECT BLOCK COUNT I=34789217 (296 should be 288) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * The usual stuff I would say. Disk corruption is never normal. It can be explained by if the machine crashed or was power-cycles before the disks were unmounted, but it can also indicate hardware troubles. Any hints are very much appreciated. So I have to conclude that the write error message does make sense and that something seems to be wrong with the disks. The next question is what can I do about it? Should I return the disks to the shop and ask for new ones? Install sysutils/smartmontools, and run 'smartctl -A /dev/adX|less', where X are the numbers of the drives in the RAID array. In the output, look at the values for Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable, which is the last number that you see on each line. A small number for Reallocated_Sector_Ct is allowable. But non-zero counts for Current_Pending_Sector or Offline_Uncorrectable means it's time to get a new disk. However other people that I have contacted and who had a similar problem before have solved it by using software raid setup instead of a hardware raid setup. This seems to indicate that there is some bug in the FreeBSD code. The RAID support that you find on most desktop motherboards _is_ software RAID. See ataraid(4). Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpNcSsEdIcRL.pgp Description: PGP signature
Re: umass causes panic on 7 amd64
On Mon, May 12, 2008 at 04:19:27PM -0700, Steve Franks wrote: On Mon, May 12, 2008 at 3:50 PM, Roland Smith [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 01:38:51PM -0700, Steve Franks wrote: I have added options USB DEBUG to my kernconf file (DYSTANT). Here is the backtrace: Steve [EMAIL PROTECTED] /usr/obj/usr/src/sys/DYSTANT]$ sudo kgdb kernel.debug /var/crash/vmcore.6 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd. Unread portion of the kernel message buffer: umass0: OLYMPUS C-700 Ultra Zoom, class 0/0, rev 1.10/1.00, addr 3 on uhub2 umass0: SCSI over (unknown 0x00); quirks = 0x0100 panic: /usr/src/sys/dev/usb/umass.c:1453: Unknown proto 0x100 It looks like the camera is not returning a wire protocol. You definitely need to take this to the -usb list. Still shouldn't cause a panic, should it? Yes it should. It calls the 'panic' function. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpOY3iUqfsIc.pgp Description: PGP signature
Re: umass causes panic on 7 amd64
On Mon, May 12, 2008 at 01:38:51PM -0700, Steve Franks wrote: I have added options USB DEBUG to my kernconf file (DYSTANT). Here is the backtrace: Steve [EMAIL PROTECTED] /usr/obj/usr/src/sys/DYSTANT]$ sudo kgdb kernel.debug /var/crash/vmcore.6 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd. Unread portion of the kernel message buffer: umass0: OLYMPUS C-700 Ultra Zoom, class 0/0, rev 1.10/1.00, addr 3 on uhub2 umass0: SCSI over (unknown 0x00); quirks = 0x0100 panic: /usr/src/sys/dev/usb/umass.c:1453: Unknown proto 0x100 It looks like the camera is not returning a wire protocol. You definitely need to take this to the -usb list. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpvxJrXnOyz6.pgp Description: PGP signature
Re: Crash with recent kernel on wireless
On Fri, Apr 25, 2008 at 04:25:14PM +0400, Vladimir Grebenschikov wrote: Hi Recently I've upgraded 7-STABLE: Mar 11 - Apr 24 Everything was fine until I've tried to configure wireless (ath driver, WPA) It crashes every time after interface becomes UP, (I've seen associated in ifconfig output before crash), but before dhcp finished to get IP. % cat /var/crash/info.43 Dump header from device /dev/ad0s2b Architecture: i386 Architecture Version: 2 Dump Length: 162320384B (154 MB) Blocksize: 512 Dumptime: Fri Mar 28 17:24:32 2008 Hostname: vbook.fbsd.ru Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-STABLE #3: Tue Mar 11 19:35:53 MSK 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VBOOK Panic String: non-maskable interrupt trap Dump Parity: 3087556879 Bounds: 43 Dump Status: good kgdb does not shows match (why ?): % kgdb /boot/kernel.bad/kernel /var/crash/vmcore.43 You should use the kernel image with the debugging symbols here. If you build and install a kernel, you get two kernel images on 7.x; 1) /boot/kernel/kernel (your regular kernel) 2) /boot/kernel/kernel.symbols (with the debug symbols) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpRshdS1rZSx.pgp Description: PGP signature
Re: g_vfs_done error third part--PLEASE HELP!
On Mon, Apr 21, 2008 at 09:04:03PM +0200, Willy Offermans wrote: Dear FreeBSD friends, It is already the third time that I report this error. Can someone help me in solving this issue? Probably the reason that you hear so little is that you provide so little information. Most of us are not clairvoyant. Over and over again and always after heavy disk I/O I see the following errors in the log files. If I force ar0s1g to unmount the machine spontaneously reboots. Nothing seriously seems to be damaged by this act, but anyway I cannot afford something bad happening to this production machine. Why would you force an unmount? Apr 18 20:02:19 sun kernel: g_vfs_done():ar0s1g[WRITE(offset=290725068800, length=4096)]error = 5 I have no clue what the errors mean, since offsets of 290725068800, 290725072896, and 290725074944 seem to be ridiculous. Does anybody have a clue what is going on? For starters, how big is ar0s1g? If the offset is in bytes, it is around 270 GB, which is not that unusual in this day and age. I'm using FreeBSD 7.0, but found the error being reported before with previous versions of FreeBSD. I can and will provide more details on demand. What does 'df' say? Did you notice any file corruption in the filesystem on ar0s1g? Unmount the filesystem and run fsck(8) on it. Does it report any errors? Any hints are very much appreciated. Did you manage to create a partition larger than the disk is (using newfs's -s switch)? In that case it could be that you're trying to write past the end of the device. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpfrJ8nxl21I.pgp Description: PGP signature
Re: umass causes panic on 7 amd64
On Thu, Apr 17, 2008 at 07:13:17PM -0400, Garrett Wollman wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: Eh I think I saw something like this myself. Do you by a chance have that new device sg in your kernel? I assume you do (GENERIC) - try to drop it. I am not sure if this is some brokenness of that driver or fighting of several USB drivers over the same hardware. In my experience, umass over EHCI has never worked on any machine ever, going back to 5.x and over multiple kinds of umass devices. (I I've had several machines with VIA chipsets where ehci never was a problem. My current machine has: usb4: VIA VT6202 USB 2.0 controller on ehci0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb4 uhub4: 8 ports with 8 removable, self powered A 256MB usb flash drive works OK with this controller: umass0: vendor 0x3538 USB Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2 on uhub4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Generic USB Flash Disk 0.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 250MB (512000 512 byte sectors: 64H 32S/T 250C) As does an external harddisk enclosure. umass0: JMicron USB to ATA/ATAPI Bridge, class 0/0, rev 2.00/1.00, addr 2 on u hub4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: WDC WD25 00JB-00REA0 0K20 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) I've never had read/write or data corruption problems with these. Only when copying from _and_ to GELI encrypted devices has the transfer stalled occasionally. But that's probably due to my (single core) CPU running out of steam. In my experience machines with Via chipsets have always worked well and are very well supported by FreeBSD's drivers. Likewise I've avoided nvidia stuff because of the lack of support. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpGI2EyxG2mP.pgp Description: PGP signature
Re: umass causes panic on 7 amd64
On Wed, Apr 16, 2008 at 09:10:23AM -0700, Steve Franks wrote: freebsd-stable: as you can see, Roland has been teaching me about crashdumps since my umass brought down one system, and is rather unusable on another. Here's the kgdb output: Best, Steve [EMAIL PROTECTED] /usr/obj/usr/src/sys/GENERIC]$ sudo kgdb kernel.debug /var/crash/vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd. Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xa0208570 frame pointer = 0x10:0xff0001e1ca00 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock sio) Odd. This doesn't seem to have anything to do with usb. It is in a kernel thread that runs the clock and serial port. trap number = 12 panic: page fault cpuid = 0 Uptime: 32s Physical memory: 1002 MB Dumping 96 MB: 81 65 49 33 17 #0 doadump () at pcpu.h:194 194 __asm __volatile(movq %%gs:0,%0 : =r (td)); (kgdb) If you give the 'bt' command (backtrace) here, what does it say? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpuldIAnDUJ7.pgp Description: PGP signature
Re: Digitally Signed Binaries w/ Kernel support, etc.
On Fri, Apr 04, 2008 at 10:58:40AM +0200, Ivan Voras wrote: Signing binaries could be naturally tied in with securelevel, where some securelevel (1?) would mean kernel no longer accepts new keys. If you set the system immutable flag on the binaries, you cannot modify them at all at securelevel 0. Signing the binaries would be pointless in that case. I think these are separate things. Modifying binaries is separate from introducing new binaries. SCHG would prevent the former, but not the latter. If you set the SCHG flag on the directories in $PATH, you can't put anything new there as well. Of course, with the popularity of various scripting languages it's not as useful as it could be on the first thought. If an intruder want to do real damage with a script, he pretty much has to be root. In which case you're already fscked. Or the script must contain a viable local root exploit, which amounts to the same thing. As usual, there is a balance between security and usability. Where that balance lies depends on the situation. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgplXDCPrEXWR.pgp Description: PGP signature
Re: Digitally Signed Binaries w/ Kernel support, etc.
On Thu, Apr 03, 2008 at 01:46:39PM +0200, Ivan Voras wrote: Roland Smith wrote: On Wed, Apr 02, 2008 at 03:09:59PM -0400, Forrest Aldrich wrote: Does FreeBSD have support for digitally signed binary checking, similar to what Linux has with bsign and DigSig, where system binaries are signed and this signature is verified before being run in the kernel? If an attacker can modify binaries, he already has root privileges. In that case, what will stop him from creating a new pgp key and re-sign his doctered binaries? This would be very useful to have to further tighen-down the system. As an alternative, on FreeBSD you can set the system immutable flag on binaries (see chflags(1)), and set the securelevel 0. See init(8). Once this is set, not even root can undo this. You have to reboot to reset the securelevel to -1. Signing binaries could be naturally tied in with securelevel, where some securelevel (1?) would mean kernel no longer accepts new keys. If you set the system immutable flag on the binaries, you cannot modify them at all at securelevel 0. Signing the binaries would be pointless in that case. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpWbasT2kYxd.pgp Description: PGP signature
Re: Digitally Signed Binaries w/ Kernel support, etc.
On Wed, Apr 02, 2008 at 03:09:59PM -0400, Forrest Aldrich wrote: Does FreeBSD have support for digitally signed binary checking, similar to what Linux has with bsign and DigSig, where system binaries are signed and this signature is verified before being run in the kernel? If an attacker can modify binaries, he already has root privileges. In that case, what will stop him from creating a new pgp key and re-sign his doctered binaries? This would be very useful to have to further tighen-down the system. As an alternative, on FreeBSD you can set the system immutable flag on binaries (see chflags(1)), and set the securelevel 0. See init(8). Once this is set, not even root can undo this. You have to reboot to reset the securelevel to -1. The only weakness is that the securelevel is set quite late in the boot process. An attacker could compromise the system if he gets access before the securelevel is set. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp7W9ask9J96.pgp Description: PGP signature
Re: sticky sound on 7 stable
On Fri, Jan 11, 2008 at 03:44:36PM +0100, Julian Stacey wrote: Hi stable@ I have sticky sound flow on 2 different slowish laptops running 7 Stable, Sound plays for a few secs, then breaks for a fraction resumes, repeatedly. I guess fault is not sound config, hence I'm not posting multimedia@, but stable@ where I've seen other Sticky 7 response topics. Much other info on both laptops their BSD conf. here: host=lapd CPU 166M 586 http://www.berklix.com/~jhs/hardware/digital/ host=lapn CPU 133M 586 http://www.berklix.com/~jhs/hardware/laptops/dell_latitude_xpi_p133st/ Many dmesg other debug info linked within, anything else you want please just tell me debug command to run. I'm happy to try src/ sys/ patches etc. Pref. based on 7-stable. Both have /boot/loader.conf: hw.ata.ata_dma=0 # Essential else disk access fails. Could that be it ? both report from xs atacontrol mode ad0 current mode = PIO4 This won't help. Mayby there is a BIOS setting that would enable you to run with dma enabled. I dont know about HZ setting, or different schedulers, but happy On 7.x, it is recommended to use SCHED_ULE. I'm not sure what compiling the kernel with HZ=1000 would accomplish, the default is HZ=100. See Have a look at the sound(4) manual page. There are some sysctls that influence latency; hw.snd.latency_profile and hw.snd.latency. If the problem is IRQ processing, you could try setting dev.pcm.0.polling to 1 if the driver supports it. Another thing to check is if the sound card isn't sharing an interrupt with other devices. The command 'ps -xa | grep irq' would be of use there. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpQ4krOeTJ0D.pgp Description: PGP signature
Re: FreeBSD tar errors on valid empty tar.gz
On Thu, Jan 10, 2008 at 11:55:52PM -, Steven Hartland wrote: A totally empty file is not valid try the following test:- touch empty tar cvzf test.tar.gz --files-from empty tar tvzf test.tar.gz tar: Unrecognized archive format: Inappropriate file type or format tar --version bsdtar 1.2.53 - libarchive 1.2.53 gtar tvzf test.tar.gz gtar --version tar (GNU tar) 1.15.1 Tested on: FreeBSD 6.2-RELEASE-p9 No problem on 7.0-BETA3 (amd64); touch empty tar cvzf test.tar.gz --files-from empty tar tvzf test.tar.gz tar --version bsdtar 2.2.5 - libarchive 2.2.4 ls -l empty test.tar.gz -rw-r--r-- 1 rsmith rsmith 0 Jan 11 01:14 empty -rw-r--r-- 1 rsmith rsmith 45 Jan 11 01:14 test.tar.gz Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpv7sajzYW9X.pgp Description: PGP signature
Re: devfs.rules include rule question in 6.2 release
On Wed, Jan 02, 2008 at 06:23:52PM +1100, Geoff Roberts wrote: Hi, It seems you can't recursively use the include rule specification with devfs in Freebsd 6.2. I couldn't see a note about this in the devfs man page so I'm not sure whether this is expected behaviour or not. The manpages for devfs.conf and devfs.rules do not contain anything about included rulesets because the person who wrote the manual pages doesn't use them. :-) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp2MjWRcvzEJ.pgp Description: PGP signature
Re: Instant Reboot with 7.0 BETA4 LifeFS Disk
On Thu, Dec 27, 2007 at 04:49:47PM -0700, Seth Hieronymus wrote: The specs of the system are: Soltek SL-k8TPro-939 (Via K8T800 Pro ATX) motherboard AMD Athlon64 3800+ Newcastle 2.4GHz Promise FastTrak 579 RAID Controller (PDC20579) 2x Seagate Barracuda 7200 SATA 150 disks in RAID 1 Re-badged Radeon 9600 Pro 256MB 128-bit DDR AGP video card One guess: what if you disable and disconnect your hard disk? This will be helpful to narrow down the issue... Thanks for the response! What you suggested worked -- I removed the SATA cables from both harddrives, and then was able to boot using the 7.0 BETA4 AMD64 LiveFS cd. Not sure it matters, but one interesting thing is that the motherboard also has another SATA controller (irq 20 at device 15.0), which is: atapci1: VIA 6420 SATA150 controller I've got two disks attached in RAID1 to the VIA 6420 controller. Works fine here (7.0-BETA3 FreeBSD amd64). Try connecting your disks to the via controller. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpxfdw6BtCYy.pgp Description: PGP signature
Re: Some processes stay active after killing its PID
On Tue, Nov 27, 2007 at 01:05:21PM +0100, Honza Holakovsky wrote: Thanks for reply, I tried to kill the process via all possibilities described in man kill :) But I didn't know there are some processes which can't be killed, so I tried again running wdfs, but after ps -xacu | grep wdfs I see USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 971 73,9 0,9 19048 5552 ?? Rs1:03od 0:15,36 wdfs no D state :( I'm quite confused, because in state, I have to reboor every time I umount wdfs drive :( By default, the shell uses it's built-in kill function. Try invoking the real kill directly, as root; '/bin/kill -9 971' Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpdJHldKH9Z1.pgp Description: PGP signature
Re: Some processes stay active after killing its PID
On Tue, Nov 27, 2007 at 01:24:56PM -0600, Stephen Montgomery-Smith wrote: On Tue, 27 Nov 2007, Honza Holakovsky wrote: Well, didn't know that, /bin/kill -9 wdfs_PID works, great Thanks a lot, after your advice I read an article about csh built-in commands, never heard of it from any fbsd handbook... I am completely baffled why this worked. Why would /bin/kill -9 work when the built in csh kill -9 wouldn't? According to the manual page for the built-in kill command, it recognizes 'kill -s 9', but not 'kill -9'. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpVAmptlKnGl.pgp Description: PGP signature
Re: re(4) lockups on a MSI K9AG Neo2-Digital (7.0-BETA3 amd64)
On Mon, Nov 26, 2007 at 09:10:43AM +0100, Martin Matuska wrote: Hi, I am using a MSI K9AG Neo2-Digital (MS-7368) mainboard with 7.0-BETA3 in amd64 mode at a german dedicated server provider. The mainboard has a onboard re(4) ethernet controller. I experience a very strange behaiviour: When there are large transfers on the onboard SATA controller the re(4) controller starts to have packet loss. This packet loss does not stop when there is no more load on ata(4). With another high load (like doing a full-system backup) the packet loss keeps increasing up to 90% and more - the system is not accesible over the internet anymore, packets get lost, SSH sessions or http requests get stale, I have to restart the system. One thing you could check is if the network cards are sharing an irq with other hardware; ps -xa | grep '\[irq' If so, you could try to enable device polling(4) with ifconfig. The sysctl kern.polling.enable must be set to 1, and the kernel must be compiled with 'options DEVICE_POLLING'. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpFJM63Sk2wW.pgp Description: PGP signature
Re: Some processes stay active after killing its PID
On Mon, Nov 26, 2007 at 04:30:01PM +0100, Honza Holakovsky wrote: Hi, I'm expecting quite curious problem (currently spotted with usage of audacious (1.3.2 [20070405-4320]) and fusefs-wdfs (1.3.2)) After I finish working with either of these two programs (i.e. closing audacious windown or unmounting wdfs unit), they still run on background, and cosume all remaining cpu performance. Even if I kill its PID, it's still running. top looks like this: How did you kill them? Did you use 'kill -9'? last pid: 21161; load averages: 1.30, 1.33, 1.11 up 0+02:49:43 16:20:56 51 processes: 3 running, 48 sleeping CPU states: 53.1% user, 0.0% nice, 46.5% system, 0.4% interrupt, 0.0%idle Mem: 209M Active, 226M Inact, 105M Wired, 21M Cache, 70M Buf, 54M Free Swap: 2048M Total, 20K Used, 2048M Free PID USERNAMETHR PRI NICE SIZERES STATETIME WCPU COMMAND 19163 root 1 1320 19112K 4948K RUN 14:57 81.88% wdfs 18873 holakac 1 960 79652K 53568K select 13:14 1.66% Xorg 18911 holakac 4 200 104M 81280K kserel 9:06 0.00%firefox-bin Under some circumstances, a process cannot be killed, e.g. if 'px -xacu' has the process in D state. See ps(1). Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgptV0UeNToJr.pgp Description: PGP signature
Re: Is it O.K. to use the 7.0 ports tree on 6.3 ?
On Sat, Nov 24, 2007 at 12:25:32PM +, Pete French wrote: You've already received the right advice about not renaming the INDEX, but I think it's also worth mentioning that untar'ing a static picture of the ports tree is of little practical value unless you never plan to update the base, and you never plan to update any ports on that machine. Sorrty, but I do not understand this at all. Surely untarring the ports file is exactly what the installer does when you install BSD onto a machine? Why is doing it by hand any different ? Not much. Some packages and a tarball of the ports tree are on the installation CD for convenience. If you have a fast internet connection, then don't bother installing stuff from the CD, because it's dated by the time you install it. Install the ports tree with portsnap, and then build the ports you want (or get the latest packages if you don't fancy compiling stuff). That way you'll get the latest ports. You're much better off starting with downloading the tree with csup, that way you can maintain it more easily down the road. Won't running csup on the tree I just untarred work ? I use csup (and have used cvsup in the past) to update ports trees on machines I installed from CD, and it works fine. Unless the installer is doing something other than simply untarring that file I can't see why it isn't just going to work in the same way. For keeping the ports tree up-to-date, portsnap is generally faster. See §4.5 of the Handbook on how to use it. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpDL8xyt4IFR.pgp Description: PGP signature
Re: Progress with usability of AMD64
On Wed, Nov 14, 2007 at 01:59:03PM +1100, Andrew Reilly wrote: On Fri, Sep 28, 2007 at 11:24:41PM +0400, Dmitry Morozovsky wrote: On Fri, 28 Sep 2007, Vivek Khera wrote: VK My list of software is purely server stuff; I VK don't use any FreeBSD desktops. It seems to be the key point here. I'm thinking about giving a try for the following scheme for my development desktop at work: amd64 machine with servers' ports built inside (postgresql-server, apache, etc) with i386 jail with desktop applications (xorg, firefox/nspluginwrappers, MUA, you name it...) ENOTIME so far... Utility is definitely a personal variable. I run a FreeBSD-6-stable workstation at AMD64 and am more or less happy with it, My workstation runs amd64 7.0-BETA2. I'm very happy with it. but I also have a MacOS laptop, which I can fall back to for anything that falls out of the FreeBSD-amd64 capability bucket, like watching the google Android videos on youtube, There's youtube-dl in ports for downloading youtube videos. You can them watch them with your favorite media player. Certainly xorg, firefox (and epiphany, which I prefer) and MUA (thunderbird, evolution, mutt, claws-mail(my pref.)) all work happily in amd64 mode. The only desktop related things that one hears a lot about are the Flash plugin, and the NVidia binary driver. For me those are things that I can happily live without. I certainly don't miss the annoying Flash ads on the Web! Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp3VBWtifIlI.pgp Description: PGP signature
Re: Upgrading FreeBSD Questions
On Tue, Oct 30, 2007 at 07:04:43AM -0700, Jason C. Wells wrote: Jason Slack wrote: I want to try version 7 as it has items of interest to me, but I am not one to continually wipe and reload my machine, can you upgrade from the test releases of 7 available now to the final release when ready? Or do you have to wipe? You can easily upgrade from 7.0-BETA to 7.0-RELEASE without erasing your drive. Historically, FreeBSD has always been upgradeable even through major releases, 4 to 5, 5 to 6. Sometimes that has been more painful than others. Upgrading within a major release, 6.1 to 6.2, has always been pretty easy. Remember to remove old files and libraries with `make delete-old' and `make delete-old-libs' as explained in /usr/src/Makefile. It is advisable to remove and install your ports from scratch when upgrading to a new major version, because the automatic port updating tools don't always do this correctly. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpm6iEtomtTm.pgp Description: PGP signature
Re: Upgrading FreeBSD Questions
On Tue, Oct 30, 2007 at 10:36:27AM -0500, Bruce Burden wrote: On Mon, Oct 29, 2007 at 04:25:18PM -0700, Jason Slack wrote: I want to try version 7 as it has items of interest to me, but I am not one to continually wipe and reload my machine, can you upgrade from the test releases of 7 available now to the final release when ready? Or do you have to wipe? From ports, you install cvsup and you can keep your ports and OS source up to date. No need to do that anymore. A replacement for cvsup called csup is in the base system in 6.x. The last time a full install was preferred was going from the 5.x release to 6.x, I believe, due to differences in GCC 3.x and GCC 4.x. So, it rarely happens. Version 6.x still uses gcc 3.4 as the system compiler. It is 7.x that uses gcc 4.2. I've performed a source upgrade from 6 to 7 without problems. I did however remove all ports and reinstalled them from scratch, to clean out all the ports cruft. There is also some interesting advice about cleaning up your system after a source upgrade in /usr/scr/Makefile. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp83avFdkAsb.pgp Description: PGP signature
Re: portupgrade error with 7.0-BETA1
On Sun, Oct 28, 2007 at 11:31:49PM +0100, Marc UBM Bocklet wrote: and then tried using portupgrade, which promptly fails with: Fatal error 'Cannot allocate red zone for initial thread' at line 382 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) Illegal instruction: 4 (core dumped) (the red zone error ist repeated about 20 times). [snip] This one bit me as well. It's an obsolete library (libthr) in the binary, Recompile ruby18 and problem will go away. You'll find other programs will do this too, but a lot of them disapear after doing a portupgrade. After updated to a new major version of FreeBSD (6-7, not 6.2-6.3) is to make a list of all ports, remove them all with pkg_delete and install them from scratch. That is the only sure way to prevent programs linking to older libraries. And while your at it, it would be a good idea to clean out the old cruft from (/usr)/lib as well. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpxlteOj41v5.pgp Description: PGP signature
Re: Mounting smbfs as user?
On Mon, Oct 22, 2007 at 02:04:15PM +0200, Ivan Voras wrote: On 18/10/2007, Roland Smith [EMAIL PROTECTED] wrote: The user in question probably needs read/write access to the /dev/smbX device in question. There is no such device: # ls /dev/smb* My bad. That's a device for the system management bus. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpzDF78rdz7e.pgp Description: PGP signature
Re: Mounting smbfs as user?
On Thu, Oct 18, 2007 at 04:08:09PM +0200, Ivan Voras wrote: Hi, I'm trying to implement smbfs mounting by regular non-root users and I can't make any progress. vfs.usermount is set to 1. When I try mounting a remote file system, this is what I get: mount_smbfs -I server //[EMAIL PROTECTED]/pre mt Warning: no cfg file(s) found. mount_smbfs: can not setup kernel iconv table (ISO8859-1:tolower): syserr = Operation not permitted The same command works under root, and the appropriate klds are loaded: snip Any ideas? The user in question probably needs read/write access to the /dev/smbX device in question. An elagant solution is to create a group called e.g. smbusers. All the users who need to mount an smb share should be added to this group. Then you have to add the following rule to your /etc/devfs.rules file; [local_ruleset=10] add path 'smb*' mode 0660 group smbusers The following then needs to be set in /etc/rc.conf. devfs_system_ruleset=local_ruleset Then reboot or re-start devfs and try again. Normally when mounting a drive as a normal user, the user in question needs to _own_ the mount point. I'm not sure if this applies to smb devices, but try it. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpCULMLubPSo.pgp Description: PGP signature
Re: buildworld failures on STABLE
On Sun, Oct 07, 2007 at 11:01:16AM +0200, Per olof Ljungmark wrote: On a remote machine currently with RELENG-6 from 20th. June, with STABLE sources from this morning I get build failures in contrib/ similar to: snip /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/lcm.c:801: internal compiler error: Segmentation fault: 11 snip Would this indicate a hardware (memory) problem? Yes. The compiler dying with signal 11 is a typical memory problem. Any way to test remotely? There are memory test applications like memtest86+ (http://www.memtest.org/). You have to boot from it, but it does support a console on a serial port. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpuSDa3WCars.pgp Description: PGP signature
Re: gbde and geli on 6.2
On Wed, Sep 26, 2007 at 11:09:22PM +0100, Chris wrote: Hi I am concerned about the availabilities of these encryptions in freebsd releases that are marked stable. It seems gbde has a problem when the the data written goes over the lba boundary around lba48. http://lists.freebsd.org/pipermail/freebsd-geom/2007-August/002524.html I suffered this problem error example below. Usage at the time was approx 150gig when I first noticed it. g_vfs_done():ad6s1c.bde[WRITE(offset=493964558336, length=131072)]error = 1 After reading about this problem on a few diff hits (all with no response on fixes) I tried geli. However I seen this in geli within an hour of using it. GEOM_ELI: Crypto WRITE request failed (error=1). ad6s1c.eli[WRITE(offset=0, length=131072)] I've been running a GELI encrypted /home partition on 6.2-STABLE amd64 for months without problems. I've had trouble with GELI on usb harddisks, but that seems to be related to the USB/ATAPI controller. The message seems to come from /usr/src/sys/geom/eli/g_eli_integrity.c, in the function g_eli_auth_write_done. But for a more detailed analysys, you'd have to set kern.geom.eli.debug to 3, and see what else pops up. The headers indicate that the error number is used according to errno.h, which lists 1 as being Operation not permitted. Both GELI and GBDE fail with the same length of request. So the error might depend on the underlaying code in the kernel (bio* functions). Are you sure that the disk and controller are working properly? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpAxT4YeDmFk.pgp Description: PGP signature
Re: gbde and geli on 6.2
On Thu, Sep 27, 2007 at 07:35:28PM +0100, Chris wrote: However I seen this in geli within an hour of using it. GEOM_ELI: Crypto WRITE request failed (error=1). ad6s1c.eli[WRITE(offset=0, length=131072)] I've been running a GELI encrypted /home partition on 6.2-STABLE amd64 for months without problems. I've had trouble with GELI on usb harddisks, but that seems to be related to the USB/ATAPI controller. As I said no dma errors or any hd related errors of any sort with encyrption turned off. How big are your drives? I have two 160GB SATA150 drives in a mirrored configuration (VIA Tech V-RAID RAID1). The encrypted partition is 120GB. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp4tOmaoNd3v.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Sun, Jul 01, 2007 at 10:19:03AM +0200, Ulrich Spoerlein wrote: On Wed, 27.06.2007 at 08:12:06 +0200, Roland Smith wrote: Unfortunately I can't check the drives with smartctl; they produce an SCSI error. I'll try 'camcontrol defects', and see if that turns up anything. Please try with atausb. Remove umass/da/scsi from your kernel and add atausb. Might be worth a try. I tested the disk by putting it in another computer and running the manufacturer's diagnostic from the ultimate boot CD (www.ultimatebootcd.com) and it was fine. Other than that, I wish FreeBSD could somehow translate those SMART commands, so it would work with USB/Firewire enclosures of all sorts. It turned out that my enclosure used a USB/firewire chip with known problems, the Prolific PL3507 which has a problem with large transfers. I've ditched it. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpKe4mhjlBgr.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Thu, Jun 28, 2007 at 02:53:31AM +1000, Norberto Meijome wrote: On Wed, 27 Jun 2007 17:05:08 +0100 Alex Zbyslaw [EMAIL PROTECTED] wrote: Manufacturer's diagnostics. Usually: download from manufacturer site, burn onto CD, reboot from CD, voila. good point. these may already be part of the Ultimate boot CD http://www.ultimatebootcd.com/ - never leave home without it ! ;) An update on how it went; I tested the drive in an old PC with the Western Digital tool from the ultimate boot CD. The diagnostics produced no errors. A tip from Paul Mather pointed to problems with USB/firewire chipset, the PL-3507, which was what I found in my enclosure. Most likely this is the culprit. I'm going to buy a new enclosure. Thanks for the help, everybody. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpidkg92zH8m.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Thu, Jun 28, 2007 at 12:24:15PM -0700, Jeremy Chadwick wrote: On Thu, Jun 28, 2007 at 08:55:46PM +0200, Roland Smith wrote: A tip from Paul Mather pointed to problems with USB/firewire chipset, the PL-3507, which was what I found in my enclosure. Most likely this is the culprit. I'm going to buy a new enclosure. Can you provide these details (forward what Paul sent you, etc.)? It would be nice to have this info somewhere in the archives in case someone mails about similar... Here it is; I don't have your original posting, so I don't know what model of chipset you have, though I do dimly recall it being a Prolific, which is why I thought I'd e-mail you. Given that the PL3507 had an early history of problems when writing to it using large transfers (and that GELI uses large transfers, IIRC), and you say that enclosure is old, you might want to see if chipset bugs are the source of your problem. Here is a link I had bookmarked when I was looking for firmware updates for the Prolific PL3507: http://missig.org/julian/blog/2004/06/10/prolific-pl3507-firewire-device/ Here is a link to the corruption issue that plagued various chipsets, including the Prolific PL3507: http://www.bustrace.com/delayedwrite/index.htm -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpiXrpteTMYh.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Wed, Jun 27, 2007 at 03:32:21PM +1000, Norberto Meijome wrote: On Tue, 26 Jun 2007 08:09:48 +0200 Roland Smith [EMAIL PROTECTED] wrote: On Mon, Jun 25, 2007 at 10:45:07PM -0400, Yoshihiro Ota wrote: It's probabry your disk is dying based on your output. I've being using GELI for while, i.e. like a year, with dump/resotre, too. I never had problems with dump/restore. My disk also failed recently with very similer messages. The weird thing is, when I use the USB disk without encryption, it works fine. what happens if you dump your GELI partition first, and then the others? I haven't tried that yet. But I did try dumping to another USB disk with identical harddisk but slightly different enclosure, which worked fine. So I guess that Yoshihiro is right, and the disk is crapping out. Or the enclosure is malfunctioning. Unfortunately I can't check the drives with smartctl; they produce an SCSI error. I'll try 'camcontrol defects', and see if that turns up anything. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpB3ZVLWFsZe.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Wed, Jun 27, 2007 at 08:19:05PM +1000, Norberto Meijome wrote: On Wed, 27 Jun 2007 08:12:06 +0200 Roland Smith [EMAIL PROTECTED] wrote: Unfortunately I can't check the drives with smartctl; they produce an SCSI error. I'll try 'camcontrol defects', and see if that turns up anything. Well, camcontrol didn't work either. :-( possibly because of the USB enclosure. I've had very mixed results with USB cases - some great, some dying for no reason, some working on and off. I would test the drive itself outside the USB enclosure (hopefully you have one that can be pulled apart) and see how that goes. These ones are relatively easy to disassemble, luckily. I have two enclosures of the same brand, but the older (malfunctioning) one has both USB 2 and firewire connections, while the newer one just has a USB 2 connection. See http://www.conceptronic.nl/site/desktopdefault.aspx?tabindex=0tabid=200Cat=60grp=6010ar=450Prod_ID=1393Prod=CHD3UL I'll disassemble the malfunctioning drive, put it in an old PC and run smartctl on it. Are there any other tests that might be worthwhile? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpaMFNaBpTOp.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Wed, Jun 27, 2007 at 09:03:21AM -0700, Jeremy Chadwick wrote: On Wed, Jun 27, 2007 at 05:11:23PM +0200, Roland Smith wrote: Well, camcontrol didn't work either. :-( This doesn't come as much of a surprise; camcontrol expects to talk to a native SCSI device (your drive is ATA). atacontrol expects to talk to a native ATA device, but via adXX, not via umass or any other USB interface. I don't know of any software even on Windows (for comparison) that lets you get SMART stats off of an ATA drive in a USB enclosure via USB. Bummer. Upon opening the enclosure (and violating the warranty), I found that the 2 long ATA33 cable (which was amusing in itself since the device claimed to support ATA100/ATA133 speeds) connecting the drive to the ATA-USB backplane had a couple copper wires exposed, and two of the wire crimping pins were actually sticking outside of the 40-pin connector. I took the unit apart because I had to check the HD's serial number anyway. The connectors looked ok. No visible flaws. The drive was correctly set up as master. It's interesting that the old enclosure feels hotter then the new one, even though they contain the same type HD. Unfortunately the HD itself just passed the warranty date. :( Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgphmX0lr43Fk.pgp Description: PGP signature
Re: dumping large partition to USB drive fails
On Mon, Jun 25, 2007 at 10:45:07PM -0400, Yoshihiro Ota wrote: It's probabry your disk is dying based on your output. I've being using GELI for while, i.e. like a year, with dump/resotre, too. I never had problems with dump/restore. My disk also failed recently with very similer messages. The weird thing is, when I use the USB disk without encryption, it works fine. So, dumping a non-encrypted partition to an encrypted disk works. As does dumping from an encrypted partition to a non-encrypted disk. Only in the case of where both are encrypted it fails. I tried testing the USB disk with smartctl, but it failed with a SCSI command error. :-( Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgphn7Qog39vQ.pgp Description: PGP signature
dumping large partition to USB drive fails
Some background; I'm using a 160GB USB harddisk to write dumps to. This disk is encrypted with GEOM_ELI; umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: WDC WD25 00JB-00REA0 20.0 Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) GEOM_ELI: Device da0.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: software Since I've converted my largest partition (/home) to GEOM_ELI as well, I'm having trouble making backups. slackbox:~$ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ar0s1a496M 88M368M19%/ devfs 1.0K1.0K 0B 100%/dev /dev/ar0s1g.eli120G 65G 46G59%/home /dev/ar0s1e496M 24K456M 0%/tmp /dev/ar0s1f 19G4.5G 13G25%/usr /dev/ar0s1d1.9G147M1.6G 8%/var /dev/da0.eli 226G100G107G48%/mnt/root Backing up non-encrypted partitions like /, /usr and /var works fine. But when I get to /home, the following happens; (da0:umass-sim0:0:0:0): AutoSense Failed GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165967687 68, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165968998 40, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165970309 12, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165971619 84, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165972930 56, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165974241 28, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165975552 00, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165976862 72, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165966376 96, length=131072)] g_vfs_done():da0.eli[WRITE(offset=116596768768, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116596899840, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597030912, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597161984, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597293056, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597424128, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597555200, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597686272, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116596637696, length=131072)]error = 5 GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=65536, len gth=2048)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=6144000, l ength=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=6160384, l ength=6144)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1161638707 20, length=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1163565137 92, length=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165491568 64, length=16384)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165979484 16, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165980794 88, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165982105 60, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165983416 32, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165984727 04, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165984727 04, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165986037 76, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165987348 48, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165988659 20, length=131072)] GEOM_ELI: Crypto WRITE request failed (error=5). da0.eli[WRITE(offset=1165978173 44, length=131072)] g_vfs_done():da0.eli[WRITE(offset=65536, length=2048)]error = 5 g_vfs_done():da0.eli[WRITE(offset=6144000, length=16384)]error = 5 g_vfs_done():da0.eli[WRITE(offset=6160384, length=6144)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116163870720, length=16384)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116356513792, length=16384)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116549156864, length=16384)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116597948416, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116598079488, length=131072)]error = 5 g_vfs_done():da0.eli[WRITE(offset=116598210560, length=131072)]error
Re: Upgrading to amd64 requires recompilation of ports?
On Sat, Jun 16, 2007 at 06:21:40PM -0400, Indigo 23 wrote: Does anyone think that its worth the hassle? If you do manage to get it up and running, will you see any noticeable advantages or is it better to just stick with i386? The only caveat that I can see is a recompilation of all the ports. Any thoughts? You don't really _need_ it unless you've got more than four gigs of RAM and are routinely running out of memory on i386. Then again, I installed amd64 instead of i386 because I could. :-) No regrets so far. Some stuff like binary drivers, flash player, is not available on amd64 (not necessarily a bad thing :-). I think i386 has more ports available as packages. Amd 64 will use some more disk space and RAM. Doing a clean reinstall instead of an upgrade will probably less of a hassle. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpOA3r7si6wO.pgp Description: PGP signature
Re: Problem with external usb harddisk
On Wed, May 30, 2007 at 12:34:05PM +0200, Cédric Devillers wrote: Hello, I have a problem with an external usb harddisk in FreeBSD 5.4. It seems to be recognize but when I try to fdisk it, I have the following message : fdisk: can't open device /dev/da0 fdisk: cannot open disk /dev/da0: Input/output error The kernel dmesg is : umass0: VIA Technologies Inc. USB 2.0 IDE Bridge, rev 2.00/0.03, addr 2 umass0: 8070i (ATAPI) over Bulk-Only; quirks = 0x umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Hitachi HDS721680PLA P21O Fixed Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 78533MB (160836480 512 byte sectors: 255H 63S/T 10011C) umass0: Invalid CSW: tag 7 should be 8 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x10, scsi status == 0x0 Opened disk da0 - 5 Is there a solution? You could try if it works with 6.2. Release 5.4 is old and no longer supported. Some USB mass storage devices have quirks. If they are known, the driver handles them specially. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpnKSW0OHZfC.pgp Description: PGP signature
Re: OT: In defense of a GUI (was: atapicam, blah, blah)
On Fri, May 25, 2007 at 09:46:35AM -1000, Robert Marella wrote: On Fri, 25 May 2007 18:30:00 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] wrote: By the way, I am _not_ using k3b or any other krap. ;-) Best regards Oliver What is Krap to one can be Komfort to another. ;-) I assist a photographer fiend by maintaining her computers, network and doing backups. Being a photographer in Hawaii means she shoots about 200 weddings a year. A typical month will run from 80GB to over 200GB depending upon the time of year and other factors. After about 3 months I will archive the projects to DVD. I make two copies of each DVD so that they can be kept in different locations. Some weddings and other projects will be 20GB or more. Trying to divide these projects over the fewest number of DVDs is quite easy with K3B because I can add or subtract individual files as needed to fill the DVD to the maximum. If someone knows an easy way to do this on the command line I would be more than willing to try it. dirsplit (http://freshmeat.net/projects/dirsplit/) will do the trick nicely. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpPkPKXVjl21.pgp Description: PGP signature
Re: OT: In defense of a GUI (was: atapicam, blah, blah)
On Fri, May 25, 2007 at 10:40:31AM -1000, Robert Marella wrote: dirsplit (http://freshmeat.net/projects/dirsplit/) will do the trick nicely. Roland Roland Thanks for the reply. Mea culpa, I failed to mention that the individual file cannot be spread over different media. After archiving to DVD I than catalog the photos on a Windows machine using Portfolio. Dirsplit doesn't split up files. And you can even tell it to keep directories intact. My photographer will get calls years later from brides wanting a certain picture or two. Using Portfolio she can call up the picture and it will request the specific DVD be installed. CD-R and DVD±R might not be the most reliable form of long term backup, though. I've seen test reports in magazines indicating significant corruption after as little as two years. There are special archival quality disks, but they are more expensive. See e.g. http://www.manifest-tech.com/media_dvd/dvd_compatibility.htm and http://www.digitalfaq.com/media/dvdmedia.htm and http://adterrasperaspera.com/blog/2006/10/30/how-to-choose-cddvd-archival-media/ I like USB harddisks for backups, because of the large and ever growing capacity available, although the cost per gigabyte is currently around 1.75 that of a cheap DVD disk. But problems like splitting up large directories disappear, as does hunting through stacks of DVDs. Other people here are more knowledgeable about things like tape backup, which still seems to be a popular solution for people with large collections of data. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpeJcBnPBV1g.pgp Description: PGP signature
Re: xorg 7.2 start problem
On Wed, May 23, 2007 at 05:29:54PM -0300, JoaoBR wrote: I also haven't read anything and got terrible caught by this 7.2 xorg thing Says it all, really. :-) and kind of lame that portupgrade xorg does not install the modules, And how is portupgrade to know which specific drivers you need? There will always be big ports changes that exceed the capabilities of the automated ports management tools and need manual intervention. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgprQfHaYPRve.pgp Description: PGP signature
Re: xorg 7.2 start problem
On Wed, May 23, 2007 at 06:18:12PM -0300, JoaoBR wrote:
On Wednesday 23 May 2007 17:51:34 Roland Smith wrote:
On Wed, May 23, 2007 at 05:29:54PM -0300, JoaoBR wrote:
I also haven't read anything and got terrible caught by this 7.2 xorg
thing
Says it all, really. :-)
you're not laughing at me aren't you?
A little. Ignoring /usr/{ports|src}/UPDATING usually has predictable results.
Been there, done that. :-)
and kind of lame that portupgrade xorg does not install the modules,
And how is portupgrade to know which specific drivers you need?
good question deserve good answers: how the heck portupgrade did it before?
It didn't. All the drivers were in one huge package, the X server. Now
they are in seperate ports. But the xorg or xorgs-drivers meta-ports
should install all of them.
There will always be big ports changes that exceed the capabilities of
the automated ports management tools and need manual intervention.
absolutely, but only partial correct because the tools are perfectly capable,
the thing is that the process is not really thought through enough when
publishing it
That's funny. :-) If you can't be bothered to read UPDATING, you are not
the person to tell the maintainers that they haven't thought it
through.
Tools like portupgrade and portmaster and even the ports system are
great but they have their limitations. I think they are kept relatively
simple for a reason. It's much better to have a simple (maintainable)
tool that does 95% of the jobs well than to build an extremely
complicated ACME contraption that can cover all the corner cases and
oddball situations. It's just not worth the effort.
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpoEkCp7cPMT.pgp
Description: PGP signature
Re: (no subject)
On Thu, May 10, 2007 at 10:03:41AM +0200, [EMAIL PROTECTED] wrote: I'm trying to get work a WMP54G Linksys Wireless card. I should work with .ko normal driver (ra.ko or ral.ko don'r remember) but it doesn't. The problem might be that wireless card manufacturers sometimes switch the chipset on the card without changing the type number. So before you buy a card, you need to know the chipset that is used on the card, so you can check if it is supported. Sometimes you can see it on the packaging, but usually you have to take a look at the card. And it can happen that all the chips are behind a metal shield, in which case you're out of luck. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp3WpNPYPE0O.pgp Description: PGP signature
Re: Some questions from a newcomer
On Sat, Mar 10, 2007 at 03:23:49PM +0100, Daniel Mouritsen wrote:
I'm playing around with using freebsd for my home server (which used to use
linux), and I have a quick question regarding the distributions you can
select with sysinstall during the install phase.
I've chosen developer(since i wish to use the ports packages, i figured
selecting developer might be a good idea to get gcc and such), user and
minimal.
The C compiler is part of the base system. It is part of the required
binary distributions.
The reason im asking is, all this server is gonna be running is apache, pf
and ntpd to handle the clock. I pretty much want to close down everything
else and make as minimal a system as possible. Any suggestions about the
layout of this machine? Is developer overkill?
Could be. Why not use custom and choose what you want? I've marked the
things that I'd recommend with an 'X'.
│ │ [X] base Binary base distribution (required)
│ │ [X] kernels Binary kernel distributions (required)
│ │ [ ] dict Spelling checker dictionary files
│ │ [X] doc Miscellaneous FreeBSD online docs
│ │ [ ] games Games (non-commercial)
│ │ [X] info GNU info files
│ │ [X] man System manual pages - recommended
│ │ [ ] catmanPreformatted system manual pages
│ │ [ ] proflibs Profiled versions of the libraries
│ │ [X] src Sources for everything
│ │ [X] ports The FreeBSD Ports collection
│ │ [ ] local Local additions collection
│ │ [ ] X.Org The X.Org distribution
If you won't be recompiling the kernel or system binaries you can forgo
installing the source code ('src'). But in general I think it is a good
idea to have the source handy, in case you want to build a custom kernel
or want to patch a vulnerability.
You can always restart sysinstall at a later date, and install
additional stuff if you like.
Things like apache are from ports, and you can install as little as you like.
Also, i was wondering, i tried playing around with portsnap, but dear lord
it was slow :D I tried googling for European mirrors close to me, but i
haven't had much success, any help with finding a faster portsnap server
would be much appreciated
The first time you invoke portsnap ('fetch extract'), it will be slow
because it needs to download a lot. Subsequent invocations ('fetch
update') will be much faster. I'm using portsnap from Europe, and it is
usually faster than a csup from a european mirror.
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgprUvjx9Ef5n.pgp
Description: PGP signature
