El mar, 20-09-2011 a las 13:57 +0000, Duncan escribió: > Pacho Ramos posted on Tue, 20 Sep 2011 15:09:01 +0200 as excerpted: > > > I haven't ever tried it but, what would occur if that people with really > > updated systems simply unpack an updated stage3 tarball in their / and, > > later, try to update? > > I believe it was Mike that pointed me at the error in that, which once he > mentioned it I recognized it due to having to recover from the same > problem but for a different reason.[1] > > The problem is that since the stage-3 untarring bypasses portage, the > files on the live filesystem no longer match what portage believes to be > installed. The filesystem right after the untarring should be functional > to at minimum the level of the stage tarball, but as soon as one starts > emerging new packages, there will be issues since the old versions won't > be properly removed, because the files no longer match what's in the > database. > > FEATURES=unmerge-orphans is a dramatic help cleaning up the mess (it > wasn't around when I had the problem for other reasons, unfortunately), > but I don't believe it can or will catch everything. > > There's definitely a stage-3 tarball method that works and is actually > the recommended method for updating real old installations, but it > involves using a chroot and effectively installing from scratch in the > chroot, then booting to it instead of the existing installation. That's > basically a special-case of case #5 in the Gentoo Linux Alternative > Installation HOWTO, installing Gentoo from an existing Linux distro[2]. > The only bit of note is that the existing distro happens to be (an > outdated) Gentoo as well, instead of whatever other distro. > > --- > > [1] My situation was separate /, /usr and /var partitions, each with > backups, but ending up in a recovery situation where the backups weren't > in sync time-wise. Thus portage's package installation database on /var > was out of sync with the actual files on / and /usr. I was still finding > the occasional stale file triggering issues, over a year later! It's for > this reason that by personal policy, everything portage installs to is on > the same partition, along with the installed package database, so if I > end up using a backup of that partition, the database is by definition in > sync with what's installed since it's all the same backup partition. > > > [2] http://www.gentoo.org/doc/en/altinstall.xml#doc_chap5 > > I used this HOWTO from Mandrake back in 2004, for my original > Gentoo/~amd64 install. For that matter, the gentoo/amd64 32-bit chroot > guide is a variant on this idea as well, except that for just a 32-bit > chroot, the host-system kernel and services can be used, so they don't > need built. But I did a variant on /that/ for my netbook build image, > located on my main machine since it's far more powerful than the netbook, > and of course I built the kernel and system services for it, tho I only > actually ran them after installing them to the netbook.
I thought that problem wouldn't occur as, if I don't misremember, stage3 tarballs include /var/db/pkg files for its packages and, then, an "emerge -e world" just after unpacking stage3 would use updated /var/db/pkg contents from stage3 and, for the remaining files, they would be updated as soon as emerge -e world ends (maybe this and "unmerge-orphans" would solved most of the issues)
signature.asc
Description: This is a digitally signed message part
