Re: Crash with KVM monitoring in place ...
there, we appear to be good now:
venus# sysctl -a | grep dump
kern.dumpdev: { major = 133, minor = 0x20001 }
kern.sugid_coredump: 0
kern.coredump: 1
machdep.do_dump: 1
On Sun, 1 Sep 2002, Matthew Dillon wrote:
:
:
:venus# dumpon /dev/amrd0s1b
:dumpon: sysctl: kern.dumpdev: No space left on device
Grarrr. Well, maybe you were right re:
reducing the amount of physical memory a little
more. Try 2000m
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: Crash with KVM monitoring in place ...
On Sun, Sep 01, 2002 at 12:35:15PM -0700, Matthew Dillon wrote: : :On Sun, 1 Sep 2002, Matthew Dillon wrote: : : : : 'trace'. If over several crashes it dies in the same place : : then we at least have an idea where to look. : : : : How large is your swap space, or your largest free partition? : : : :My swap is only ~2gig, and my drive looks like: : : Right... then do as I suggested in a previous email. Reduce : the machine's memory to 2G via /boot/loader.conf: : : hw.physmem=2048m : : Then reboot and turn on dumps to the swap device. If you : can reproduce the crash with the machine downgraded to 2G : we should get a dump we can work with. : :Okay, just to confirm, my swap device looks like: : :venus# pstat -s :Device 1K-blocks UsedAvail Capacity Type :/dev/amrd0s1b 2097024 8708 2088316 0%Interleaved : :which is just under 2048m, at 2039m instead ... so ... should I sent it :down to 2000m even, or ... ? : :And all I need to do is set 'dumpdev=/dev/amrd0s1b' in /etc/rc.conf ... :no other settings I need? pstat -s reports 128K less then the actual size of the partition, so you have 2097152 = 2G exactly. 2048m should be fine. Yes, setting dumpdev=/dev/amrd0s1b in /etc/rc.conf should do it. You might want to set the dumpdir variable too, you'll need the location for the dumps to have enough space, or when your machine boots up it will try and read the dump from the swap space onto /var/crash (default) obviously its no good if it runs out of space while it is doing this. Good Luck. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Dominic Marks Computer Politics Geek [work]::[npl.co.uk] dominic.marks at npl.co.uk [educ]::[umist.ac.uk] notyet-known at umist.ac.uk [home]::[btinternet] dominic_marks at btinternet.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
HEADS UP: Package compression format changed
At the request of the release engineers the default package compression scheme has been changed from gzipped tarball to bzip2ed tarball. The package tools have been updated to deal with the new format (older package tools only had partial support for .tbz packages). Additionally, the ports collection packages distributed via the FTP site have been switched to .tbz, so if you are a regular user of these packages you will need to update and rebuild your package tools (e.g. by doing a complete upgrade). Kris msg49302/pgp0.pgp Description: PGP signature
Re: cvsup dying
here's the actual message Checkout src/contrib/ntp/readme.y2kfixes Detailer failed: Network write failure: Connection closed Will retry at 13:26:33 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvsup dying
On Sunday 01 September 2002 01:47 pm, Christoph Sold wrote: Karl Agee wrote: here's the actual message Checkout src/contrib/ntp/readme.y2kfixes Detailer failed: Network write failure: Connection closed Will retry at 13:26:33 Are you running CVSup as root? yes Have you tried another server? severak Did you read up the firewall FAQ information about CVSup? yes ( http://www.cvsup.org/faq.html#fwtk ) HTH -Christoph Sold To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvsup dying
well I've kludged my way though it--I simply added src/contrib/ntp to my refuse file and it's going onward fine now.. curious as to why it keeps stopping on one stinkin' file, though --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Updating world with least downtime
Date: Fri, 30 Aug 2002 17:20:24 -0700 From: David Schultz [EMAIL PROTECTED] Thus spake Kevin Oberman [EMAIL PROTECTED]: For a modern system and a reasonable disk, this is trivial. I have a system which MUST not be down for over 15 minutes and I can do it quite easily unless I really fumble something in mergemaster. I do always merge a few files later and tend to install most changes very quickly, having ode the same upgrade on a non-critical system just before I do the critical one so I know what to expect. The actual installworld time on my 1GHZ system is about 5 minutes (5:34 last time). Nice record. There ought to be a better solution than ``run mergemaster really fast and hope nothing goes wrong,'' though. For example, you could use mergemaster with -D on a copy of /etc and commit the copy in single user mode. No. I run mergemaster on another system to confirm what needs to be merged before reboot or can be installed with no complications. Then plan what I will have to do with any files that require merging. This is far different from just rushing through things and risking s disaster. It is, as the subject of the thread states, Updating world with least downtime. I like the idea of an early-run using -D, though. I might do that next time I update a system. Should be even faster than what I do and less prone to error. Thanks for the suggestion. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
