From owner-freebsd-stable Sat Nov 4 0: 9:36 2000 Delivered-To: freebsd-stable@freebsd.org Received: from 2711.dynacom.net (2711.dynacom.net [206.107.213.3]) by hub.freebsd.org (Postfix) with ESMTP id 8D66737B4C5 for ; Sat, 4 Nov 2000 00:09:31 -0800 (PST) Received: from urx.com (dsl1-160.dynacom.net [206.159.132.160]) by 2711.dynacom.net (Build 101 8.9.3/NT-8.9.3) with ESMTP id AAA01585; Sat, 04 Nov 2000 00:09:23 -0800 Message-ID: <3A03C433.C0BFA3F3@urx.com> Date: Sat, 04 Nov 2000 00:09:23 -0800 From: Kent Stewart Reply-To: kstewart@urx.com Organization: Dynacom X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: "freebsd-stable@freebsd.org" Subject: Re: Re-Booting new -STABLE Kernel: Failure To Mount Root .. even GENERIC References: <3A03A209.42953174@urx.com> <200011040714.AAA31109@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <3A03A209.42953174@urx.com> Kent Stewart writes: > : doing all of this from an xterm on the computer being upgraded. KDE > : will sometimes cause hang in perhaps 1 out of 6 or 7 tries. The > : frequency could be less often than that. > > Hmmm, I've never had a problem doing a buildworld in one Xterm while > doing other things in another. On really bad days, I've had problems > with make installworld, but that usually involves running me out of > disk rather than anything too hairy (except for the one kernel flagday > with signals that torpedoed me, but even that's been mostly or totally > fixed). I had some flaky things happen with KDE-1. KDE-2 ran out of swap space. I've never had more than 1% usage of my 300MB. It was just as easy to stop it before I did the mergemaster. It was all a matter of order. In order to reboot, I had to logout anyway and this way I did it before starting mergemaster. > > Usually I do silly things like buildworld/installworld and then I > build the kernel the traditional way, only cursing if it fails. My > kernel/userland updates are massively decoupled, but I'm supposed to > know what I'm doing. Usually I get away with a lot, but sometimes > that burns me (like not running mergemaster and wondering why ldconfig > would hang the boot process a while ago :-). I figure my left hand is slower than my right and one of these days I'll make a real mistake. I ended up with a script that captures everything from cvsup to the install world. If something is broken, I have a record of what was changed on that system. I liked what Nik Clayton's cvsuplog did when it converts my cvsup.log to html. Poelstra has a similar tool but my scripts already use cvsuplog. > > Other machines I'm fairly religous about doing things right so that > UPDATING isn't too far out of whack and I know how to field some of > the odd build problems that come in. These are generally my > production machines, so they get a little extra TLC (I don't have > their covers off as often swapping hardware :-). I have a big thing about building things in one step and then you install them. I never used a make world on my first attempt back at 2.2.8. It went against rules I had developed after many years of programming. I've followed your rules in UPDATING almost religously since your comment around the time I was having problems after O'Brien upgraded the /binutils. You can get aways with things but if you automate them, there isn't any point in trying to skip things. The buildworld and installworld require about 1:40 on my typical system. The buildkernel requires around 500 seconds and the installkernel is really fast. I start my upworld script and usually when I look back the two "makewhatis" lines are staring at me. It is already done and I would be just getting around to either starting the buildworld or the buildkernel. I just won't let mergemaster blindly upgrade my files. I also want to know what has been changed. > > Also, I tend to be conservative about what I recommend as the blessed > way. The conservative way will always work, although there are often > short cuts that will usually work most of the time, if the wrong > dependencies don't change on you. If the conservative way ever > breaks, it is usually fixed quickly :-) I call it KISS. I figure it only takes one mistake in an obtimized job stream to make a KISS'ed job be much faster. When you get in trouble, many people can help you. If you use something really complicated, even the creator may not be able to figure out what went wrong with the script. Kent > > Warner -- Kent Stewart Richland, WA mailto:kbstew99@hotmail.com http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message