Re: clock problem
Martin Dieringer wrote: What's the output from ntpq -p? # ntpq -p No association ID's returned # Are you using pf? I think there is some kind of boot time race condition between pf and ntpd. On my firewall (uses FreeBSD 6.2 with pf), I always have to restart ntpd after boot, otherwise it shows no associations. Once I restart ntpd, everything works fine. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble Mounting Seagate HD
Stephen A. Lewis wrote: I am having issues mounting a USB Seagate 300MB HD any suggestions. After you plug in the external drive, are you seeing any messages in /var/log/messages that the drive has been detected by devd/usbd/whatever? I have a 500g WD mybook, and all I do is: 1. plug it in and wait a few seconds 2. mount /dev/da0s1d /mnt (as root) Not much else to it. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: impossible rc.d ordering problem with stf and pf ?
Pete French wrote: 1) You use the interface name as address w/o dynamic lookup. i.e. ... from stf0 ... Yes, thats it - I hadn't come across this 'dynamic lookup' thing before though, so I didn't realise what it was. I still cant find it in the PF manual, aside from a reference that you need to do it for NAT. To 1 and 2 there is a simple sollution: Don't do that then! 1 can easily=20 be defused by adding parentheses. i.e. ... from (stf0) pass out on (stf0) inet6 from any to any keep state Gives me a syntax error when I try and load it with pfctl. If I change it to: pass out on stf0 inet6 from any to any keep state Then it works loading it with pfctl, but now does not work at boot due to the lack of stf0 interface. :-( -pete. This confused me at first. But I believe you only use the dynamic syntax (stf0) in places where the interface name gets converted to an address or network, rather than just specifying an interface. So, for instance pass out on stf0 from (stf0) to any The way I found them all was to look at pfctl -s rules and look for the rules that had the ip address that was causing the problem. For me, this occurred in places where I used the interface name with to, from, and inside the antispoof rule. That fixed my problem with ppp and pf. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: impossible rc.d ordering problem with stf and pf ?
Bruce M. Simpson wrote: Pete French wrote: Am trying to solve a little problem with 'pf'. I have a ruleset which has some firewall rules for the IPv6 interface stf0. This works fine, except when I rreboot the machine, as the pf script is run before the network_ipv6 script - so stf0 does not exist. but I cannot work out how to arrange for stf0 to be created before the pf script is run - as network_ipv6 requires 'routing', but the pf script says it must be run before 'routing', if I am reading the 'REQUIRE' and 'BEFORE' lines correctly. Just chiming in to confirm that this problem definitely exists. I don't have a solution, however, my IPv6 tunnels at home have all expired, so I may well get spare cycles to look at this the same time that I get spare cycles to revive the tunnels. BMS Essentially the same problem exists with pf and ppp. The tun device (on which most of my pf rules depend) does not yet exist when pf is started. Apparently, someone has looked at this before, since there are commands to resync pf and ipf inside the rc.d script for ppp (in ppp_postcmd). But this still doesn't work, since ppp is still negotiating the connection when this function is run, so pf fails a second time. My solution was to jam a sleep 15 inside ppp_postcmd() right before the point the commands to reload pf and ipf are run. It's major ugly, but it works. Hopefully someone will find a better solution to these problems. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: impossible rc.d ordering problem with stf and pf ?
Max Laier wrote: On Sunday 28 January 2007 16:33, Richard Coleman wrote: Bruce M. Simpson wrote: Pete French wrote: Am trying to solve a little problem with 'pf'. I have a ruleset which has some firewall rules for the IPv6 interface stf0. This works fine, except when I rreboot the machine, as the pf script is run before the network_ipv6 script - so stf0 does not exist. but I cannot work out how to arrange for stf0 to be created before the pf script is run - as network_ipv6 requires 'routing', but the pf script says it must be run before 'routing', if I am reading the 'REQUIRE' and 'BEFORE' lines correctly. Just chiming in to confirm that this problem definitely exists. I don't have a solution, however, my IPv6 tunnels at home have all expired, so I may well get spare cycles to look at this the same time that I get spare cycles to revive the tunnels. BMS Essentially the same problem exists with pf and ppp. The tun device (on which most of my pf rules depend) does not yet exist when pf is started. Apparently, someone has looked at this before, since there are commands to resync pf and ipf inside the rc.d script for ppp (in ppp_postcmd). But this still doesn't work, since ppp is still negotiating the connection when this function is run, so pf fails a second time. My solution was to jam a sleep 15 inside ppp_postcmd() right before the point the commands to reload pf and ipf are run. It's major ugly, but it works. Hopefully someone will find a better solution to these problems. In oder to solve these problems you have to understand why pf is failing. This can be for three reasons: 1) You use the interface name as address w/o dynamic lookup. i.e. ... from stf0 ... 2) You use set loginterface sft0 3) You use the interface with ALTQ altq on stf0 ... (now this doesn't work and wouldn't be a good idea either, but for tun0 it makes slightly more sense). To 1 and 2 there is a simple sollution: Don't do that then! 1 can easily be defused by adding parentheses. i.e. ... from (stf0) If more control is required you have to write explicit addresses in your configuration anyway. 2 is obsolete by pfctl -vvsI -i stf0 which has all the counters for all the interfaces. ALTQ is the only remaining problem. I did do some initial patches to tear down altq on interface removal, which could be extended to work the other way 'round on interface arrival - if only I had more time :-\ I remember trying a dynamic interface for tun before, and it failed. But I now see that it was because I also use set logininterface. I didn't think to remove that. Thanks for the help. I'll give it a try. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large msdosfs disk will not mount on RELENG_6
Oliver Fromme wrote: secmgr [EMAIL PROTECTED] wrote: As far as I am aware windows 2000 and xp will only allow you to format up to a 32G dive with FAT32. Any bigger and it will force you to use NTFS. The other strange thing is tht you are trying to mount /dev/da0 and not /dev/de0s1. The 32 gb restriction was artificial. You can look it up in the M$ knowledge base. Watch out for the hand waving. FreeBSD and Linux (and probably other cluefull OS's)can handle a 500gb FAT32 drive (assuming intelligent format values) w/o problem. That's not completely correct, at least as far as FreeBSD is concerned (I don't know if and how Linux solves the problem). The basic problem is that FAT doesn't support what UNIX calls inode numbers (sometimes also called fileid). But for a file system to be able to be handled under Free- BSD (and other UNIX systems), files have to be uniquely identified by such inode numbers. To solve that problem, FreeBSD's msdosfs uses a simple hack by assigning a number to each file based on the offset of its directory entry relative to the beginning of the file system. However, if the size of the file system exceeds 128 MB (which is the size of 2^32 directory entries), then those numbers don't fit into a 32 bit inode number anymore. If you try to mount such a file system, it will fail and print the error message disk too big, sorry. If you compile your kernel with MSDOSFS_LARGE, then the kernel uses a different hack to generate appropriate inode numbers: Whenever you access a file, it assigns a number dynamically for this file. That approach works for FAT file systems of unlimited size, but it has two other draw- backs: First, the kernel needs to maintain a table for mapping between files and inode numbers. So, if the file system contains many files, the kernel will need a huge amount of kernel memory which won't be freed until the FS is unmounted (and if you run out of kernel memory, your machine panics). Second, when you unmount and remount the same file system, you might get different inode numbers for your files (because of the dynamic nature), which can confuse certain applications. In particular it breaks NFS because NFS -- being a stateless protocol -- requires constant inode numbers for exports. Best regards Oliver Thanks for the explanation. That helps a lot. Because of the potential panics that were mention, I can understand a reluctance to change the default. But I suspect that (attempting to) mount a large msdosfs disk is a much more common occurrence than using a smaller msdosfs disk over NFS. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Large msdosfs disk will not mount on RELENG_6
I just bought a large external hard drive for home backups (500g Western Digital My Book). When I plug it in to my machine (RELENG_6 from about a week ago), the system sees the device just fine: Nov 26 22:03:21 neptune kernel: umass0: Western Digital External HDD, rev 2.00/1.06, addr 2 Nov 26 22:03:21 neptune kernel: uhid1: Western Digital External HDD, rev 2.00/1.06, addr 2, iclass 8/6 Nov 26 22:03:21 neptune kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Nov 26 22:03:21 neptune kernel: da0: WD 5000YS External 106a Fixed Direct Access SCSI-4 device Nov 26 22:03:21 neptune kernel: da0: 40.000MB/s transfers Nov 26 22:03:21 neptune kernel: da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) But when I try to mount the drive (mount -t msdos /dev/da0 /mnt), the system gives the following error: Nov 26 22:06:41 neptune kernel: mountmsdosfs(): disk too big, sorry I was surprised to see a file system limitation on FreeBSD that Windows does not have. I will probably reformat the system to ufs2, but thought I would mention this error message. I'm sure these drives will become increasingly common. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large msdosfs disk will not mount on RELENG_6
Clayton Milos wrote: - Original Message - From: Richard Coleman [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Sent: Monday, November 27, 2006 5:23 AM Subject: Large msdosfs disk will not mount on RELENG_6 I just bought a large external hard drive for home backups (500g Western Digital My Book). When I plug it in to my machine (RELENG_6 from about a week ago), the system sees the device just fine: Nov 26 22:03:21 neptune kernel: umass0: Western Digital External HDD, rev 2.00/1.06, addr 2 Nov 26 22:03:21 neptune kernel: uhid1: Western Digital External HDD, rev 2.00/1.06, addr 2, iclass 8/6 Nov 26 22:03:21 neptune kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Nov 26 22:03:21 neptune kernel: da0: WD 5000YS External 106a Fixed Direct Access SCSI-4 device Nov 26 22:03:21 neptune kernel: da0: 40.000MB/s transfers Nov 26 22:03:21 neptune kernel: da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) But when I try to mount the drive (mount -t msdos /dev/da0 /mnt), the system gives the following error: Nov 26 22:06:41 neptune kernel: mountmsdosfs(): disk too big, sorry I was surprised to see a file system limitation on FreeBSD that Windows does not have. I will probably reformat the system to ufs2, but thought I would mention this error message. I'm sure these drives will become increasingly common. Richard Coleman [EMAIL PROTECTED] I am very suprised at all that windows would allow you to format a 500G drive into a single 500G FAT32 partition. As far as I am aware windows 2000 and xp will only allow you to format up to a 32G dive with FAT32. Any bigger and it will force you to use NTFS. The other strange thing is tht you are trying to mount /dev/da0 and not /dev/de0s1. How did you format this drive ? -Clay I didn't format it. This was out of the box. To be honest, I forgot to look to see how much of the disk that Windows XP could see. And I needed to use the drive, so unfortunately I've already nuked the msdosfs stuff and reformatted it with ufs2. Looking at the (meager) documentation that came with the drive, it just says that it was preformatted as a single FAT32 partition for compatibility. As to using da0 rather than da0s1, that's how I've always seen to mount a msdosfs partition (and it works for my 256M usb key drive). Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large msdosfs disk will not mount on RELENG_6
Christian Brueffer wrote: On Sun, Nov 26, 2006 at 10:23:14PM -0500, Richard Coleman wrote: I just bought a large external hard drive for home backups (500g Western Digital My Book). When I plug it in to my machine (RELENG_6 from about a week ago), the system sees the device just fine: Nov 26 22:03:21 neptune kernel: umass0: Western Digital External HDD, rev 2.00/1.06, addr 2 Nov 26 22:03:21 neptune kernel: uhid1: Western Digital External HDD, rev 2.00/1.06, addr 2, iclass 8/6 Nov 26 22:03:21 neptune kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Nov 26 22:03:21 neptune kernel: da0: WD 5000YS External 106a Fixed Direct Access SCSI-4 device Nov 26 22:03:21 neptune kernel: da0: 40.000MB/s transfers Nov 26 22:03:21 neptune kernel: da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) But when I try to mount the drive (mount -t msdos /dev/da0 /mnt), the system gives the following error: Nov 26 22:06:41 neptune kernel: mountmsdosfs(): disk too big, sorry I was surprised to see a file system limitation on FreeBSD that Windows does not have. I will probably reformat the system to ufs2, but thought I would mention this error message. I'm sure these drives will become increasingly common. Please rebuild your kernel with options MSDOSFS_LARGE and try again. - Christian Ahh, good to know. I hadn't seen that one before. Thanks. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large msdosfs disk will not mount on RELENG_6
Rink Springer wrote: On Mon, Nov 27, 2006 at 07:34:09AM +0100, Rink Springer wrote: Looking at /sys/fs/msdosfs/msdosfs_vfsops.c seems to hint the existance of options MSDOSFS_LARGE; this avoids the error message and will let you mount the disk. Oh, and before I forget: this option is defined in /sys/conf/NOTES as well (a pure #ifdef in source code is not enough, of course :-) --- # Experimental support for large MS-DOS filesystems. # # WARNING: This uses at least 32 bytes of kernel memory (which is not # reclaimed until the FS is unmounted) for each file on disk to map # between the 32-bit inode numbers used by VFS and the 64-bit # pseudo-inode # numbers used internally by msdosfs. This is only safe to use in # certain # controlled situations (e.g. read-only FS with less than 1 million # files). # Since the mappings do not persist across unmounts (or reboots), these # filesystems are not suitable for exporting through NFS, or any other # application that requires fixed inode numbers. options MSDOSFS_LARGE --- Regards, It didn't occur to me to check NOTES, since this is on a very GENERIC box. I did check the man pages for both msdosfs and mount_msdosfs, as well as the storage chapter in the handbook. I didn't see this error message or that kernel option mentioned there. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
can't assign requested address with ntpd on 5-STABLE
On 5-STABLE, when I try to start ntpd, I get the following error: bind() fd 7, family 28, port 123, addr fe80:1::2a0:c9ff:fec8:ea25, in6_is_addr_multicast=0 flags=0 fails: Can't assign requested address I've used netstat to check and nothing else is on that port (other than sshd, there is nothing else on the box). My ntp.conf line only has one line server time-a.nist.gov. All other configuration for ntpd is the default. I googled for this error and got several hits. It was suggested to add the line disable auth to ntp.conf. But in this case I still received the same error. I'm am running a recent 5-STABLE box (built yesterday). The kernel is equivalant to GENERIC with the exception that I've commented out the I486_CPU and i586_CPU lines. Anyone else seen this recently. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL in FreeBSD jails
Dag-Erling Smørgrav wrote: There are two possible solutions: - hack the SysV IPC code to use separate namespaces for each jail - make PostgreSQL use POSIX shared memory instead of SysV shared memory I suspect that the latter is significantly easier, and would probably improve performance as well. DES It might be easier to hack PostgreSQL so that the shared memory identifier depends not only on the port, but also on the IP address (which will of course be different for each jail). Or better yet, to be able to specify the shared memory identifier to use directly in the config file. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfsiod tasks started in error
Kris Kennaway wrote: It looks like setting vfs.nfs.iodmin=0 and then klling them off works. We probably should think about changing the default to 0 and setting appropriate values via /etc/rc.d/nfs. Over all, I can't say this is a very high priority though patches would certaintly be accepted. This was a deliberate change by Peter, since if you have NFSCLIENT in the kernel it's assumed you want to use the machine as a NFS client. Kris That seems like a bad assumption. There are many features that are made available in GENERIC (or via module) in which it is not assumed will be used by everyone. I thought the general trend was to get away from requiring everyone to recompile their kernel to configure their box. It's not a big deal to me, since I rebuild my world anyways. But I suspect this question will come up semi-frequently since sysinstall explicitly asks you if you want the machine to be a nfs client. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: downgrading ports
Tejas Kokje wrote: Hi, I just upgraded to perl 5.6 using perl5 port. However some of my scripts are not working due to compatibility problems. How do I revert back to the system (base) version of perl that comes with 4.10. Tejas Kokje 1. Deinstall the perl 5.6 port 2. Type the command use.perl system Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: downgrading ports
Richard Coleman wrote: Tejas Kokje wrote: Hi, I just upgraded to perl 5.6 using perl5 port. However some of my scripts are not working due to compatibility problems. How do I revert back to the system (base) version of perl that comes with 4.10. Tejas Kokje 1. Deinstall the perl 5.6 port 2. Type the command use.perl system Richard Coleman [EMAIL PROTECTED] Oops. My mistake. Reverse the order of these steps, since deinstalling the perl port will deinstall the use.perl command. Richard Coleman [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP!!! USB MFC committed..
Christopher Vance wrote: On Sun, Feb 29, 2004 at 05:01:28PM -0800, Julian Elischer wrote: The USB code in RELENG_4 has been updated to match that in -current. Please test any USB devices that are critical to you BEFORE we release 4.10 :-) gentle flame=no Would the effort to keep making 4.X releases be better spent making 5.X stable, or are the two efforts not competing for the same developer resources? /gentle Keeping the code bases closer together will probably make development easier, not harder. Also, this USB code will now be tested on more hardware before the release of 4.10 or 5.3. I wouldn't be surprised if someone running -stable on strange hardware finds a bug that needs fixing on both -stable and -current. Seems like a win/win to me. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct way to cvsup ports for -stable
If you are talking about updating the ports tree on a single machine via cvsup, then it's easy. Just make a copy of /usr/share/examples/cvsup/ports-supfile and update the name of the cvsup mirror in this config file (say cvsup3.freebsd.org). Then the command cvsup -g -L 2 ports-supfile will get you an updated tree. That's it. If you use portupgrade to manage your ports (recommended), you will then need to execute portsdb -Uu to rebuild your INDEX.db file. To answer your question below, there is only one ports tree. So, even if you are following -STABLE for the base code, you will still follow the HEAD tag (-CURRENT) for the ports tree. So you generally cvsup twice, once for /usr/src and once for /usr/ports. The ports tree is generally pretty stable, so it works out just fine. There are refinements to this procedure if you have many machines or want to keep a copy of the whole CVS tree (for looking at CVS logs, etc). Read the development(7) man page for an example. Richard Coleman [EMAIL PROTECTED] Jozef Babjak wrote: Hi! A similar topic has been disscused here several days ago, but I still don't understand, how correctly update ports tree via cvsup. I have installed 4.9-release. I upgraded to -stable according to /usr/share/examples/cvsup/stable-supfile (I have changed only '*default host=...' line, all rest I kept untouched) and I done make world and kernel... I understand well how to upgrade system, but my questions about ports are: 1) Is it ok to upgrade ports, or do I have keep ports instaled from -release CD? 2) If I should upgrade ports, how exactly? Which file from examples I should use and how I need to modify it? There is nothing about ports upgrade in stable-supfile and ports-supfile deals about -current. Is it enough to use cvs-supfile from examples directory, change a cvsup server and comment out 'doc-all' and 'cvsroot-all', isn't it? Sorry for (maybe) stupid questions; I read comments in stable-supfile and handbook, but this is still not clear for me. Jozef ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
