When running a emerge sync or emerge-webrsync with less than 16 MB free filesystem space for the tmp partition, the portage sync will abort syncing and continue with deleting the rest of /usr/portage which will leave the system in a broken condition. You'll have to manually copy a /usr/portage tree from a stage-image to get your system working(updateable by emerge sync) again. Reproducible: Always Steps to Reproduce: 1. Lower free space on /var/tmp or /tmp filesystem to less than 16 MB. (e.g. dd a big file for filling your filesystem to emulate that) 2. Sync the portage tree either by emerge sync or emerge-webrsync (big updates will will use more tempspace, so try to update a more outdated /usr/portage tree) 3. See the rsync failing due to out of filesystem space and it will move over to deleting the rest of your /usr/portage tree. 4. Enlarge your free filesystem space again. (e.g. remove your dd-file from step1) 5. Try to emerge sync (or emerge-webrsync) your system again now. 6. It fails after updating a few directories which where left in /usr/portage. Actual Results: You'll have to copy a complete /usr/portage tree from a backup or stage image to get your portage sync working again. Expected Results: emerge sync or emerge-webrsync should check for at least 64MB free filesystem space, or a commandline switch or config-parameter should be added somewhere to check for this. It's extremly nasty for people using an internal /usr/portage(rw)-nfs-export where everyone should be allowed to do a sync to update it. But if one of those users doesn't watch the local filesystem space, they might kill this original tree on the NFS-server. So noone can use /usr/portage anymore.
Portage team - any comments about this one?
Err... that sounds more like a rsync bug then portage bug.
Yes, might be a rsync issue... I did find this: http://groups.google.com/groups?selm=aqda8b%24oii%241%40FreeBSD.csie.NCTU.edu.tw&output=gplain It was suggested to change code in receiver.c to raise an ENOSPC instead of RERR_FILEIO at some places. This was Nov/2002, and now in 2004 with rsync 2.6.x we still have the same code/bug ?
this is definitely not a release bug...
Fact is that webrsync will kill your portage tree when running out of diskspace. IMHO rsync should handle this, at least we need a patch for gentoo to ensure that it doesn't get its portage-tree destroyed that way. (This also happens when the portage snapshot is incomplete as on 10242004, as rsync just does its job and deletes everything not inside the snapshot.)
No way to handle when the snapshot is incomplete, and the md5sum of the snapshot is correct (in other words, if our mirrors are daft and release an incomplete snapshot, you're screwed and portage cannot detect it). Besides that, tar returns should be checked... for the sync refactoring, I know it is. For stable, the tar exit code is checked also.
*** Bug 61398 has been marked as a duplicate of this bug. ***
