Re: FreeBSD on Dell r210 (SAS 6/ir)
On Thu, Feb 3, 2011 at 8:35 AM, Sergio de Almeida Lenzi lenzi.ser...@gmail.com wrote: I have a dell with 2 dual xeon 6 cores, dual thread cpus (24 logical cpus) with that famous perc6 controller, running FreeBSD 8.2 and with journaling FS (one partition) and 2 SAS drivers of 160GB. The controller blocks almost all the time.. message is timeout. I used the mfi config utility (in the ports) and enable write cache. it now works ok (no more timeouts) but sometimes (once a week) it panics the system. A fix in the gjournal appears today (cvsup) and I hope it can fix the problem... I have seen many reports of the mfi timeout problem, and I was seeing this on one of my Dell servers as well. All the problem reports I've seen have involved the mfi driver, but sometimes it is PERC5 or PERC6, other times it has been H700 or H800. It appears we have the same CPU? Intel Xeon X5680 (Intel Westmere). I fixed the timeout problem on my server by updating some settings in the BIOS. Here are the details. The following should all be set to disabled (they are enabled by default): Processor Options: - Turbo Mode - C1E - C-States Turbo mode allows overclocking of the CPU when certain conditions occur. C-States and C1E have to do with ACPI; see the section on Processor States at http://en.wikipedia.org/wiki/Acpi for more info. You may also want to make sure your BIOS is set for Maximum Performance. Sorry, I don't recall off hand which config section this is found under. plw ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: network deamons starting before network!
On Thu, Sep 2, 2010 at 9:45 AM, Peggy Wilkins enli...@gmail.com wrote:
On Fri, Jun 18, 2010 at 2:32 AM, Mark Stapper st...@mapper.nl wrote:
Since updating to 8.X I noticed that network services were started
before the network was up!
I use lagg failover configuration on both my FreeBSD boxes.
First, boot fails on mounting my nfs-shares.
After entering and exiting the rescue shell, the system boots as normal.
uname -a
FreeBSD mario 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #4: Fri Jun 18
07:46:01 CEST 2010 *...@mario:/usr/obj/usr/src/sys/mario amd64
What could I do to fix this?
Here's an exerpt from /var/log/messages:
Jun 18 09:10:25 ntpd[1376]: ntpd 4.2.4p5-a (1)
Jun 18 09:10:25 kernel: fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8
Jun 18 09:10:27 ntpd_initres[1412]: host name not found: yoshi
Jun 18 09:10:27 kernel: nfe0: link state changed to UP
Jun 18 09:10:27 kernel: lagg0: link state changed to UP
Jun 18 09:10:27 kernel: nfe1: link state changed to UP
Jun 18 09:10:27 ntpd_initres[1412]: couldn't resolve `yoshi', giving up
on it
Jun 18 09:10:28 dhclient: New Hostname (lagg0): mario
Jun 18 09:10:28 dhclient: New IP Address (lagg0): 10.58.235.6
Jun 18 09:10:28 dhclient: New Subnet Mask (lagg0): 255.255.255.0
Jun 18 09:10:28 dhclient: New Broadcast Address (lagg0): 10.58.235.255
Jun 18 09:10:28 dhclient: New Routers (lagg0): 10.58.235.1
I upgraded my amd64 FreeBSD-8.0-RELEASE-p4 system to
FreeBSD-8.1-RELEASE earlier this week. After completing the upgrade
and rebooting, I also am having the above reported problem.
I am not using dhcp, I have configured a static IP address.
My system also has nfe NIC. I wonder if this problem is specific to
systems using nfe network driver. The problem was not occuring on my
8.0 system, before the upgrade to 8.1.
Here are my boot messages that display this problem.
[snip]
It is pretty clear that the network services are all getting started
twice, once before dropping to single user shell, and a second time
after exiting single user.
It is also pretty clear that nfe0: link state changed to DOWN is
happening at a bad time; and nothing that requires network to be up is
waiting for it to change to UP.
I have a workaround for this problem, albeit an ugly workaround. I
edited /etc/rc.d/netif to add a 10 second sleep as each network
interface is brought up:
if [ -n ${_ok} ]; then
case ${_func} in
ifn_start)
_str='Starting'
;;
ifn_stop)
_str='Stopping'
;;
esac
echo ${_str} Network:${_ok}.
if check_startmsgs; then
for ifn in ${_ok}; do
/sbin/ifconfig ${ifn}
sleep 10
done
fi
fi
This is probably overkill, and for me it adds 20 seconds to boot time,
but it works for me until the general problem is solved.
I think there is a general bug with the rc.d/rcorder framework,
because even outside this weird case with nfe NIC if any network mount
fails during the early part of rc processing it is repeated in the
late part via mount -a in the second passthrough. This results
potentially in multiple mounts of the same remote filesystem (e.g. if
mount_nfs is backgrounded in the first pass mount_nfs will be run a
second time in the second pass; and if the first problem isn't
resolved the second mount_nfs is also backgrounded. For me this
usually results in two mounts of the same remote filesystem, after the
(presumably temporary) network mounting problem resolves).
plw
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: network deamons starting before network!
On Fri, Jun 18, 2010 at 2:32 AM, Mark Stapper st...@mapper.nl wrote: Since updating to 8.X I noticed that network services were started before the network was up! I use lagg failover configuration on both my FreeBSD boxes. First, boot fails on mounting my nfs-shares. After entering and exiting the rescue shell, the system boots as normal. uname -a FreeBSD mario 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #4: Fri Jun 18 07:46:01 CEST 2010 *...@mario:/usr/obj/usr/src/sys/mario amd64 What could I do to fix this? Here's an exerpt from /var/log/messages: Jun 18 09:10:25 ntpd[1376]: ntpd 4.2.4p5-a (1) Jun 18 09:10:25 kernel: fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Jun 18 09:10:27 ntpd_initres[1412]: host name not found: yoshi Jun 18 09:10:27 kernel: nfe0: link state changed to UP Jun 18 09:10:27 kernel: lagg0: link state changed to UP Jun 18 09:10:27 kernel: nfe1: link state changed to UP Jun 18 09:10:27 ntpd_initres[1412]: couldn't resolve `yoshi', giving up on it Jun 18 09:10:28 dhclient: New Hostname (lagg0): mario Jun 18 09:10:28 dhclient: New IP Address (lagg0): 10.58.235.6 Jun 18 09:10:28 dhclient: New Subnet Mask (lagg0): 255.255.255.0 Jun 18 09:10:28 dhclient: New Broadcast Address (lagg0): 10.58.235.255 Jun 18 09:10:28 dhclient: New Routers (lagg0): 10.58.235.1 I upgraded my amd64 FreeBSD-8.0-RELEASE-p4 system to FreeBSD-8.1-RELEASE earlier this week. After completing the upgrade and rebooting, I also am having the above reported problem. I am not using dhcp, I have configured a static IP address. My system also has nfe NIC. I wonder if this problem is specific to systems using nfe network driver. The problem was not occuring on my 8.0 system, before the upgrade to 8.1. Here are my boot messages that display this problem. (I will note that nfe0 shows no carrier.) Setting hostname: capricorn.lib.uchicago.edu nfe0: link state changed to DOWN Starting Network: lo0 nfe0. lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 nd6 options=3PERFORMNUD,ACCEPT_RTADV nfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=80008VLAN_MTU,LINKSTATE ether 00:1a:92:45:c5:25 inet 128.135.53.92 netmask 0xff00 broadcast 128.135.53.255 media: Ethernet autoselect (none) status: no carrier add net default: gateway 128.135.53.1 Starting devd. Mounting NFS file systems: mount_nfs: quarto: hostname nor servname provided, or not known [snip -- this is repeated for every NFS mount we have configured] ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/kde4/lib /usr/local/lib/qt4 /usr/local/lib/virtualbox /usr/local/lib/zsh 32-bit compatibility ldconfig path: /usr/lib32 Creating and/or trimming log files . Starting syslogd. Starting rpcbind. NFS access cache time=60 rpc.umntall: quarto: MOUNTPROG: RPC: Unknown host [snip -- repeated errors again] Starting amd. Sep 1 17:49:11 capricorn amd[1017]/info: using configuration file /etc/amd.conf Clearing /tmp (X related). Starting mountd. Sep 1 17:49:12 capricorn mountd[1091]: can't get address info for host mozart.lib.uchicago.edu Sep 1 17:49:12 capricorn mountd[1091]: bad host mozart.lib.uchicago.edu, skipping Sep 1 17:49:12 capricorn mountd[1091]: bad exports list line /disk/1 -alldirs mozart.lib.uchicago.edu [snip -- repeated errors for each line in /etc/exports and /etc/zfs/exports] Starting nfsd. Starting statd. Starting lockd. NLM: failed to contact remote rpcbind, stat = 7, port = 28416 Sep 1 17:49:12 capricorn rpcbind: connect from ::1 to getport/addr(status): request from unauthorized host Sep 1 17:49:12 capricorn kernel: NLM: failed to contact remote rpcbind, stat = 7, port = 28416 Starting local daemons: . Starting lpd. Updating motd: . Mounting late file systems: mount_nfs: quarto: hostname nor servname provided, or not known [snip repeated errors] Mounting /etc/fstab filesystems failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Sep 1 17:49:12 capricorn init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh : # nfe0: link state changed to UP = END boot messages excerpt At this point I can fix all issues by killing mountd and syslogd and then exiting single user. The reason to kill mountd is that without doing this two mountd's will be running. The reason to kill syslogd is that if I don't kill it before exiting single user: Starting syslogd. Sep 1 17:53:17 syslogd: bind: Address already in use Sep 1 17:53:17 syslogd: bind: Address already in use syslogd: child pid 1910 exited with return code 1 /etc/rc: WARNING: failed to start syslogd This also causes errors later because there is no /var/run/syslog.pid written (it gets
Re: SSH root login with keys only
On Mon, Apr 5, 2010 at 4:17 AM, Vincent Hoffman vi...@unsane.co.uk wrote: I missed the rest of this thread so sorry its its been said already. As far as I knew the directive PermitRootLogin without-password in /etc/ssh/sshd_config should accomplish what was requested. However a note later in the default sshd_config file regarding the UsePAM setting says 'Depending on your PAM configuration, PAM authentication via ChallengeResponseAuthentication may bypass the setting of PermitRootLogin without-password.' That PAM comment in sshd_config got my attention a number of years ago, so I did a lot of testing of various sshd/pam settings to try and understand what could happen and to try and make some sense out of it. My configurations: in /etc/ssh/sshd_config: PermitRootLogin without-password UsePAM yes in /etc/pam.d/sshd: # auth: open policy: allow OPIE, ldap, and unix password authsufficient pam_opie.so no_warn no_fake_prompts authrequisite pam_opieaccess.so no_warn allow_local authsufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass authrequiredpam_unix.so no_warn try_first_pass Using this configuration I have thoroughly tested on both FreeBSD-7 and (more recently) FreeBSD-8 and root is allowed in via ssh with public key auth only; typing the unix password at it gets permission denied for keyboard-interactive. Non-root users are allowed in via either LDAP password or local unix password as expected. I haven't configured OPIE for root, but it wouldn't bother me if it worked for root in this setup since its design addresses why passwords are insecure in the first place. I use this in production on all my systems and haven't changed any other of FreeBSD's default configurations for sshd. I haven't gone so far as to check source code to see why this works as it does. I'm guessing that PAM may allow passwords for root via something that isn't pam_unix since by design PAM can allow anything. But when using pam_unix, at least, it does observe the without-password setting for root. As always YMMV, but I am happy with this tested setup and so I use it with confidence. Peggy Wilkins Sysadmin, The University of Chicago Library ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
8.0-RELEASE and dangerously dedicated disks
Can someone elaborate on what exactly this statement in the 8.0 detailed release notes means? http://www.freebsd.org/releases/8.0R/relnotes-detailed.html#FS 2.2.5 File Systems “dangerously dedicated” mode for the UFS file system is no longer supported. Important: Such disks will need to be reformatted to work with this release. Due to history I won't go into, all my production (currently 7.2-RELEASE) systems are installed onto dangerously dedicated disks. What exactly do I need to do to upgrade them to 8.0? (I'm not asking for an upgrade procedure, I'm familiar with that, but rather, how this change impacts the upgrade.) I think that the suggestion that the disks need to be reformatted is extreme and I hope something less extreme will suffice. Also, just to be clear, does this statement refer to boot disks, data disks, or both? It doesn't make sense to me that dangerously dedicated could have an impact on UFS filesystems specifically. A partition table is just a partition table, regardless of what filesystems might be written on disks, yes? Am I misunderstanding something here? Thanks for helping to clear up my confusion... plw ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Why do I have to keep doing portsnap extract?
On 5/5/06, Colin Percival [EMAIL PROTECTED] wrote: Peggy Wilkins wrote: On 5/4/06, Colin Percival [EMAIL PROTECTED] wrote: Do you have a .portsnap.INDEX file in your ports tree? Yes; I don't know if it was there before I ran portsnap today, though. -rw-r--r-- 1 root wheel 1230186 May 4 16:39 .portsnap.INDEX Does 'portsnap update' work now? Yes, it does. I will guess that I must have done something to my ports tree (absentmindedly no doubt) that made it not work before. Thanks for the help. -- Peggy Wilkins ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why do I have to keep doing portsnap extract?
On 5/4/06, Colin Percival [EMAIL PROTECTED] wrote: Peggy Wilkins wrote: On 5/4/06, Jason Morgan [EMAIL PROTECTED] wrote: Did you run `extract' after your original `fetch'? Yes, I did; I followed the instructions exactly. I ran portsnap for the first time a couple weeks ago after which I successfully did a bunch of portupgrades. Then the ports tree sat there on my disk untouched for a couple of weeks until I ran portsnap fetch update today. For some reason it insisted that I needed to run extract when as far as I can tell that shouldn't have been necessary. Do you have a .portsnap.INDEX file in your ports tree? Yes; I don't know if it was there before I ran portsnap today, though. -rw-r--r-- 1 root wheel 1230186 May 4 16:39 .portsnap.INDEX plw ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Why do I have to keep doing portsnap extract?
I just recently started using portsnap in lieu of cvsup on my ports tree for FreeBSD-6.0-RELEASE. I thought it was supposed to be more efficient than cvsup, but I'm finding it to be worse. I followed the directions from the Handbook that say to run portsnap fetch update to update the ports tree (assuming it's already been set up previously, which I did a couple weeks ago)... but when the fetch finished, it told me that I needed to run extract before update. Unfortunately, extract takes forever to run, so this is much worse than running cvsup. Am I doing something wrong? I thought I was following the directions in the Handbook. I ran extract the first time I did it, before running update, why do I need to run it again? -- Peggy Wilkins [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why do I have to keep doing portsnap extract?
On 5/4/06, Jason Morgan [EMAIL PROTECTED] wrote: On Thu, May 04, 2006 at 04:40:32PM -0500, Peggy Wilkins wrote: I just recently started using portsnap in lieu of cvsup on my ports tree for FreeBSD-6.0-RELEASE. I thought it was supposed to be more efficient than cvsup, but I'm finding it to be worse. I followed the directions from the Handbook that say to run portsnap fetch update to update the ports tree (assuming it's already been set up previously, which I did a couple weeks ago)... but when the fetch finished, it told me that I needed to run extract before update. Unfortunately, extract takes forever to run, so this is much worse than running cvsup. Am I doing something wrong? I thought I was following the directions in the Handbook. I ran extract the first time I did it, before running update, why do I need to run it again? The first time you run portsnap: # portsnap fetch # portsnap extract Subsequent usage: # portsnap fetch update Did you run `extract' after your original `fetch'? Yes, I did; I followed the instructions exactly. I ran portsnap for the first time a couple weeks ago after which I successfully did a bunch of portupgrades. Then the ports tree sat there on my disk untouched for a couple of weeks until I ran portsnap fetch update today. For some reason it insisted that I needed to run extract when as far as I can tell that shouldn't have been necessary. Is there some configuration information I should be mentioning? I haven't changed anything in /etc/portsnap.conf, I am using all the defaults. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/ports/multimedia/mplayer
On Sat, 5 Feb 2005 00:34:16 +0100, Gert Cuykens [EMAIL PROTECTED] wrote: fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/mplayer/Abyss-1.1.tar.bz2: size mismatch: expected 314296, actual 314264 = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/mplayer and try again. I have had this issue on my system... I'm not quite sure what the real issue is (can't fetch simply replace the file, or is it some other issue?) but I have solved it anyway by simply removing the old files before building: rm -rf /usr/ports/distfiles/mplayer plw ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
