From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 19:23:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D106596B for ; Sun, 1 Jun 2014 19:23:38 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8662228D8 for ; Sun, 1 Jun 2014 19:23:38 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id w8so1525381qac.19 for ; Sun, 01 Jun 2014 12:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PbsH8sKGlaOhBljnhVBhfTg841KEjZKgG4EA/J9yoaQ=; b=ViD7oe7/fX76xSLpHrWaE6PZrRUI9aI1Gm7a2p5GXLrVI/tCaSC79LJs9JFLvz+b0O NRVl51773BK31d3Q4aCnkUVZfxgr4d/QDa+6Tk1DLQbJjC76vqUPByc3uz3y2niaPbNM 2x7Cg9npqKw9PuJMLCbl8tGuIpcOMvRLv2OlU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PbsH8sKGlaOhBljnhVBhfTg841KEjZKgG4EA/J9yoaQ=; b=iwzfmPVrFXR1VbpQGEOz0yVix893kNeW8z63Af7i/odZMHs3c07HDIlcpWCxSqm1EU Kw+xsixnVvVsHVCSPeM+kTMYjSwvtzaRjN/XK7h7ZAjhlQikeFfFSDvBK4AI0BONHrzq Yo36TSttDSdgLzIpWTVuiC1Pbq5z/YvnkdV5u1vZPHrO9Kv7+qFwUq+rb/M7d5IKSh7h XDUwnniyQBanxnxoN54kI1xJLM3Hd1j1OgB8GIukW7oBODMRiExf+bjMF6RzwQ843LTq FjgmPWs55uR7U6koMrf0/S9rD9e/xUvsovvkQ1A+ndgRCYkFi2q0eWtU5Rg75G570DSa U3Xw== X-Gm-Message-State: ALoCoQma4HJzbpe+QRHydFrbsQ2BCvn5WRZiDrAeWHQnvRQFGUctRgsEpShqzFBK1N/OVyNQ0aWc MIME-Version: 1.0 X-Received: by 10.224.92.144 with SMTP id r16mr43883288qam.10.1401650617553; Sun, 01 Jun 2014 12:23:37 -0700 (PDT) Received: by 10.140.92.198 with HTTP; Sun, 1 Jun 2014 12:23:37 -0700 (PDT) X-Originating-IP: [75.128.101.59] In-Reply-To: <538B7937.2030104@mu.org> References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> Date: Sun, 1 Jun 2014 15:23:37 -0400 Message-ID: Subject: Re: Upgrading an i386 machine from amd64. From: Jason Hellenthal To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 19:23:38 -0000 What about doing an install to DESTDIR on the amd64 machine then using either cpio(1) or if it was on its own device whether it be a mdconfig(8)'d file and then using dump(8) to just create a backup and restore file of the whole filesystem... truncate -s 4g /usr/mdroot mdconfig -v -f /usr/mdroot newfs -U -O2 /dev/md0 mount /dev/md0 /mnt/md0 make installkernel DESTDIR=/mnt/md0 make installworld DESTDIR=/mnt/md0 dump -h -0 -L -f /data/md0.backup /dev/md0 Then on the i386: cd / ; restore rvf /data/md0.backup Should keep your flags and everything else that may exist without the need for any install tools which can be replaced at a later point. On Sun, Jun 1, 2014 at 3:04 PM, Alfred Perlstein wrote: > > On 6/1/14, 11:58 AM, Jason Hellenthal wrote: > >> >> On Jun 1, 2014, at 14:51, Alfred Perlstein wrote: >>> >>> >>> On 6/1/14, 11:42 AM, Jason Hellenthal wrote: >>>> That would be nice. Could've swore there was something similar to that >>>> but memory escapes me as I haven't done backwards cross compiles in awhile. >>>> >>>> Curious have you done a svn status on your src tree in a while to see >>>> if there are any stale depends laying around that may affect the >>>> compilation ? >>>> >>> I use git. :) But the build tree was completely clean. >>> >>>> Also ALWAYS_CHECK_MAKE=YES defined in make.conf ? >>>> >>> No, what does that do? >>> >> Instructs the top-level Makefile to check if make(1) is up-to-date. Not >> sure if it really would have an effect on a cross build but worth a shot. >> make.conf(5) holds a better definition of it. >> >> I think once I get this sorted I will make a blog post on it, right now >>> that blog post is basically: >>> >>> export TARGET=i386 >>> make buildworld -j36 >>> make buildkernel -j36 >>> mkdir -p /mnt/target.local /mnt/target >>> make installkernel installworld DESTDIR=/mnt/target.local >>> mount i386target:/ /mnt/target >>> rsync -avvH /mnt/target.local /mnt/target >>> >>> I thought though there was a way to get this to work, obviously there is >>> a bug here that we lose "chflags" bits on install. I wonder if there's a >>> way to restore or preserve them? >>> >> rsync(1) can be build from ports with the chflags patch that should aid >> in preserving them. >> >> rsync --fileflags . . . >> > > Unfortunately I'm doing it over NFS and I don't think we support chflags > over NFS (not even with an extension). > > mount i386target:/ /mnt/target > rsync -avvH /mnt/target.local /mnt/target > > > So that wouldn't work... perhaps if I mounted from the i386 host and ran > rsync from the i386 host, however then I'm overwriting the running system... > > I figured out two other ways that might work: > > 1) make the "distribution tarballs" then dig through the installer to find > the part that knows about manifests enough to set chflags. > -or- > 2) give up and build it all under a i386 vm so the "installtools" are > i386, then somehow export that to the i386 machine. > > meh! > > -Alfred > >> >> -Alfred >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>>> Jason Hellenthal >>>> Voice: 95.30.17.6/616 >>>> JJH48-ARIN >>>> >>>> On Jun 1, 2014, at 14:24, Alfred Perlstein wrote: >>>> >>>> On 6/1/14, 10:34 AM, Jason Hellenthal wrote: >>>>>> What if you just NFS mount the obj directory from the 386 to the >>>>>> amd64 build world for 386 the mount the src on the i386 and just rebuild >>>>>> strip and friends ? >>>>>> >>>>>> A little more of a hack i know but would get the job done. >>>>>> >>>>> I tried that using install(1), then it broke with strip(1), then I >>>>> basically was like, "this is a rabbit hole, forget it" and used rsync. >>>>> >>>>> I was really looking for a "buildinstalltools" or something target (as >>>>> you suggest), but I couldn't find one. >>>>> >>>>> Is there an "buildinstalltools" target? >>>>> >>>>> -Alfred >>>>> >>>>>> -- >>>>>> Jason Hellenthal >>>>>> Voice: 95.30.17.6/616 >>>>>> JJH48-ARIN >>>>>> >>>>>> On Jun 1, 2014, at 13:25, Alfred Perlstein wrote: >>>>>> >>>>>> Hello hackers. >>>>>>> >>>>>>> Is there a way to build on amd64 and then mount over nfs the build >>>>>>> and src and installworld from an i386 machine? >>>>>>> >>>>>>> The problem seems to be that "install" and "strip" and etc are built >>>>>>> as amd64 binaries so that the installworld will fail. >>>>>>> >>>>>>> Below I have a solution I was going to do a blog post about, but >>>>>>> then realized maybe I'd be leading people down the wrong path. >>>>>>> >>>>>>> Can someone verify that I need to use rsync as opposed to >>>>>>> installworld for this to work? >>>>>>> >>>>>>> I have an old i386 based soekris geode box called "soekris": >>>>>>> CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class >>>>>>> CPU) >>>>>>> Origin = "AuthenticAMD" Id = 0x5a2 Family = 0x5 Model = 0xa >>>>>>> Stepping = 2 >>>>>>> Features=0x88a93d >>>>>>> AMD Features=0xc0400000 >>>>>>> real memory = 536870912 (512 MB) >>>>>>> avail memory = 502792192 (479 MB) >>>>>>> >>>>>>> Building on this machine is difficult because of the speed and lack >>>>>>> of space, so I decided to use my more powerful amd64 machine "spigot": >>>>>>> CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class >>>>>>> CPU) >>>>>>> Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a >>>>>>> Stepping=7 >>>>>>> ... >>>>>>> real memory = 17179869184 (16384 MB) >>>>>>> avail memory = 16585228288 (15816 MB) >>>>>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>>>>>> >>>>>>> So I've built an 10-stable on the amd64 machine using: >>>>>>> >>>>>>> spigot % TARGET=i386 >>>>>>> spigot % make -j24 buildworld >>>>>>> spigot % make -j24 buildkernel >>>>>>> >>>>>>> Works great, I get an i386 object tree under /usr/obj/i386.386/... >>>>>>> >>>>>>> Then I go to install this over NFS and this is where I get stuck. >>>>>>> >>>>>>> If I mount the i386 machine like so and install I get errors on libc >>>>>>> and other libraries: >>>>>>> >>>>>>> spigot % mount soekris:/ /usr/soekris >>>>>>> spigot % cd /usr/src && make installworld >>>>>>> ..... >>>>>>> ===> lib/libcrypt (install) >>>>>>> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >>>>>>> install -C -o root -g wheel -m 444 libcrypt_p.a >>>>>>> /usr/soekris/usr/lib >>>>>>> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 >>>>>>> /usr/soekris/lib >>>>>>> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >>>>>>> *** Error code 71 >>>>>>> >>>>>>> Stop. >>>>>>> make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt >>>>>>> *** Error code 1 >>>>>>> >>>>>>> OK, so that doesn't work... >>>>>>> >>>>>>> Maybe if I mount the amd64 build host under the soekris box, no that >>>>>>> breaks because the bootstrap tools (install(1), strip(1)) are built for >>>>>>> amd64 so the install fails. >>>>>>> >>>>>>> So what I finally did on the amd64 box was: >>>>>>> >>>>>>> spigot % mkdir /use/soekris.local >>>>>>> spigot % make installworld DESTDIR=/usr/soekris.local >>>>>>> spigot % mount soekris:/ /usr/soekris >>>>>>> spigot % rsync -avvH /usr/soekris.local/ /usr/soekris/ >>>>>>> >>>>>>> That hung at the end forever at the end: >>>>>>> var/unbound/ >>>>>>> var/yp/ >>>>>>> var/yp/Makefile >>>>>>> var/yp/Makefile.dist >>>>>>> .... >>>>>>> >>>>>>> but after giving it an hour I just hit ^C and rebooted and >>>>>>> everything was more or less fine. >>>>>>> >>>>>>> Is there a better way to do this? Was the "installworld to NFS" >>>>>>> breaking because of NFS bugs? Should I get those to Rick? I'm just >>>>>>> confused. >>>>>>> >>>>>>> -Alfred >>>>>>> _______________________________________________ >>>>>>> freebsd-hackers@freebsd.org mailing list >>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ >>>>>>> freebsd.org" >>>>>>> >>>>>> >