From owner-freebsd-hackers Sun Apr 26 23:17:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA23878 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 23:17:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kaleb.keithley.belmont.ma.us (horizon4.camb.opengroup.org [130.105.39.28]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA23873 for ; Sun, 26 Apr 1998 23:17:11 -0700 (PDT) (envelope-from k.#nojunk#keithley@opengroup.org) Received: from kaleb.keithley.belmont.ma.us (localhost [127.0.0.1]) by kaleb.keithley.belmont.ma.us (8.8.8/8.8.8) with SMTP id CAA06393 for ; Mon, 27 Apr 1998 02:23:41 -0400 (EDT) (envelope-from k.#nojunk#keithley@opengroup.org) Message-ID: <3544246C.2781E494@opengroup.org> Date: Mon, 27 Apr 1998 02:23:40 -0400 From: "Kaleb S. KEITHLEY" Organization: The Open Group X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 3.0-980311-SNAP i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: 3.0-980311-SNAP "upgrade" post mortem References: <1360.893641190@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan K. Hubbard wrote: > > > First I tried to upgrade, but the new snap didn't like the superblocks > > in my filesystems. Nothing in any of the .TXT files warned me about > > this. The only apparent solution was to newfs all my partitions. After > > That's bizarre Yes, I thought so too. I'll be happy to provide any additional information for anyone who might be interested. > - I've heard of no one else with such a problem. You heard it here first. :-} > Are you > positive it was the superblocks it didn't like? Yup. When I started with the upgrade I was careful to toggle the newfs bits "off" in the fdisk/disklabel. I only told it about my wd0s2x partitions, with the expectation that when the upgrade was done I'd reboot with the saved fstab and my wd2s1 disk would be okay. As the upgrade proceeded it wouldn't mount the wd0s2x partitions (tried mounting them by hand in the emergency holographic shell and got the bad superblock error) and thus it couldn't backup my /etc before proceeding. (The install process gave me the "option" of treating this as a serious failure and aborting. Don't know what it would have done if I hadn't aborted.) So I proceeded to do a clean install, being careful to never touch wd2s1 and after all was said and done, when I tried mounting wd2s1f by hand, or fscking it, I got the bad superblock error on it too. (BTW, What's the fdisk/disklabel utility that's on the boot floppy, and why can't the "real" fdisk and disklabel utilities be replaced with that?) > > > like my file systems. They'd fsck'ed fine under the prior snap. Oh, BTW, > > the new snap could mount the old / (as root_device, read-only) just > > fine, but when it tried to remount it read-write then it would fail. > > And this was most definitely *not* the problem described in: > > ftp://ftp.freebsd.org/pub/FreeBSD/2.2.6-RELEASE/ERRATA.TXT ? > > Just making sure here before we go off on a chase. I went from 2.2.2-RELEASE to the 3.0-971225-SNAP without any problem. I don't really remember what the remount error was at this point, but that may well have been the problem. For instance in single-user mode I tried `mount -u /` and a bunch of other things which are getting hazy, but I'd wager I never tried `mount -u /dev/wd0s2a /'. I probably only used the old wd0a "compatibility" name. But that definitely wasn't the problem with mounting any of the other partitions. > > > But at boot time I get this message: > > > > /kernel: changing root device to wd0s3a > > You must have upgraded to a 3.0 SNAP that's still not entirely current. > This cosmetic bogon was fixed last month sometime. I did qualify it as the 3.0-980311-SNAP. That was, and still is the only snap that's on ftp.cdrom.com/ftp.freebsd.org. Is there a newer snap somewhere else? What file or files should I get from -current to make this bogon go away? (Or do I have to go on a search-and-destroy mission in the kernel sources? :-) > > > Third, on all prior releases, including the prior snap, I could set my > > default route at boot in /etc/rc.network (route add default > > 130.105.39.20) and it would "stick" until such time as I brought up my > > ppp link. This doesn't work anymore. Should it? It is/was convenient. > > I don't think it should, if it's the tun0 device you're really talking > about here. > > > Using "add default HISADDR" in the ppp.conf doesn't work either as it > > tries to set it before the link is up, and that's no better than setting > > it at boot. > > Which is why you put it in /etc/ppp/ppp.linkup Yes, that sounds like just the thing. Thank you. -- Kaleb S. KEITHLEY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message