MD_ROOT and MFS_IMAGE options in 7.2 causes kernel trap
Hello, list. I try to migrate one of my MFS-based system from 7.1 to 7.2 and get kernel trap 12 just after DDB initialisation (screenshot: http://dindin.ru/download/kernel_trap.png) FreeBSD svn revision: r11, architecture: amd64 there was a lot of changes in sys/amd64/amd64/pmap.c and can't really understant which can cause this. I'll appreciate any help. -- Cheers Denis Barov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
nscd again
Hello! I found some strange behaviour of NIS/nscd when NIS in compat mode. In /etc/nsswitch.conf I have: netgroup: cache compat passwd: cache compat group:cache compat #group_compat: cache nis #passwd_compat:cache nis in /etc/nscd.conf: #nscd.conf threads 16 enable-cache passwd yes keep-hot-count passwd 20480 positive-time-to-live passwd 36000 enable-cache group yes keep-hot-count group 20480 positive-time-to-live group 36000 enable-cache group_compat yes keep-hot-count group_compat 20480 positive-time-to-live group.byname 36000 enable-cache passwd_compat yes keep-hot-count passwd_compat 20480 positive-time-to-live passwd_compat 36000 enable-cache netgroup yes keep-hot-count netgroup 20480 positive-time-to-live netgroup 36000 But, when I do some actions on NIS-client host (host with ypbind), host ignoring cached data. In ypserv debug log: ... ypserv: retrieving next key, previous was: [XXX] ypserv: result of lookup: key: [X] data: [XX:*:1168:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [XXX] ypserv: result of lookup: key: [baytin] data: [XX:*:1220:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [XX] ypserv: result of lookup: key: [] data: [:*:3012:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [] ypserv: result of lookup: key: [XXX] data: [XXX:*:3021:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [XXX] ypserv: result of lookup: key: [vereschagin] data: [XXX:*:3024:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [XXX] ... If I set in nsswitch.conf: netgroup: cache compat passwd: cache compat group:cache compat group_compat: cache nis passwd_compat:cache nis I have other errors: Jan 17 21:53:13 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, passwd_compat, setpwent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, setgrent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, getgrent_r, not found Jan 17 21:53:15 mfas002 last message repeated 197 times Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, endgrent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, passwd_compat, endpwent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, endgrent, not found Seems group_compat and passwd_compat databases can't operate with cache sourse. Is that true? -- Denis Barov| /\ Yandex WEB-Search Administration Team | \ / ASCII Ribbon Campaign phone: : +7 (495) 739-70-00 add. 7154 | X NO HTML/RTF in e-mail e-mail: [EMAIL PROTECTED] | / \ NO Word docs in e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is there any hope for MFC nscd?
Hi, Michael! In attachment patch for backporing nscd from RELENG_7 to RELENG_6. Tested on FreeBSD sepulca.yandex.ru 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Dec 23 22:06:36 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/RELENG_6_ncsd/src/sys/GENERIC amd64 and works fine. Must I prepare pr? P.S. Don't forget to mkdir -p src/usr.sbin/nscd/agents before patching ;) Sun, Dec 23, 2007 at 19:34 +0300 Michael Bushkov: Hi Denis, It's actually possible - at first glance it's just the matter of copying a number of quite self-contained chunks of 7th version libc code to the RELENG_6_2 libc + copying the nscd itself. I'll contact some other committers to make sure that there are no other reasons that can prevent such MFC. If everything is ok with it - I can do it. The best way you can help with it is to prepare a patch that I can review and commit :) Is it possible? With best regards, Michael Bushkov On Dec 19, 2007, at 4:00 PM, Denis Barov wrote: Hi, Michael! Is there any hope for MFC nscd into 6.2? Can I help you in this task? Cheers -- Denis Barov Yandex http://www.yandex.ru WEB-Search Administration Team phone: : +7 (495) 739-70-00 add. 7154 e-mail: [EMAIL PROTECTED] Cheers -- Denis Barov Yandex http://www.yandex.ru WEB-Search Administration Team phone: : +7 (495) 739-70-00 add. 7154 e-mail: [EMAIL PROTECTED] pgpKUH1eYoXdZ.pgp Description: PGP signature
Re: is there any hope for MFC nscd?
I'm sorry, seems attachment was stripped by mailserver or somewhat else. Gzipped patch avialable at http://www.dindin.ru/wiki/FreeBSD?action=AttachFiledo=gettarget=nscd_backport.gz (78Kb) Mon, Dec 24, 2007 at 12:15 +0300 Denis Barov: Hi, Michael! In attachment patch for backporing nscd from RELENG_7 to RELENG_6. Tested on FreeBSD sepulca.yandex.ru 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Dec 23 22:06:36 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/RELENG_6_ncsd/src/sys/GENERIC amd64 and works fine. Must I prepare pr? P.S. Don't forget to mkdir -p src/usr.sbin/nscd/agents before patching ;) Sun, Dec 23, 2007 at 19:34 +0300 Michael Bushkov: Hi Denis, It's actually possible - at first glance it's just the matter of copying a number of quite self-contained chunks of 7th version libc code to the RELENG_6_2 libc + copying the nscd itself. I'll contact some other committers to make sure that there are no other reasons that can prevent such MFC. If everything is ok with it - I can do it. The best way you can help with it is to prepare a patch that I can review and commit :) Is it possible? With best regards, Michael Bushkov On Dec 19, 2007, at 4:00 PM, Denis Barov wrote: Hi, Michael! Is there any hope for MFC nscd into 6.2? Can I help you in this task? Cheers -- Denis Barov Yandex http://www.yandex.ru WEB-Search Administration Team phone: : +7 (495) 739-70-00 add. 7154 e-mail: [EMAIL PROTECTED] Cheers -- Denis Barov Yandex http://www.yandex.ru WEB-Search Administration Team phone: : +7 (495) 739-70-00 add. 7154 e-mail: [EMAIL PROTECTED] Cheers -- Denis Barov Yandex http://www.yandex.ru WEB-Search Administration Team phone: : +7 (495) 739-70-00 add. 7154 e-mail: [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: usb bluetooth dongle
AFAIK most of USB bluetooth dongles work fine with ng_ubt, either laptop on-board. Any way you better to ask at [EMAIL PROTECTED] mailing list. On Wed Nov 07, 2007 at 19:13:20 +0100, Marten Vijn wrote: On Wed, 2007-11-07 at 17:45 +0100, Zoran Kolic wrote: Howdy! Does it matter what usb bluetooth dongle I buy while it is class 1 and v2.0? these work fine: ubt0: Broadcom CCBT2035BDGP23-1, class 224/1, rev 1.10/0.01, addr 2 on uhub2 ubt0: Broadcom CCBT2035BDGP23-1, rev 1.10/0.01, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 ubt0: vendor 0x0a12 BT2.0, class 224/1, rev 2.00/19.58, addr 2 on uhub2 ubt0: vendor 0x0a12 BT2.0, rev 2.00/19.58, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ubt0: vendor 0x0df6 Bluetooth 2.0 USB adapter 100m, class 224/1, rev 2.00/19.58, addr 2 on uhub2 ubt0: vendor 0x0df6 Bluetooth 2.0 USB adapter 100m, rev 2.00/19.58, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ubt0: vendor 0x0a12 product 0x0001, class 224/1, rev 2.00/31.64, addr 2 on uhub2 ubt0: vendor 0x0a12 product 0x0001, rev 2.00/31.64, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 these work fine sold as sitecom the 100m version can do over 1000 meters http://www.wifisoft.org/trac/wcc-2007/attachment/wiki/WikiStart/IMG_0127_mod.jpg with a 14 Db (wifi) antenna :) Marten In shop nearby I could get canyon btu4. Any advice what should work on amd64? Also, is gammu the app of choice to send data/wallpaper to nokia phone (6233). If the device itself is important, I will make an effort to find right one. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Denis Barov Yandex http://www.yandex.ru WEB-Search Administtration Team e-mail: [EMAIL PROTECTED] pgpkGdtyofAbh.pgp Description: PGP signature
Re: freebsd-stable Digest, Vol 148, Issue 7
Date: Wed, 1 Mar 2006 23:35:31 - From: Nick [EMAIL PROTECTED] Subject: Remote Installworld To: freebsd-stable@freebsd.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1; I'm currently administering a machine about 1500mi from me with nobody local to the machine to assist me. Anyways, my only access to this machine is via SSH, no remote serial console or anything. When I try to do a make installworld I end up with install: rename: /lib/[EMAIL PROTECTED] to /lib/libcrypt.so.3: Operation not permitted very shortly thereafter. I cannot boot into single user mode because I am far, far away from the machine. What can I do to finish the installworld? Thanks Nick VHCS Webmail -- It's probably because there schg flag set for this file. Try to # chflags noschg /lib/libcrypt.so if your securelevel allows it. Afterward try installworld one more time. Best regards, Denis Barov. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Remote Installworld
The securelevel wouldn't allow me to change the flag. Thanks anyways Nick Try to set kern_securelevel=-1 in /etc/rc.conf, remotely reboot your computer, remove schg flags and do installworld one more time. Set kern_securelevel back and reboot. Best regards, Denis Barov. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
