Re: very stupid mistake: a part of /usr is deleted
But if Zara Kanaeva use freebsd-update that method wont fit her needs. 2010/9/15 Bartosz Stec ad...@kkip.pl: This is a solution I would recommend (if time isn't the problem), first csup fresh 8.X sources, rebuild, upgrade, and as a result you will get more than missing files, but 8.1-RELASE + STABLE patches :). -- Bartosz Stec ___ 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 ___ 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
Re: fbsd8_stable nfsv3 sys=krb5 issue [resolved]
On 16/09/2010 16:44, George Mamalakis wrote: Hi all, I re-decided to move my nfs server from solaris to fbsd. So I am using test machines to see if it works. I have my kerberos realm configured, and seems to work fine, both nfsserver and nfsclient have their host and nfs keytabs stored in /etc/krb5.keytab files, and I am following the configuration instructions from http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup that rick was kind enough to write (thanx rick!). Before analyzing my problem and configuration steps further, let me state the reason for this email: I am not able to access an nfsv3 mounted filesystem when mounted with sys=krb5 (or krb5i, krb5p whatsoever) by following rick's instructions, whereas in the past I had no such problem. To be more specific: Last time I was playing with the configuration most things worked fine (Feb 2010), but now things seem a bit different, and I am not sure whether I have forgotten something fundamental on my configuration or something has changed since I updated both my machines (client and server) to the latest sources: nfs-server: # uname -a FreeBSD fbsdclient.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #1: Wed Sep 15 17:07:13 EEST 2010 r...@fbsdclient.ee.auth.gr:/usr/obj/usr/src/sys/SERVER i386 nfs-client: # uname -a FreeBSD filesrv.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #0: Fri Sep 10 13:08:06 EEST 2010 r...@filesrv.ee.auth.gr:/usr/obj/usr/src/sys/CLIENT amd64 I have my two usual test-users on my test-machines, mamalos and testakis, who both exist as kerberos principals too; their uids and gids are the same on all machines. I am able to kinit to any of them on my machines and acquire a valid kerberos ticket, which makes me assume that kdc runs nicely. fbsd-client's /etc/rc.conf reads: rpcbind_enable=YES mountd_enable=YES mountd_flags=-e nfs_server_enable=YES nfs_client_enable=YES nfsv4_server_enable=YES nfsuserd_enable=YES gssd_enable=YES and fbsd-server's /etc/rc.conf reads: rpcbind_enable=YES nfs_client_flags=-n 4 rpc_statd_enable=YES rpc_lockd_enable=YES #nfsd_flags=-e gssd_enable=YES nfsuserd_enable=YES nfsclient_enable=YES # nfs server nfs_server_enable=YES mountd_enable=YES #mountd_flags=-e Don't get confused that both machines have nfsd enabled (the client is used as an experimental nfsv4 server too), and I think that this should not be an issue with regard to my problem (on the other hand, nobody knows...). the server's kernel-config reads: options KGSSAPI device crypto options NFSCL and the client's kernel-config reads: options NFSD #(don't forget that the client works as an nfsv4 server too) options KGSSAPI device crypto Lastly, the server's /etc/exports reads: /exports-alldirs -sec=krb5 on the server: # ls -la /exports total 10 drwxr-xr-x 5 root wheel - 512 17 Feb 2010 ./ drwxr-xr-x 22 root wheel - 512 15 Sep 19:33 ../ drwxr-xr-x 3 root wheel - 512 5 Feb 2010 m/ drwxr-xr-x 2 mamalos wheel - 512 16 Sep 15:43 mamalos/ drwx-- 2 testakis wheel - 512 4 Feb 2010 testakis/ on the client: # klist klist: No ticket file: /tmp/krb5cc_0 # mount mount_nfs -onfsv3,sec=krb5 server:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server:/exports on /mnt (nfs) # ls -la /mnt total 0 ls: /mnt: Permission denied # exit $ id uid=1001(mamalos) gid=1001(mamalos) groups=1001(mamalos),0(wheel) $ klist klist: No ticket file: /tmp/krb5cc_1001 $ ls -la /mnt total 0 ls: /mnt: Permission denied $ kinit mamalos mama...@example's Password: $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example $ ls -la /mnt total 0 ls: /mnt: Permission denied ... (dooea?!?!?!!?) ... $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example Sep 16 16:27:51 Sep 17 02:26:49 nfs/ser...@example And this is where I don't understand what I have done wrong... If I use sec=krb5:sys in my /etc/exports, and type mount_nfs -onsfsv3,sec=krb5 ...blabla... on the client, everything seems to work ok, but then again no kerberos protection is applicable (I am able to rw in /mnt/mamalos folders as mamalos without having obtained any ticket). I assume that I must have forgotten to include something very fundamental in my configs, but my head is stuck, so if someone has an idea... Thank you all for your time in advance, regards, mamalos Rick, I found the problem once I followed your suggestion to kinit -k fbsdclient.ee.auth.gr on the server; the output was wrong password or something like that. On both server and client I have two keys stored in their /etc/krb5.keytab files: one nfs/blabla and one
Re: very stupid mistake: a part of /usr is deleted
Am Wednesday 15 September 2010 15:36:38 schrieb Zara Kanaeva: can i get the binaries, that was deleted, with sysinstall/distributions/base ? This will restall the missing binaries, but I think there will be installed some original files of the /etc directory, too. I think you changed at least your credentials and /etc/shells. These might get lost. - Michael ___ 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
Re: Policy for removing working code
Hi jhell! On Thu, 09 Sep 2010 12:51:06 -0400; jhell wrote about 'Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)': The situation was: an announcement was made that in X months, all network drivers need to be made to run Giant-free so that FreeBSD can drop Giant from the neworking stack to move forward. Within that period, most of the drivers were updated. Repeated postings were made to the mailing list that the following drivers still have not been converted, and need to be updated or they will be dropped. They weren't; they were droppped. No. See my answer to vwe@ that there were no proper announcements. With them, for example, someone could get sponsored to update these drivers which were needed by those FreeBSD users who can't maintain code themselves. That's a last resort, more likely volunteers will come, but you get the idea. So while it could still work, it was slowing down progress. If it is not ideology, then what is it?.. The fact of the matter is, FreeBSD is a big project with a finite number of developers. We try to keep as much coverage of systems as we can, but a reality of any large software engineering project is that older features sometimes have to be dropped to make progress. From time to time such critical cases could possibly be handled by another ways, I've mentioned one possible above. The code still exists in the repository for any interested party to pick up and modernize. I hope that for this particular case alternative from ports will be enough. But policy is not tied to one particular case, alas. Would you please stop provoking a situation for which you are no more involved in other than running FreeBSD. You either not understanding that this situation is about entire project (not ISDN, but policy) or assert that users just running FreeBSD should not care about the way things happen, which is wrong. And thus your stop provoking sounds like ostrich policy, which is even worse. PS: The website in your signature is broke. This should give you enough to do for a while. You may have noted in whois that I am not that site admin. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ 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
Re: Policy for removing working code
Hi Julian H. Stacey! On Fri, 10 Sep 2010 11:20:10 +0200; Julian H. Stacey wrote about 'Re: Policy for removing working code': If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a errata fix branch), then they should be reading the stable@ list. True for RELENG_X, but not for RELENG_X_Y. They shouldn't, because all information for security/errata fix branch go to announce@, they don't need to read all noise in stable@ just for this. And, what is more important, they in fact don't do. So announce@ is the only choice from purely practical means. One option could be a new list perhaps called eg one of features@ advisories@ notifications@ feature-notifications@ to carry heads up notification of future feature changes / removals. Its would be more traffic than announce@ but much lower traffic than stable@ FreeBSD already has the precedent of security-notifications@ Umm, no: security-notifications@ is not an addon to, but rather a subset of announce@ for those who don't care about anything except the most important events - security. So announce@ would be sufficient - and Handbook already states that things like call for volunteers go to announce@ (and many feature removal notifications may be not certain if there will be volunteers then). But perhaps your idea is applicable to www.freebsd.org, though. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ 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
Re: Policy for removing working code
Hi jhell! On Sat, 11 Sep 2010 23:26:04 -0400; jhell wrote about 'Re: Policy for removing working code': Just send these notices to -announce. The removal of stuff like this doesn't happen often, and as long as we're careful with the frequency and content of the messages I can't imagine people would complain too much. I agree with Doug on this. No need to add another layer of complexity to the already existing lists. Just use them properly. Besides wouldn't it make sense to publish the top three or five recent posts to announce@ to a reserved space on the CMS rather than relying on consumers to subscribe to the list at all. I know errata notices get announced I would think a heads up around the board about big changes like removing portions of code completely should be announced as well. Good idea. I think the web site is viewed by more people than read annou...@. FreeBSD-CA-??? Change Announcement? for that are constructed much of the same way the SA EN are ?. No, as this is not certain - if volunteers will answer the call, feature may survive instead of removal. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ 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
Re: Crashes on X7SPE-HF with em
In the end this turned out to be faulty hardware, at least the mainboard
died a tragic death and has to be replaced now.
Thanks for the help anyway and sorry for the noise!
Greetings,
philipp
Philipp Wuensche wrote:
Hi,
I'm having trouble with a system on a Supermicro X7SPE-HF, it crashes
about once a day. I haven't found a way to trigger this yet.
The system has a bunch of VLANs on em1, it does routing between them.
Currently its running 8-STABLE but it happend with 8.1-RELEASE too.
greetings,
Philipp
# kgdb kernel.debug /var/crash/vmcore.0
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 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8061f5a8
stack pointer = 0x28:0xff8e64d0
frame pointer = 0x28:0xff8e64e0
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 = 0 (em1 taskq)
trap number = 9
panic: general protection fault
cpuid = 0
Uptime: 13h24m39s
Physical memory: 4079 MB
Dumping 1349 MB: 1334 1318 1302 1286 1270 1254 1238 1222 1206 1190 1174
1158 1142 1126 1110 1094 1078 1062 1046 1030 1014 998 982 966 950 934
918 902 886 870 854 838 822 806 790 774 758 742 726 710 694 678 662 646
630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358
342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54
38 22 6
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from
/boot/kernel/coretemp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/coretemp.ko
Reading symbols from /boot/kernel/ahci.ko...Reading symbols from
/boot/kernel/ahci.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ahci.ko
Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from
/boot/kernel/ipmi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipmi.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from
/boot/kernel/smbus.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/smbus.ko
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
#0 doadump () at pcpu.h:224
224 __asm(movq %%gs:0,%0 : =r (td));
(kgdb) list *0x8061f5a8
0x8061f5a8 is in m_tag_locate (/usr/src/sys/kern/uipc_mbuf2.c:389).
384 if (t == NULL)
385 p = SLIST_FIRST(m-m_pkthdr.tags);
386 else
387 p = SLIST_NEXT(t, m_tag_link);
388 while (p != NULL) {
389 if (p-m_tag_cookie == cookie p-m_tag_id == type)
390 return p;
391 p = SLIST_NEXT(p, m_tag_link);
392 }
393 return NULL;
(kgdb) backtrace
#0 doadump () at pcpu.h:224
#1 0x805c25ce in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:416
#2 0x805c29dc in panic (fmt=0x0)
at /usr/src/sys/kern/kern_shutdown.c:590
#3 0x808d40bd in trap_fatal (frame=0x80c8af60,
eva=Variable eva is not available.
)
at /usr/src/sys/amd64/amd64/trap.c:777
#4 0x808d4a8b in trap (frame=0xff8e6420)
at /usr/src/sys/amd64/amd64/trap.c:588
#5 0x808b9d64 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:224
#6 0x8061f5a8 in m_tag_locate (m=0xff010bb45c00, cookie=0,
type=6, t=Variable t is not available.
) at /usr/src/sys/kern/uipc_mbuf2.c:388
#7 0x806d7c56 in ip_ipsec_output (m=0xff8e6598,
inp=0xff010be43150, flags=0xff8e6594,
error=0xff8e65a8, ifp=Variable ifp is not available.
) at mbuf.h:1006
#8 0x806d97ef in ip_output (m=0xff010bb45c00, opt=Variable
opt is not available.
)
at /usr/src/sys/netinet/ip_output.c:483
#9 0x8073ef13 in tcp_output (tp=0xff000a9eb370)
at
Re: Policy for removing working code
on 17/09/2010 12:14 Vadim Goncharov said the following: You either not understanding that this situation is about entire project (not ISDN, but policy) or assert that users just running FreeBSD should not care about the way things happen, which is wrong. And thus your stop provoking sounds like ostrich policy, which is even worse. You either don't understand the situation or are a troll. People who actively participate(d) in the project/community were very well aware of the issue. Following the generalized principle of locality it was not expected that much help would come from people who didn't already sufficiently participate. This much belated and non-productive thread is a perfect demonstration. -- Andriy Gapon ___ 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
Re: How to predict drive number change for 7.3-8.1 upgrade?
Michael Sperber sper...@deinprogramm.de wrote: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? Remove options ATA_STATIC_ID from your kernel config before building the new kernel and rebooting. Then your first disk will be ad0, no matter what controller and channel it is connected to. Be sure to update your /etc/fstab file. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I have stopped reading Stephen King novels. Now I just read C code instead. -- Richard A. O'Keefe ___ 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
Re: How to predict drive number change for 7.3-8.1 upgrade?
Oliver Fromme o...@lurza.secnetix.de writes: Michael Sperber sper...@deinprogramm.de wrote: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? Remove options ATA_STATIC_ID from your kernel config before building the new kernel and rebooting. Then your first disk will be ad0, no matter what controller and channel it is connected to. Be sure to update your /etc/fstab file. Ah, excellent - that's what I was looking for. Thanks! -- Regards, Mike ___ 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
Re: How to predict drive number change for 7.3-8.1 upgrade?
Michael Sperber wrote: Oliver Frommeo...@lurza.secnetix.de writes: Michael Sperbersper...@deinprogramm.de wrote: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? Remove options ATA_STATIC_ID from your kernel config before building the new kernel and rebooting. Then your first disk will be ad0, no matter what controller and channel it is connected to. Be sure to update your /etc/fstab file. Ah, excellent - that's what I was looking for. Thanks! beware of drago^Wchanging of adX numbers each time you add/remove drive ;) It's better to label filesystems, imho ;) -- SY, Marat
Re: How to predict drive number change for 7.3-8.1 upgrade?
Marat N.Afanasyev ama...@ksu.ru writes: Michael Sperber wrote: Oliver Frommeo...@lurza.secnetix.de writes: Michael Sperbersper...@deinprogramm.de wrote: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? Remove options ATA_STATIC_ID from your kernel config before building the new kernel and rebooting. Then your first disk will be ad0, no matter what controller and channel it is connected to. Be sure to update your /etc/fstab file. Ah, excellent - that's what I was looking for. Thanks! beware of drago^Wchanging of adX numbers each time you add/remove drive ;) It's better to label filesystems, imho ;) This is a rented server, so I no drive will ever be removed or added. On the other hand, if I understand it correctly, I'll need to unmount the root partition in order to label it - right? -- Regards, Mike ___ 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
Re: How to predict drive number change for 7.3-8.1 upgrade?
Michael Sperber wrote: Marat N.Afanasyevama...@ksu.ru writes: Michael Sperber wrote: Oliver Frommeo...@lurza.secnetix.de writes: Michael Sperbersper...@deinprogramm.de wrote: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? Remove options ATA_STATIC_ID from your kernel config before building the new kernel and rebooting. Then your first disk will be ad0, no matter what controller and channel it is connected to. Be sure to update your /etc/fstab file. Ah, excellent - that's what I was looking for. Thanks! beware of drago^Wchanging of adX numbers each time you add/remove drive ;) It's better to label filesystems, imho ;) This is a rented server, so I no drive will ever be removed or added. On the other hand, if I understand it correctly, I'll need to unmount the root partition in order to label it - right? you may try the following commands: sysctl kern.geom.debugflags=16 foreach fs (your-filesystems) glabel label your-$fs-label your-$fs-device end echo geom_label_load=YES /boot/loader.conf reboot and see if the labels appear in /dev/label -- SY, Marat
Re: How to predict drive number change for 7.3-8.1 upgrade?
Marat N.Afanasyev ama...@ksu.ru writes: you may try the following commands: sysctl kern.geom.debugflags=16 foreach fs (your-filesystems) glabel label your-$fs-label your-$fs-device end echo geom_label_load=YES /boot/loader.conf reboot and see if the labels appear in /dev/label Is this safe to do? The man page for glabel seems to imply that glabel should be used before newfs, and tunefs after newfs. -- Regards, Mike ___ 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
Re: Crashes on X7SPE-HF with em
Maybe it is related with
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2010-01/msg00021.html
which is still not in 8-STABLE
On Fri, Sep 17, 2010 at 12:36 PM, Philipp Wuensche cryx-free...@h3q.com wrote:
In the end this turned out to be faulty hardware, at least the mainboard
died a tragic death and has to be replaced now.
Thanks for the help anyway and sorry for the noise!
Greetings,
philipp
Philipp Wuensche wrote:
Hi,
I'm having trouble with a system on a Supermicro X7SPE-HF, it crashes
about once a day. I haven't found a way to trigger this yet.
The system has a bunch of VLANs on em1, it does routing between them.
Currently its running 8-STABLE but it happend with 8.1-RELEASE too.
greetings,
Philipp
# kgdb kernel.debug /var/crash/vmcore.0
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 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8061f5a8
stack pointer = 0x28:0xff8e64d0
frame pointer = 0x28:0xff8e64e0
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 = 0 (em1 taskq)
trap number = 9
panic: general protection fault
cpuid = 0
Uptime: 13h24m39s
Physical memory: 4079 MB
Dumping 1349 MB: 1334 1318 1302 1286 1270 1254 1238 1222 1206 1190 1174
1158 1142 1126 1110 1094 1078 1062 1046 1030 1014 998 982 966 950 934
918 902 886 870 854 838 822 806 790 774 758 742 726 710 694 678 662 646
630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358
342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54
38 22 6
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from
/boot/kernel/coretemp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/coretemp.ko
Reading symbols from /boot/kernel/ahci.ko...Reading symbols from
/boot/kernel/ahci.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ahci.ko
Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from
/boot/kernel/ipmi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipmi.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from
/boot/kernel/smbus.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/smbus.ko
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
#0 doadump () at pcpu.h:224
224 __asm(movq %%gs:0,%0 : =r (td));
(kgdb) list *0x8061f5a8
0x8061f5a8 is in m_tag_locate (/usr/src/sys/kern/uipc_mbuf2.c:389).
384 if (t == NULL)
385 p = SLIST_FIRST(m-m_pkthdr.tags);
386 else
387 p = SLIST_NEXT(t, m_tag_link);
388 while (p != NULL) {
389 if (p-m_tag_cookie == cookie p-m_tag_id == type)
390 return p;
391 p = SLIST_NEXT(p, m_tag_link);
392 }
393 return NULL;
(kgdb) backtrace
#0 doadump () at pcpu.h:224
#1 0x805c25ce in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:416
#2 0x805c29dc in panic (fmt=0x0)
at /usr/src/sys/kern/kern_shutdown.c:590
#3 0x808d40bd in trap_fatal (frame=0x80c8af60,
eva=Variable eva is not available.
)
at /usr/src/sys/amd64/amd64/trap.c:777
#4 0x808d4a8b in trap (frame=0xff8e6420)
at /usr/src/sys/amd64/amd64/trap.c:588
#5 0x808b9d64 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:224
#6 0x8061f5a8 in m_tag_locate (m=0xff010bb45c00, cookie=0,
type=6, t=Variable t is not available.
) at /usr/src/sys/kern/uipc_mbuf2.c:388
#7 0x806d7c56 in ip_ipsec_output (m=0xff8e6598,
inp=0xff010be43150, flags=0xff8e6594,
error=0xff8e65a8, ifp=Variable ifp is not available.
) at mbuf.h:1006
#8 0x806d97ef in ip_output
WITHOUT_MODULES: does it work?
Hello, Freebsd-stable. I'm trying to build very small FreeBSD installation (8.1-STABLE) and trying to use WITHOUT_MOUDLES=list on buildkernel stage. But it builds all modules anyway. Simple check shows that I do something wrong: % cd /usr/src/sys/modules %make -V SUBDIR | grep -l 3dfx (standard input) %make WITHOUT_MODULES=3dfx -V SUBDIR | grep -l 3dfx (standard input) % What do I do wrong? -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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
Re: How to predict drive number change for 7.3-8.1 upgrade?
Dnia piątek 17 wrzesień 2010 o 16:35:52 Michael Sperber napisał(a): Marat N.Afanasyev ama...@ksu.ru writes: you may try the following commands: sysctl kern.geom.debugflags=16 foreach fs (your-filesystems) glabel label your-$fs-label your-$fs-device end echo geom_label_load=YES /boot/loader.conf reboot and see if the labels appear in /dev/label Is this safe to do? The man page for glabel seems to imply that glabel should be used before newfs, and tunefs after newfs. It's because geom class uses the last sector of the provider to keep his metadata, so if you will overwrite this sector then you lose this metadata(in this case label). So to not lose this metadata you should use geom_label first and then newfs on the /dev/label/... I think that using ufs label should be sufficient, glabel supports them too (under /dev/ufs directory). Maciek ___ 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
Re: WITHOUT_MODULES: does it work?
Lev Serebryakov-4 wrote: Hello, Freebsd-stable. I'm trying to build very small FreeBSD installation (8.1-STABLE) and trying to use WITHOUT_MOUDLES=list on buildkernel stage. But it builds all modules anyway. Simple check shows that I do something wrong: % cd /usr/src/sys/modules %make -V SUBDIR | grep -l 3dfx (standard input) %make WITHOUT_MODULES=3dfx -V SUBDIR | grep -l 3dfx (standard input) % What do I do wrong? If it should be small, why not use MODULES_OVERRIDE= list and build only the modules needed? regards, - Jakub Lach -- View this message in context: http://old.nabble.com/WITHOUT_MODULES%3A-does-it-work--tp29739626p29740089.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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
Re: How to predict drive number change for 7.3-8.1 upgrade?
On Fri, Sep 17, 2010 at 5:38 AM, Oliver Fromme o...@lurza.secnetix.de wrote: Michael Sperber sper...@deinprogramm.de wrote: I just upgraded my desktop system from 7.3 to 8.1, and the main hard drive, which was /dev/ad6 before is now /dev/ad10. Consequently, the initial boot failed when trying to mount the root file system from ad6. The desktop system is now fixed, but I also have a rented server with only a serial console, and I worry that the upgrade is going to leave me with a dead machine. Is there any way to predict how the drive number changes? (Why does it change at all?) If so, what's the proper way to tell the system the initial root device *before* rebooting? Remove options ATA_STATIC_ID from your kernel config before building the new kernel and rebooting. Then your first disk will be ad0, no matter what controller and channel it is connected to. Be sure to update your /etc/fstab file. Problem with doing that (no ATA_STATIC_ID) is that if you change the order that your PCI devices are enumerated, you will change the order in which your disks are probed, and all your numbers change again. :) And there's an option for this in every BIOS I've worked with. Plus, moving addon controllers from one slot to another will also re-number your devices. The best, long-term, solution is to label your devices/filesystems so that the name never changes, no matter what happsn to the underlying device nodes. There are multiple ways to do so, depending on whether you want to label the disk, the slice, the partition, or the filesystem: - glabe; - gpart labels - filesystem labels -- Freddie Cash fjwc...@gmail.com ___ 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
Re: How to predict drive number change for 7.3-8.1 upgrade?
Freddie Cash fjwc...@gmail.com wrote: On Fri, Sep 17, 2010 at 5:38 AM, Oliver Fromme o...@lurza.secnetix.de wrote: Remove options ATA_STATIC_ID from your kernel config before building the new kernel and rebooting. Then your first disk will be ad0, no matter what controller and channel it is connected to. Be sure to update your /etc/fstab file. Problem with doing that (no ATA_STATIC_ID) is that if you change the order that your PCI devices are enumerated, you will change the order in which your disks are probed, and all your numbers change again. :) And there's an option for this in every BIOS I've worked with. Plus, moving addon controllers from one slot to another will also re-number your devices. He wrote that it is a rented server with just one drive. I don't see how the drive number could ever change under these circustances. So removing ATA_STATIC_ID is really the easiest solution. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The last good thing written in C was Franz Schubert's Symphony number 9. -- Erwin Dieterich ___ 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
Re: WITHOUT_MODULES: does it work?
Lev Serebryakov l...@freebsd.org wrote: I'm trying to build very small FreeBSD installation (8.1-STABLE) and trying to use WITHOUT_MOUDLES=list on buildkernel stage. But it builds all modules anyway. No, it doesn't. WITHOUT_MODULES (note spelling) works fine. % cd /usr/src/sys/modules %make -V SUBDIR | grep -l 3dfx (standard input) %make WITHOUT_MODULES=3dfx -V SUBDIR | grep -l 3dfx (standard input) % What do I do wrong? You use the -l option of grep, which hides the actual match. Note that there are actually _two_ modules containing the string 3dfx: 3dfx itself and 3dfx_linux. So even when you exclude the 3dfx module, the other one will still be included and trigger the grep output. The following will make it clearer: $ cd /usr/src/sys/modules $ make -V SUBDIR | tr ' ' '\n' | grep 3dfx 3dfx 3dfx_linux $ make WITHOUT_MODULES=3dfx -V SUBDIR | tr ' ' '\n' | grep 3dfx 3dfx_linux $ Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Being really good at C++ is like being really good at using rocks to sharpen sticks. -- Thant Tessman ___ 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
Re: WITHOUT_MODULES: does it work?
On Friday 17 September 2010 17:21:54 Lev Serebryakov wrote: I'm trying to build very small FreeBSD installation (8.1-STABLE) and trying to use WITHOUT_MOUDLES=list on buildkernel stage. But it builds all modules anyway. Simple check shows that I do something wrong: % cd /usr/src/sys/modules %make -V SUBDIR | grep -l 3dfx (standard input) %make WITHOUT_MODULES=3dfx -V SUBDIR | grep -l 3dfx (standard input) The grep matches the 3dfx_linux module. signature.asc Description: This is a digitally signed message part.
problem pkg_add kdehier4-1.0.6.tbz
Hi there, Today I tried to update my notebook with pkg_upgrade tool, written by a German bsdforen.de member. I ran into problems installing kdehier4-1.0.6 package. pkg_upgrade -a === Install perl-5.10.1_2 (lang/perl5.10) pkg_upgrade: The package perl-5.10.1_2 will not be installed in favour of perl-5.12.1_1, because they conflict. === Install mp4v2-1.9.1 (multimedia/mp4v2) pkg_upgrade: The package mp4v2-1.9.1 will not be installed in favour of mpeg4ip-libmp4v2-1.6.1, because they conflict. === Install kdehier4-1.0.6 (misc/kdehier4) share/PolicyKit/policy: Could not unlink tar: Error exit delayed from previous errors. pkg_add: leave_playpen: can't chdir back to '' pkg_upgrade: The installation of kdehier4-1.0.6 failed. After delete the old package with pkg_delete kdehier4-1.0.4 and try installing it by pkg_add kdehier4-1.0.6.tbz the same error occurred. On the recommendation of kamikaze (the developer of pkg_upgrade) i ask for advice on the list. with kind regards rolle ___ 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
Re: problem pkg_add kdehier4-1.0.6.tbz
On 17/09/2010 19:02, rolle wrote:
Hi there,
Today I tried to update my notebook with pkg_upgrade tool, written by a
German bsdforen.de member.
I ran into problems installing kdehier4-1.0.6 package.
pkg_upgrade -a
=== Install perl-5.10.1_2 (lang/perl5.10)
pkg_upgrade: The package perl-5.10.1_2 will not be installed in favour of
perl-5.12.1_1, because they conflict.
=== Install mp4v2-1.9.1 (multimedia/mp4v2)
pkg_upgrade: The package mp4v2-1.9.1 will not be installed in favour of
mpeg4ip-libmp4v2-1.6.1, because they conflict.
=== Install kdehier4-1.0.6 (misc/kdehier4)
share/PolicyKit/policy: Could not unlink
tar: Error exit delayed from previous errors.
pkg_add: leave_playpen: can't chdir back to ''
pkg_upgrade: The installation of kdehier4-1.0.6 failed.
After delete the old package with pkg_delete kdehier4-1.0.4
and try installing it by pkg_add kdehier4-1.0.6.tbz the same error occurred.
On the recommendation of kamikaze (the developer of pkg_upgrade) i ask for
advice on the list.
with kind regards rolle
I had a look at src/usr.sbin/pkg_install/lib/pen.c and am
confused as to how this error can come to pass:
if (chdir(PenLocation) == FAIL) {
cleanup(0);
errx(2, %s: can't chdir back to '%s', __func__, PenLocation);
}
The way I read this PenLocation must be empty to show up like this.
However, a couple of lines before it says:
if (!PenLocation[0])
return 0;
Which means to me the chdir shouldn't even performed if
PenLocation is empty.
Regards
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
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
RE: if_rtdel: error 47 (netgraph or mpd issue?)
At 12:51 PM 9/10/2010, Mike Tancsa wrote: FYI, I enabled witness in the kernel and am seeing the following uma_zalloc_arg: zone 128 with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0b56ec4) locked @ /usr/src/sys/net/if.c:419 Hi, Another crash. I had it break to the serial debugger this time Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x20:0xc64c79e4 stack pointer = 0x28:0xe7c84864 frame pointer = 0x28:0xe7c84a9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1280 (mpd5) [thread pid 1280 tid 100096 ] Stopped at ng_path2noderef+0x174: testb $0x1,0x24(%esi) db bt Tracing pid 1280 tid 100096 td 0xc58f7780 ng_path2noderef(cace4b80,cb0a5350,e7c84ab8,e7c84ab4,0,...) at ng_path2noderef+0x174 ng_address_path(cace4b80,c64d4400,cb0a5350,0,28885ba0,...) at ng_address_path+0x40 ngc_send(cb66db44,0,cb2f4500,cba946f0,0,...) at ngc_send+0x182 sosend_generic(cb66db44,cba946f0,e7c84bec,0,0,...) at sosend_generic+0x50d sosend(cb66db44,cba946f0,e7c84bec,0,0,...) at sosend+0x3f kern_sendit(c58f7780,8d,e7c84c60,0,0,...) at kern_sendit+0x107 sendit(0,cba946f0,7,e7c84c7c,1,...) at sendit+0xb1 sendto(c58f7780,e7c84cf8,c093d225,c091bcfe,282,...) at sendto+0x48 syscall(e7c84d38) at syscall+0x1da Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (133, FreeBSD ELF32, sendto), eip = 0x284b13c7, esp = 0xbf9fe4cc, ebp = 0xbf9fe4f8 --- db where Tracing pid 1280 tid 100096 td 0xc58f7780 ng_path2noderef(cace4b80,cb0a5350,e7c84ab8,e7c84ab4,0,...) at ng_path2noderef+0x174 ng_address_path(cace4b80,c64d4400,cb0a5350,0,28885ba0,...) at ng_address_path+0x40 ngc_send(cb66db44,0,cb2f4500,cba946f0,0,...) at ngc_send+0x182 sosend_generic(cb66db44,cba946f0,e7c84bec,0,0,...) at sosend_generic+0x50d sosend(cb66db44,cba946f0,e7c84bec,0,0,...) at sosend+0x3f kern_sendit(c58f7780,8d,e7c84c60,0,0,...) at kern_sendit+0x107 sendit(0,cba946f0,7,e7c84c7c,1,...) at sendit+0xb1 sendto(c58f7780,e7c84cf8,c093d225,c091bcfe,282,...) at sendto+0x48 syscall(e7c84d38) at syscall+0x1da Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (133, FreeBSD ELF32, sendto), eip = 0x284b13c7, esp = 0xbf9fe4cc, ebp = 0xbf9fe4f8 --- db show locks exclusive sx so_snd_sx (so_snd_sx) r = 0 (0xcb66dc64) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 db show alllocks Process 1928 (sshd) thread 0xc6402a00 (100094) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc669a898) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1281 (ng_queue) thread 0xc58f6a00 (100057) shared rw radix node head (radix node head) r = 0 (0xc56e1580) locked @ /usr/src/sys/net/route.c:362 Process 1280 (mpd5) thread 0xc58f7780 (100096) exclusive sx so_snd_sx (so_snd_sx) r = 0 (0xcb66dc64) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 db call doadump() Physical memory: 2032 MB Dumping 274 MB: 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 Dump complete panic: 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 i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x20:0xc64c79e4 stack pointer = 0x28:0xe7c84864 frame pointer = 0x28:0xe7c84a9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1280 (mpd5) Physical memory: 2032 MB Dumping 274 MB: 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc04a5899 in db_fncall (dummy1=1, dummy2=0, dummy3=-1061510048, dummy4=0xe7c84600 ) at /usr/src/sys/ddb/db_command.c:548 #2 0xc04a5c91 in db_command (last_cmdp=0xc09cf71c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04a5dea in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04a7c6d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc069c7ae in kdb_trap (type=12, code=0, tf=0xe7c84824) at /usr/src/sys/kern/subr_kdb.c:535 #6 0xc08aabcf in trap_fatal (frame=0xe7c84824, eva=36) at
Re: WITHOUT_MODULES: does it work?
Hello, Oliver. You wrote 17 сентября 2010 г., 21:03:29: No, it doesn't. WITHOUT_MODULES (note spelling) works fine. It was error in message, not in config file :( The following will make it clearer: Yep, my fault. And I found why it doesn't work via NanoBSD build: quotes were excessive. Sorry for noise. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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
Re: How to predict drive number change for 7.3-8.1 upgrade?
On Fri, September 17, 2010 13:10, Freddie Cash wrote: On Fri, Sep 17, 2010 at 5:38 AM, Oliver Fromme o...@lurza.secnetix.de wrote: Michael Sperber sper...@deinprogramm.de wrote:  I just upgraded my desktop system from 7.3 to 8.1, and the main hard  drive, which was /dev/ad6 before is now /dev/ad10.  Consequently, the  initial boot failed when trying to mount the root file system from ad6.   The desktop system is now fixed, but I also have a rented server with  only a serial console, and I worry that the upgrade is going to leave me  with a dead machine.  Is there any way to predict how the drive number  changes?  (Why does it change at all?)  If so, what's the proper way to  tell the system the initial root device *before* rebooting? Remove options ATA_STATIC_ID from your kernel config before building the new kernel and rebooting.  Then your first disk will be ad0, no matter what controller and channel it is connected to.  Be sure to update your /etc/fstab file. Problem with doing that (no ATA_STATIC_ID) is that if you change the order that your PCI devices are enumerated, you will change the order in which your disks are probed, and all your numbers change again. :) And there's an option for this in every BIOS I've worked with. Plus, moving addon controllers from one slot to another will also re-number your devices. The best, long-term, solution is to label your devices/filesystems so that the name never changes, no matter what happsn to the underlying device nodes. There are multiple ways to do so, depending on whether you want to label the disk, the slice, the partition, or the filesystem: - glabe; - gpart labels - filesystem labels I have the same issue, a virtual machine rented in some datacenter. I'd like to know a way that is safe, as I did already on another box the glabel way without newfs on the label (but the underlying device). never got problems thought, but I figure this way is better for aditional disks, not / and system slices. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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
Re: How to predict drive number change for 7.3-8.1 upgrade?
Michael Sperber wrote: Marat N.Afanasyevama...@ksu.ru writes: you may try the following commands: sysctl kern.geom.debugflags=16 foreach fs (your-filesystems) glabel label your-$fs-label your-$fs-device end echo geom_label_load=YES /boot/loader.conf reboot and see if the labels appear in /dev/label Is this safe to do? The man page for glabel seems to imply that glabel should be used before newfs, and tunefs after newfs. probably safe, but I didn't try this. there's another option: you may consider to create gmirror device that allows you to shoot two ducks with one arrow: 1) make your system fail-safe 2) all your devices will be in form /dev/mirror/devXsYl regardless of underlying adX-s. to do this all you need is a second hard drive large enough to serve as copy of your boot drive -- SY, Marat
Re: Policy for removing working code
On 9/17/2010 2:14 AM, Vadim Goncharov wrote: You either not understanding that this situation is about entire project (not ISDN, but policy) I think at this point that you've made your concerns clear. What you don't seem to be understanding is: 1) The policy is, and always has been, those who are interested in keeping code alive work on it. 2) No one was interested (by the definition above) in keeping the ISDN code alive. Now you have raised a valid point on how we can do the volunteers needed notifications better in the future, and I think that those will be taken to heart, and acted on the next time we face this situation. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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
[releng_8_1 tinderbox] failure on i386/pc98
TB --- 2010-09-17 20:10:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-17 20:10:40 - starting RELENG_8_1 tinderbox run for i386/pc98 TB --- 2010-09-17 20:10:40 - cleaning the object tree TB --- 2010-09-17 20:11:27 - cvsupping the source tree TB --- 2010-09-17 20:11:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/i386/pc98/supfile TB --- 2010-09-17 20:48:08 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-17 20:48:08 - ERROR: unable to cvsup the source tree TB --- 2010-09-17 20:48:08 - 1.16 user 29.12 system 2247.95 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-i386-pc98.full ___ 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
Re: problem pkg_add kdehier4-1.0.6.tbz
On Friday 17 September 2010 19:02:51 rolle wrote: Today I tried to update my notebook with pkg_upgrade tool, written by a German bsdforen.de member. I ran into problems installing kdehier4-1.0.6 package. ports/UPDATING has the solution for this -- Alberto Villa, FreeBSD Committer avi...@freebsd.org http://people.FreeBSD.org/~avilla DATA: An accrual of straws on the backs of theories. signature.asc Description: This is a digitally signed message part.
Re: Atheros AR2427 in FreeBSD 8.1
Hi!
Right, I'm now ready to start looking at the AR2427. I can't guarantee
i'll get it -stable- (as that relies mostly on me getting the
AR9280/AR9285 stable; that'll take some time) but I'll at least try to
fix the above issue.
That issue you've just noted is because the EEPROM endian-ness has
been incorrectly detected. (See the invalid channel messages just
before the EEPROM starts dumping out no power set for x/y; then the
invalid txtime messages?) I've seen that in my local tree.
I have an AR2427 in this netbook of mine, so I'll figure out what's
busting up the detection and update my development HAL. I'll let you
guys know when that's done.
Adrian
2010/8/8 Adrian Chadd adr...@freebsd.org:
There's a lot of fixes that need to be brought over for the more
recent atheros chips.
They can come from Linux ath9k, or by porting the code from openbsd
(which is based on the linux ath9k code, from what I can tell.)
So someone needs to do some legwork and help Rui (and I, I guess)
merge in all the chipset work done in ath9k.
adrian
2010/8/2 Iván Zaera Avellón iza...@gmail.com:
Hi there:
It's not only a problem of your card. I have an Eee PC 1005HA with another
atheros card (officially supporter) and I experience the same error. I have
open a PR, have a look at it here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=148112
It seems to be a problem of the wireless or the ath driver.
Regards,
Ivan
2010/7/31 Макарук Роман Валерьевич n_diablo_...@pochta.ru
Hello! I have Asus Eee PC 1001PX wich Atheros AR2427. This Wi-Fi
officially not supported by driver ath. But in OpenBSD and Linux this card
supported.
I added to ath/ath_hal/ar9285_attath.c:
ar9285Probe(uint16_t vendorid, uint16_t devid)
tatic const char* ar9285Probe(uint16_t vendorid, uint16_t devid)
{
if (vendorid == ATHEROS_VENDOR_ID amp;amp; devid ==
AR9285_DEVID_PCIE)
return Atheros 9285;
if (vendorid == ATHEROS_VENDOR_ID amp;amp; devid ==
AR2427_DEVID_PCIE)
return Atheros 2427;
return AH_NULL;
}
And to /ath/ath_hal_ah_dev_id.h:
#define AR2427_DEVID_PCIE 0x002c
I compile ath module witch debug. And the WiFi has to work. But then i
try to connect tp AP witch WEP crypt i see next: ath0: bb hang detected
(0x80), reseting.
And my home AP DI-524 (WPA-PSK crypt) can not be found.
By this, I have a few questions. Can anyone help solve this problem and
finish the driver. And will the official support for this card in the
FreeBSD?
Appendix:
#kldload if_ath
pci0: driver added
found- vendor=0x8086, dev=0x27d8, revid=0x02
domain=0, bus=0, slot=27, func=0
class=04-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=22
powerspec 2 supports D0 D3 current D0
MSI supports 1 message, 64 bit
pci0:0:27:0: reprobing on driver added
found- vendor=0x8086, dev=0x27da, revid=0x02
domain=0, bus=0, slot=31, func=3
class=0c-05-00, hdrtype=0x00, mfdev=0
cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=21
pci0:0:31:3: reprobing on driver added
pci1: driver added
pci2: driver added
found- vendor=0x168c, dev=0x002c, revid=0x01
domain=0, bus=2, slot=0, func=0
class=02-80-00, hdrtype=0x00, mfdev=0
cmdreg=0x0407, statreg=0x0010, cachelnsz=8 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=17
powerspec 3 supports D0 D1 D3 current D0
MSI supports 1 message
pci0:2:0:0: reprobing on driver added
ath0: mem 0xfbff-0xfbff irq 17 at device 0.0 on pci2
pcib2: ath0 requested memory range 0xfbff-0xfbff: good
ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 59
ath0: [MPSAFE]
ath0: [ITHREAD]
ar9285Attach: sc 0xc49ca000 st 0x1 sh 0xe678d000
ar5416SetPowerMode: AWAKE - AWAKE (set chip )
ar9285Attach: AR_SREV 0xc02ff
ar9285Attach: ID 0xc02ff VERSION 0x3 TYPE 0x0 REVISION 0x2
ath_hal_v4kEepromAttach Eeprom Magic = 0xa55a
ath_hal_v4kEepromAttach Eeprom Version 14.13
v4kEepromReadCTLInfo Numctls = 6
ar5416SetPowerMode: AWAKE - AWAKE (set chip )
ar9280RfAttach: attach AR9280 radio
enableAniMIBCounters: Enable mib counters: OfdmPhyErrBase 0x0 cckPhyErrBase
0x0
ar9285Attach: return
getchannels: cc 0 regDmn 0xf0 mode 0xff ecm
getregstate: EEPROM cc 0 rd 0x10
getregstate: EEPROM rd 0x60
getchannels: !avail mode 0x6800c (0x2) flags 0x2150
getchannels: !avail mode 0x6800c (0x1) flags 0x140
ar5416GetChipPowerLimits: no min/max power for 2412/0xa0
Chan 2412: MaxPow = 63 MinPow = 0
ar5416GetChipPowerLimits: no min/max power for 2417/0xa0
Chan 2417: MaxPow = 63 MinPow = 0
ar5416GetChipPowerLimits: no min/max power for 2422/0xa0
Chan 2422: MaxPow = 63 MinPow = 0
ar5416GetChipPowerLimits: no min/max power for 2427/0xa0
Chan 2427: MaxPow = 63
Re: fbsd8_stable nfsv3 sys=krb5 issue [resolved]
Rick, I found the problem once I followed your suggestion to kinit -k fbsdclient.ee.auth.gr on the server; the output was wrong password or something like that. On both server and client I have two keys stored in their /etc/krb5.keytab files: one nfs/blabla and one host/blabla (due to other services I was testing on them). On the server, the first key stored in the keytab file was the host/ key and not the nfs/ key. Hence it wouldn't accept it (even though the kdc.log wouldn't complain...this I still haven't understood so far). Once I placed a single /etc/krb5.keytab file containing only the nfs/ key, everything worked as should. Which yields the (natural?) question: Why am I unable to kinit to both keys stored in my keytab (I am able to kinit only to the *first* key stored in the keytab), even though I have the right to store more than one keys in a keytab? Well, if it can only use the first entry in the keytab file, I would think that's a bug. (I have used a case where the entry wasn't the first one in the keytab file before and had it work, but I was using an older version of Heimdal in the BSD machine and an MIT KDC that generated the keytab file.) I have screwed up keytab entries in the past. A couple of my favourite ways to do so are: - creating another keytab entry for the same principal, which makes the old one invalid, due to the change in version#. - created the keytab entry with the wrong encryption type. Oh, and I'm not volunteering to go bug hunting in Kerberos:-) rick ___ 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
Re: MFC of ZFSv15
On Sep 16, 2010, at 1:44 AM, Martin Matuska wrote: I have fixed the missing bits in r212688. Thanks for the notice. Dňa 15. 9. 2010 21:12, Xin LI wrote / napísal(a): On 2010/09/15 11:30, Mike Tancsa wrote: At 02:07 PM 9/15/2010, Pascal Stumpf wrote: First of all, a great thanks to mm@ and pjd@ for the excellent work on ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago. [...] here too. RELENG_8 AMD64. The tinderboxes havent hit that branch yet (http://tinderbox.freebsd.org/http://tinderbox.freebsd.org/), so it will be a few hrs before they get to test RELENG_8 [...] -lsbuf -lm -lnvpair -luutil -lutil /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent' *** Error code 1 Sorry for that, it seems to be caused by a partial merge (cddl/compat/opensolaris/misc/mnttab.c). mm@ is going to fix that ASAP. Cheers, I am getting a build failure on 8.1-STABLE: = [[...]] cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/p1003_1b.c cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/posix4_mib.c cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/sched_ule.c cc1: warnings being treated as errors /usr/src/sys/kern/sched_ule.c: In function 'sched_switch': /usr/src/sys/kern/sched_ule.c:1807: warning: implicit declaration of function 'sched_pickcpu' /usr/src/sys/kern/sched_ule.c:1807: warning: nested extern declaration of 'sched_pickcpu' *** Error code 1 Stop in /usr/obj/usr/src/sys/BACKUP. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. = Unfortunately (for me, I guess), GENERIC will build successfully on this system. It's only my custom kernel config file that is failing make buildkernel. The custom kernel config is GENERIC with various inapplicable drivers removed, plus some non-GENERIC things added in (such as ALTQ support options). I am building via the standard make buildworld followed by make buildkernel method. Can anyone spot anything obviously awry? I've included my config file at the end. Cheers, Paul. # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.19 2009/07/15 08:32:19 ed Exp $ cpu I586_CPU cpu I686_CPU ident BACKUP # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols #optionsSCHED_4BSD # 4BSD scheduler options SCHED_ULE # ULE scheduler options
