similar to: changes in kernel affecting savecore/dumps ...

'k, now one of my other machines is getting the same thing on a crash: savecore: warning: /kernel version mismatch: "FreeBSD 4.8-STABLE #2: Fri Jun 20 18:34:14 ADT 2003 " and "" It was working, last successful savecore on that machine was Jun 6th: -rw------- 1 root wheel 4227792896 Jun 6 23:58 vmcore.1 -rw------- 1 root wheel 4227792896 Jun 6 10:37

Morning all ... 'K, this one is a first for me ... server crashed this aft and savecore wouldn't dump the resultant core: pluto# savecore -v /vm/crash dumplo = 4362141696 (8519808 * 512) savecore: warning: /kernel version mismatch: "FreeBSD 4.8-STABLE #1: Sat May 31 22:57:04 ADT 2003 " and " #(#(#(" savecore: reboot savecore: dump time is zero

My home NAS box, that I''d upgraded to Solaris 2008.11 after a series of crashes leaving the smf database damaged, and which ran for 4 days cleanly, suddenly fell right back to where the old one had been before. Looking at the logs, I see something similar to (this is manually transcribed to paper and retyped): Bad trap: type=e (page fault) rp=f..f00050e3250 addr=28 module ZFS null

Hi All, I''d like to set up dumping to a file. This file is on a mirrored pool using zfs. It seems that the dump setup doesn''t work with zfs. This worked for both a standard UFS slice and a SVM mirror using zfs. Is there something that I''m doing wrong, or is this not yet supported on ZFS? Note this is Solaris 10 Update 3, but I don''t think that should

Greetings I am having trouble with suspend/resume on my Thinkpad X31, running 7.0-STABLE as of April 23. Any help would be appreciated. First problem: When I run "acpiconf -s3" from mulituser mode, the system suspends immediately, without executing /etc/rc.suspend (which has mode 755); then on resume, I get a panic. Second problem: When the system panics, I don't get a dump (or

Hi! I've got FreeBSD 8.3-STABLE/i386 server that can be reliably panicked using just 'squid -k rotatelog' command. It seems the system suffers from the problem described here: http://cxsecurity.com/issue/WLB-2010090156 I could not find any FreeBSD Security Advisory containing a fix. My server has 4G physical RAM (about 3.2G available) and runs squid (about 110M VSS) with 500

The vendor wanted to come in and replace an HDD in the 2nd X4500, as it was "constantly busy", and since our x4500 has always died miserably in the past when a HDD dies, they wanted to replace it before the HDD actually died. The usual was done, HDD replaced, resilvering started and ran for about 50 minutes. Then the system hung, same as always, all ZFS related commands would just

grep union /var/log/messages Jul 2 12:53:01 jupiter savecore: reboot after panic: union_lookup returning . (0xc68e9e90) not same as startdir (0xc5e062c0) Jul 2 14:35:07 jupiter savecore: reboot after panic: union_lookup returning . (0xbf6fee90) not same as startdir (0xbb6d58c0) had two of them today, dumping nice cores ... I'm suspecting its someone trying to remove a file that is

Hi, I may have lost my first zpool, due to ... well, we''re not yet sure. The ''zpool import tank'' causes a panic -- one which I''m not even able to capture via savecore. I''m glad this happened when it did. At home I am in the process of moving all my data from a Linux NFS server to OpenSolaris. It''s something I''d been meaning to do

I've finally been able to capture the panic, as now it occurs even with DDB configured. Of the six machines I have running 6.1-RC (CVSupped today), this is the only one that does this. /boot/kernel/kernel text=0x30c488 data=0x3b6a0+0x3170c syms=[0x4+0x46430+0x4+0x58da4] no such file or directory - Hit [Enter] to boot immediately, or any other key for command prompt. Booting

One of our Solaris 10 update 3 servers paniced today with the following error: Sep 18 00:34:53 m2000ef savecore: [ID 570001 auth.error] reboot after panic: assertion failed: ss != NULL, file: ../../common/fs/zfs/space_map.c, line: 125 The server saved a core file, and the resulting backtrace is listed below: $ mdb unix.0 vmcore.0 > $c vpanic() 0xfffffffffb9b49f3() space_map_remove+0x239()

Hello. I recently upgraded to 9.1-RC3, everything went fine, however the / partition its about to get full. Im really new to FreeBSD so I don?t know what files can be deleted safely. # find -x / -size +10000 -exec du -h {} \; 16M /boot/kernel/kernel 60M /boot/kernel/kernel.symbols 6.7M /boot/kernel/if_ath.ko.symbols 6.4M /boot/kernel/vxge.ko.symbols 9.4M

hello, i built an ssh 2.5.1p2 package for solaris. it's installed into /usr/local (with sysconfdir=/etc) on an administrative host with write access to /usr/local. other hosts nfs mount /usr/local. i had a script copy the following files generated from the package install into each host's /etc directory: primes ssh_prng_cmds sshd_config ssh_config then ran

A few hours ago I downloaded .../i386/ISO-IMAGES/4.9-RC1-i386-disc1.iso and made kern/mfsroot floppies from it. If I enable my ICH5R SATA controller in "native" mode, the 4.9-RC1 GENERIC kernel hangs solidly (only the system reset button can unwedge it) during device configuration. The last line of bootstrap monologue written by the kernel is: plip0" <PLIP network

We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few days. This started shortly after upgrade from 6.2-RELEASE to 6.3-RELEASE with freebsd-update. Other than switching to a debugging kernel, a little sysctl tuning, and patching with freebsd-update, they are stock. The debugging kernel was built from source that is also being patched with freebsd-update. These systems are

I've just updated a low-volume fileserver to 5.4-stable (as of Sep 13), and ever since, whenever I try to move or copy a directory onto one of its NFS shares, it causes a crash. I do not have a crash dump (no dumpdev enabled, unfortunately), but I can reproduce it quite easily. The client is a 6.0-BETA3 machine, but I have no other NFS clients to test from (easily). Is this something known

hi again. after some tests, (on my operational domain and on a new testdomain) i detected this behavior: on samba 4.11.6 sometimes the new DNS-records finisches on a wrong dns zone. the problem occurs, if more then 5 records are created with the same name in more then one domain zone for example: testa1.jupiter.mydom.org testa2.jupiter.mydom.org testa3.jupiter.mydom.org

'K, not sure how/what to debug here ... doing a grep of svr1.postgresql.org in /proc/*/status shows all the processes 'stuck' in inode ... /proc/38750/status:inetd 38750 2072 2072 2072 -1,-1 noflags 1055120147,191009 0,0 0,592 inode 0 0 0,0,0,2,3,4,5,20,31 svr1.postgresql.org /proc/38752/status:inetd 38752 2072 2072 2072 -1,-1 noflags 1055120154,886433 0,0 0,637 inode 0 0

Hello all, I am not sure my original mail got through to the list (I haven''t received it back), so I attach it below. Anyhow, now I have a saved kernel crash dump of the system panicking when it tries to - I believe - deferred-release the corrupted deduped blocks which are no longer referenced by the userdata/blockpointer tree. As I previously wrote in my thread on unfixeable

Funny you should post this now. I was just cleaning up some DNS records and the following happend. I had to PTR records with an empty timestamp. I deleted them and wanted to recreate them. My reverse Zones are 0.168.192.in-addr.arpa and 2.168.192.in-addr.arpa both of the records I delted were in the "0" zone. The first i recreated with: samba-tool dns add dc1