From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 08:20:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8467C37B401 for ; Fri, 18 Jul 2003 08:20:32 -0700 (PDT) Received: from schnell.net (schnell.net [209.50.225.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id C246943FE3 for ; Fri, 18 Jul 2003 08:20:31 -0700 (PDT) (envelope-from loschert@servint.com) Received: from schnell.net (localhost [127.0.0.1]) by schnell.net (8.12.8p1/8.12.8) with ESMTP id h6IFKUgc030248; Fri, 18 Jul 2003 11:20:30 -0400 (EDT) (envelope-from loschert@servint.com) Received: from localhost (matt@localhost) by schnell.net (8.12.8p1/8.12.8/Submit) with ESMTP id h6IFKUmT030245; Fri, 18 Jul 2003 11:20:30 -0400 (EDT) (envelope-from loschert@servint.com) X-Authentication-Warning: schnell.net: matt owned process doing -bs Date: Fri, 18 Jul 2003 11:20:30 -0400 (EDT) From: Matt Loschert X-X-Sender: matt@schnell.net To: Valentin Nechayev In-Reply-To: <20030718091248.GO76126@lucky.net> Message-ID: <20030718111819.V30205@schnell.net> References: <20030718091248.GO76126@lucky.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: complicated downgrade X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2003 15:20:32 -0000 On Fri, 18 Jul 2003, Valentin Nechayev wrote: > (Cc'ed to phk@ as to main GEOM and DEVFS developer; see corresponding > questions below.) > > Hi, > > I need to downgrade a remote FreeBSD system from 5.1-release to 4.8-release > remotely without any local help (except possible hitting Reset). > Don't ask why the collocation provider is too ugly and too far from me; it's > given and unchangeable. This system never was 4.* (began from 5.0-DP2). > > I suppose the following algorith to have chance to succeed. > If anybody can check it and fix, please help. > > 1. Download 4.8-release and untar it to the separate tree in file system. > > 2. Remove all unneeded for this system (including modules, fore_dlnd, > mount_portalfs and other unused programs) from directories placed > on root fs; this is due to its small size (~64M). > > 3. Place directories for 4.8 as /bin4, /sbin4, /etc4, /boot4, /usr/lib4, etc. > > 4. Place kernel for this system as /kernel; add /kernel.GENERIC also. > > 5. Run MAKEDEV in /dev4 for all standard entries and entries for specific > disks (/dev/ar0s1a, etc.) > > 6. Add minimal site-specific contents to /etc4, enough to boot and run sshd > to allow admin to enter. It includes master.passwd (with admin entry), > /etc/ssh/* (copied keys and configs), /etc/resolv.conf, /etc/rc.conf, > /etc/fstab, /etc/group (allowing su); what else? > > 7. (The most horrible step.) > > Goal is to have /dev on disk (not DEVFS!) appropriate for booting 4.8. > Two alternatives are possible: > > 7a.1. Patch kernel to disable GEOM's protection against writing to > devices which is mounted or have mounted subparts. > (Here is most foggy place: I don't know how to do it in such way > as to disable rereading of disk structure on this place.) > 7a.2. Reboot with patched kernel. > 7a.3. Use a binary editor and renames root directory entries directly: > /dev4 to /dev, /dev to /dev5. (If entry name length matters, > use, e.g., de4 instead of dev4.) > 7a.4. Immediately reboot as to prevent namei subsystem damage. > > Result of all this is that devfs is mounted not over empty directory > (or only with standard entries, without local specific disks), but over > full working one. > > Alternative variant for step 7: > > 7b. add code to /sbin/init before mounting devfs: remount root to rw, > copy entries to it (/bin/cp -Rp). It will work if mount() allows > remounting to rw without correct /dev entry (this may have problems, > as I saw on 4.8). Reboot to run this code from init. > > 8. Disable all processes except sshd and run the following (saying generally): > > for D in /bin /sbin /etc /boot /usr/bin /usr/sbin /usr/lib /usr/libexec \ > /usr/libdata /usr/share /usr/local /var/db > do > mv ${D} ${D}5 > mv ${D}4 {D} > done > > 9. Reboot and hope 4.8 will load and run. > > I attached some local outputs to check for unexpectedness. > > > -netch- This is probably obvious, but whatever you do, I would suggest building a crash box to locally test the procedure on beforehand. I made the mistake of not perfectly testing a remote upgrade once upon a time, and will never do it again. - Matt -- Matt Loschert - Software Engineer | email: loschert@servint.com | ServInt Internet Services | web: http://www.servint.net/ | McLean, Virginia USA | phone: (703) 847-1381 |