Re: Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0

On Mon, Mar 17, 2008 at 5:03 PM, Daniel Bond [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Now, if I uncomment the line with pam_mkhomedir.so on it, logins stop to work. In /var/log/auth.log I now see two lines appearing: Mar 17 16:46:40 webmail

Re: Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Valerio Daelli wrote: | On Mon, Mar 17, 2008 at 5:03 PM, Daniel Bond [EMAIL PROTECTED] wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | Hi, | Now, if I uncomment the line with pam_mkhomedir.so on it, logins stop to | work. In

Re: Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0

Hi! Daniel Bond wrote: # auth ... This pam.d/ssh config working fine for me: # auth authrequiredpam_nologin.so no_warn authsufficient pam_opie.so no_warn no_fake_prompts authrequisite pam_opieaccess.so

Re: recovering from the 6.3 xorg mess

Date: Mon, 17 Mar 2008 21:23:09 -0800 (AKDT) From: peter stern [EMAIL PROTECTED] This is an ugly way to have to deal with X. So this definitely means the mga driver is broken? I would appreciate a copy of your xorg.conf Thanks for your suggestions. peter Peter, Here is the

Re: hifn(4) causing system lockup

On Mar 17, 2008, at 4:05 PM, Sascha Klauder wrote: I've recently upgraded my 6.2-STABLE workstation to RELENG_7, and I'm now experiencing system lockups that seem to be caused by the hifn(4) driver. I've got a Soekris vpn1401 card to help with GELI disk en- cryption. Reading from a GELI

Using /etc/rc.d/geli with labeled devices on 6.3

Hi, given that /dev/ad12 is a geli encryptet device, you might set up /etc/rc.conf like geli_enable=YES geli_devices=ad12 geli_ad12_flags=-k /root/keys/geli.ad12.key I don't like absolute device names (they might change) so I label them e.g. FOOcrypt so it show up like /dev/label/FOOcrypt

Plentiful NFS debug messages in /var/log/messages

The system is built from source so that: # uname -sr FreeBSD 7.0-RELEASE # cat KERNEL-CONFIG | FILTER-DEBUG options KDB options KDB_TRACE options DDB options WITNESS options WITNESS_SKIPSPIN An NFS client (an

Re: recovering from the 6.3 xorg mess

On Mon, 17 Mar 2008 21:23:09 -0800 (AKDT) peter stern [EMAIL PROTECTED] wrote: On Mon, 17 Mar 2008, Kevin Oberman wrote: Date: Mon, 17 Mar 2008 07:36:23 +0100 From: Kurt Jaeger [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi! I'd appreciate suggestions on how to get a working xorg from

Re: Upgrading to 7.0 - stupid requirements

Kris Kennaway [EMAIL PROTECTED] writes: Then the servers. Why should I reinstall all my databases and such? I always liked that FreeBSD base (OS) is separated from packages. And no matter what I do with the packages, my OS will always work. I don't want dependency hell like in Linux. Now

[releng_7 tinderbox] failure on sparc64/sparc64

TB --- 2008-03-18 18:19:47 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-03-18 18:19:47 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-03-18 18:19:47 - cleaning the object tree TB --- 2008-03-18 18:20:02 - cvsupping the source tree TB --- 2008-03-18 18:20:03 -

Re: Upgrading to 7.0 - stupid requirements

Marko Lerota wrote: Kris Kennaway [EMAIL PROTECTED] writes: Then the servers. Why should I reinstall all my databases and such? I always liked that FreeBSD base (OS) is separated from packages. And no matter what I do with the packages, my OS will always work. I don't want dependency hell like

Re: Upgrading to 7.0 - stupid requirements

Date: Tue, 18 Mar 2008 21:22:52 +0100 From: Kris Kennaway [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Marko Lerota wrote: Kris Kennaway [EMAIL PROTECTED] writes: Then the servers. Why should I reinstall all my databases and such? I always liked that FreeBSD base (OS) is separated

Re: Upgrading to 7.0 - stupid requirements

Kevin Oberman wrote: Or, is the system failing to retrieve the packages and failing over to building the ports? This would take a long time! I always tee the output of portupgrade to a file so, if it dies in the middle, it's pretty easy to pick up where it left off and not re-build everything

Re: Upgrading to 7.0 - stupid requirements

On Tue, Mar 18, 2008 at 8:21 PM, Marko Lerota [EMAIL PROTECTED] wrote: Kris Kennaway [EMAIL PROTECTED] writes: Then the servers. Why should I reinstall all my databases and such? I always liked that FreeBSD base (OS) is separated from packages. And no matter what I do with the

Re: hifn(4) causing system lockup

On Tue, Mar 18, 2008 at 10:25:03AM -0400, Vivek Khera wrote: On Mar 17, 2008, at 4:05 PM, Sascha Klauder wrote: I've got a Soekris vpn1401 card to help with GELI disk en- cryption. Reading from a GELI volume is causing the system to freeze completely, which does not happen if software crypto

Re: +rtfree: 0xffffff0003635780 has 1 refs

On Monday 17 March 2008 20:55:01 Stefan Lambrev wrote: Greetings Dave, Dave Overton wrote: I am new to the AMD64 stable branch, so forgive me if this has been beat to death, but I can't find why this message keeps occurring over and over all day. FreeBSD 7.0 Stable on AMD x2. It works

FreeBSD-4 executables on 7.x/amd64

Hello! I have a 7.0 system (amd64) and am trying to run a FreeBSD-4 executable. It dies on startup with bad system call. The core shows, that it is simply trying to mmap something. I have the following COMPAT-options enabled in my kernel: options COMPAT_43 # Needed by

Re: FreeBSD-4 executables on 7.x/amd64

Mikhail Teterin wrote: Hello! I have a 7.0 system (amd64) and am trying to run a FreeBSD-4 executable. It dies on startup with bad system call. The core shows, that it is simply trying to mmap something. I have the following COMPAT-options enabled in my kernel: options COMPAT_43

Re: hifn(4) causing system lockup

Vivek Khera wrote: On Mar 17, 2008, at 4:05 PM, Sascha Klauder wrote: I've recently upgraded my 6.2-STABLE workstation to RELENG_7, and I'm now experiencing system lockups that seem to be caused by the hifn(4) driver. I've got a Soekris vpn1401 card to help with GELI disk en- cryption.